[svat]

I'm just now trying to send some mathematics in an email (where most recipients will be reading it in Gmail), so I'm having to figure out what subset of HTML and CSS Gmail supports. (Found this reference for CSS: https://developers.google.com/gmail/design/reference/support...) It turns out that simply using MathJax or KaTeX and pasting the resulting web page into an email doesn't work: Gmail doesn't support SVG images (security concerns?), so one needs to convert images to PNG, but then converting every $n$ or $x$ into a separate image feels like overkill (the email would become huge and slow to load), so it would be nice to only convert expressions that “really” need it. It seems Pandoc by default has a mode where it converts only “simple” expressions and throws a warning on math that cannot be converted to simple HTML (using "em" and "sup" tags and a Unicode alphabet for things like ∑), so we can use this as a trick to identify which math expressions need conversion to images. Then if any of these images occurs inline, we need to figure out the baseline problem.

And so on... Funny how trying to do the slightest thing with technology (send some mathematics over email) immediately turns into a research project.

[ktpsns]

That's why most folks I know either write a short latex file (and append pdf+tex) or write pseudo code or full latex code because... The recipient understands latex.

But honestly, this is way more portable then mathjax or MathML or whatever. Consider using a latex enabled chat when it really differs.

[svat]

Yes, those were two other options I considered. Ultimately both require higher effort from the reader (view the PDF, or mentally parse LaTeX syntax or have something special installed that does so), neither of which is conducive to quick skimming etc. Just optimizing for reader convenience. :-)

[orf]

Have you done any benchmarking on the sizes of the images? I cannot imagine a JPEG math expression, cached by google, is going to take an age to load when viewed in Gmail and not be that large.

[svat]

That's a good question. The actual size of the images is not large: the problem is that I can visually see the email take a while to load properly, even for an email containing just two PNG images that are 2941 bytes and 6333 bytes respectively. If nearly every sentence were to be interrupted a few times with such delayed-loading images, the reading experience would be rather poor.

(This was with the images self-contained in the email, which seems to be implemented under the hood by having them be attachments and referring to them in the body, so the loading happens out of order... I haven't tried with the images being loaded as external images, but that has its own problems such as Gmail probably not loading them by default, or having to ensure the images will be available over the internet for as long as anyone might want to read the email which if you're sending it to a mailing list is ideally forever, etc.)

[claar]

Try embedding Base64 images in the email instead:

  <img src="data:image/png;base64,iVBORw0K...=">

[londons_explore]

Inline base64 shouldn't have any head of line blocking or slow rendering issues, unlike embedded images-as-mime-attachments, which will normally result in one HTTP request to gmails servers per image, and without QUIC you'll get head of line blocking and limited/no HTTP pipelining making that very slow.

Inline base64 should perform fine for small images up to ~10k images I'd guess on most hardware.

If your email contains more than 10k math equations, perhaps email isn't the right tool...

[jraph]

That's what the LaTeX It! Thunderbird add-on [1] does I think. Good extension by the way. Not sure it will work with Thunderbird 68, I didn't check.

[1] https://addons.thunderbird.net/en-US/thunderbird/addon/latex...