You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I noticed from adam-p#874 that Markdown Here's privacy policy was out of date, so I took a pass at the policy language to disclose data sharing with CodeCogs for math rendering.
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.
The text was updated successfully, but these errors were encountered: