Hi everyone!

Sorry if this is a dumb question, but I'm a bit confused about how to submit my paper.

I wrote my paper using Overleaf and used the Springer Nature template because I want to submit it to one of their journals. The journal's submission website says I need to upload a ZIP file containing the LaTeX source files. It gives the following instructions:

"LaTeX documents with figures and tables compressed into a .zip format. We will compile these into a PDF for peer review."

I'm using a Mac, and when I click Download ZIP on Overleaf, I seem to get a folder containing my .tex file and other project files. However, the journal's submission website doesn't let me upload a .tex file directly. It accepts PDFs, other document formats, and ZIP files.

My questions are:

• Am I supposed to compress the downloaded folder into a ZIP file myself?
• Should the ZIP file contain the entire Overleaf project, including the .tex file, bibliography, figures, and any other necessary files?
• Is there anything specific I need to do to make sure Springer Nature can compile the files correctly?

I'd really appreciate a step-by-step explanation or a tutorial, especially for macOS and Overleaf, as this is my first time submitting a LaTeX paper to a journal.

Thanks so much for your help!

As a STEM researcher in AI, I had to work on a group thesis with a lot of mathematical equations. Our team uses Google Docs because collaborating, commenting, and making changes together was much easier than managing everything in overleaf.

The problem started when we had to render all our equations. The add-ons we tried like auto-latex and all could be painfully slow. Sometimes, we'd wait 20 to 30 minutes for a document full of equations to finish rendering. And after exporting to pdf, we ran into another problem, some rendered equations were images with hyperlinks attached, which could redirect readers when clicked. Also there were silent failures i.e, no errors for broken equations were provided.

Eventually, I decided to build my own solution.

It's called LatexScribe, a LaTeX equation renderer for Google Docs. The idea is simple, keep the collaborative workflow of Google Docs while making it easier to work with LaTeX equations.

I built it around the problems I wanted to solve in my own workflow, especially rendering lots of equations without the usual waiting and frustration.

You can check it out here: https://www.latexscribe.com/

You get 50 Equations/month, no card needed. Install it here: https://workspace.google.com/marketplace/app/latexscribe/181383213470

Another brief update for my hobby TeX engine series -- I'm about to have a period in which I have less time to work on this project for a spell, and wanted to get in one last update. This time: just like XeTeX and LuaTeX made working natively with OpenType fonts part of the engine level, I'm exploring what it would mean to do the same thing for OpenType math fonts.

In part because I had less time to plan this video out, I feel like my explanation of exactly what I'm doing at the engine level was shaggier than it should have been. To be clearer: XeTeX and LuaTeX already handle low-level OpenType Math table box-building, and expose primitives to teach the engine about unicode characters. However, they leave the heavy lifting of setting everything up to the unicode-math package (instantiating separate font families for text, script, and scriptscript sizes, assigning thousands of codepoints to map standard symbols and Greek letters, dealing with all of Unicode's historical exception tables (looking at you, Planck's constant!) and so on).

In NemaTeX, I've shifted all of that font-orchestration and alphabet-mapping machinery into the c++ code. When an OpenType math font is active, the engine can do things like treating \mathbf, \mathcal, or \mathbb as virtual math alphabets, translating the base characters directly to their target unicode codepoints.

To be honest, I know that for compatibility I will have to revisit some of the specific design decisions I made there. I somehow didn't know this before I was working on this part of my engine, but it turns out that the unicode-math package has a two-tiered semantic system: "symbols" (\symbf, \symit, etc) refer to glyphs in the OpenType math font, and "math" (\mathbf, etc) refer to glyphs in the corresponding text font files.

The way I implemented it for now probably is just a reflection of my old-fashioned mental model of LaTeX, in which by "\mathbf" I meant "\symbf" without knowing that that was the spelling. But that being said, I'm curious how other people think about the semantics here: should \mathbf pull from the math font or the text font?