We currently (and have always) used a third-party service for TeX rendering -- Google and now CodeCogs. There are two really bad things that come with this:
User math is being sent to the third party.
If the third party service goes away (like when Google shut down the API we were using), the rendering dies. And not just when writing a new email, but also when reading the email.
The ideal would be to render the math image locally and include it in the rendered MD->HTML output. A big problem with that is that there's no easy way to do it with (for example) Gmail; images with inline data don't work, etc.
However, maybe it's possible to do this by pasting the image; see this comment for details. This is no small task, as it's a fundamental change. It needs a proof of concept that can be tested in multiple email providers and other sites -- there's a very good chance that they don't all support image-pasting and so this method would work worse than the current DOM-insertion-with-remote-image method.
See #144 and #261 for background.
We currently (and have always) used a third-party service for TeX rendering -- Google and now CodeCogs. There are two really bad things that come with this:
The ideal would be to render the math image locally and include it in the rendered MD->HTML output. A big problem with that is that there's no easy way to do it with (for example) Gmail; images with inline data don't work, etc.
However, maybe it's possible to do this by pasting the image; see this comment for details. This is no small task, as it's a fundamental change. It needs a proof of concept that can be tested in multiple email providers and other sites -- there's a very good chance that they don't all support image-pasting and so this method would work worse than the current DOM-insertion-with-remote-image method.