TeX Math rendering

[bordaigorl]

I am proposing to add TeX math rendering via Google Charts or the like.

The only change needed is in marked.tex that needs to be patched as follows

--- marked.js   2012-08-06 16:26:22.155518000 +0100
+++ marked-tex.js   2012-08-07 17:59:24.654090000 +0100
@@ -306,3 +306,3 @@
 var inline = {
-  escape: /^\\([\\`*{}\[\]()#+\-.!_>])/,
+  escape: /^\\([\\`*{}\[\]()#+\-.!_>\$])/,
   autolink: /^<([^ >]+(@|:\/)[^ >]+)>/,
@@ -312,2 +312,3 @@
   reflink: /^!?\[(inside)\]\s*\[([^\]]*)\]/,
+  math: /^\$([^ \t\n\$][^\$]*[^ \t\n\$])\$/,
   nolink: /^!?\[((?:\[[^\]]*\]|[^\[\]])*)\]/,
@@ -317,3 +318,3 @@
   br: /^ {2,}\n(?!\s*$)/,
-  text: /^[^\0]+?(?=[\\<!\[_*`]| {2,}\n|$)/
+  text: /^[^\0]+?(?=[\$\\<!\[_*`]| {2,}\n|$)/
 };
@@ -341,3 +342,4 @@
   strong: /^__(?=\S)([^\0]*?\S)__(?!_)|^\*\*(?=\S)([^\0]*?\S)\*\*(?!\*)/,
-  em: /^_(?=\S)([^\0]*?\S)_(?!_)|^\*(?=\S)([^\0]*?\S)\*(?!\*)/
+  em: /^_(?=\S)([^\0]*?\S)_(?!_)|^\*(?=\S)([^\0]*?\S)\*(?!\*)/,
+  math: noop
 };
@@ -346,3 +348,3 @@
   url: /^(https?:\/\/[^\s]+[^.,:;"')\]\s])/,
-  text: /^[^\0]+?(?=[\\<!\[_*`]|https?:\/\/| {2,}\n|$)/
+  text: /^[^\0]+?(?=[\$\\<!\[_*`]|https?:\/\/| {2,}\n|$)/
 };
@@ -369,2 +371,9 @@

+    // math
+    if (cap = inline.math.exec(src)) {
+      src = src.substring(cap[0].length);
+      out += '<img alt="'+cap[1]+'" src="https://chart.googleapis.com/chart?cht=tx&chl='+encodeURIComponent(cap[1])+'">';
+      continue;
+    }
+
     // autolink

or along the same lines.

I am aware of one big downside of this approach: the image gets rendered on the fly by google chart so your TeX formula flies around the net every time you (or the receiver) view it.
This conflicts with the general idea of Mardown-here rendering the content completely in-browser.

A fully fledged solution could present an option to disable this feature if "no info leak" is a strong requirement.

The added functionality is in my opinion a huge gain when working on scientific projects with collaborators.
A warning that this is not rendered in browser would in my opinion be enough.

[adam-p]

This is a super cool suggestion, and it'll almost certainly get added. (I've been burned by trying to mess with the Markdown rendering before, and I'm a little worried about tweaks like this turning into a slippery slope, but... it's still too cool to not add.)

I totally agree with the info-leak concern, so there will be an option to enable it (which means it'll be disabled by default, which is sad).

Taking a look at this SO post suggests that there are different rendering providers and different GCharts options that might be nice to expose to users. So, the options page could let the user modify the base URL being used. (It'll default to the HTTPS GCharts URL in your code.) On the other hand... getting that URL prefix from the options down into the Marked.js code might make me stop caring about this custom-URL option.

This suggestion set me to thinking about abstracting Markdown Here into a plugin-able email-mutation framework. So, there could be a Markdown plugin and a Tex plugin and a Textile plugin and a RST plugin and so on. Some plugins would work with others (like Markdown with Tex), while some would replace others (like MD and Textile). I don't think I'm going to try to do this in the short term, though, for two reasons:

1. A sample size of two plugins (Markdown and Tex) isn't very big, and maybe no one will ever want another.

2. The design is hurting my brain. For example, Markdown will gladly consume $Tex$ and stick it in a paragraph, which isn't a great form to feed it to Tex. Your simple Tex extractor can leave everything else intact, though. So the order of plugin application matters? But is this just a special case because the Tex one is so simple? Would all/most (all-but-final) plugins need to be aware that they're in the Markdown Here framework and not change stuff that doesn't belong to them (and be very conservative about what "belongs to them")?

   Maybe another way of stating my concern: I'm not sure how/if different plugins can do successive passes over plaintext and the final result be good and sane. (Especially if those plugins aren't custom-crafted to work with Markdown Here.)

Anyway, pluginable architecture is not in the short term. Looking at Tex support is in the short term.

[adam-p]

There's another non-fatal strike against this change that I forgot to mention: Modifications to Marked.js could have later repercussions (besides the usual harder-to-update-from-upstream). Markdown Here was failed Mozilla approval because I had made changes to Highlight.js (see #21) -- which is code that they've already reviewed and therefore don't want people to modify. They haven't said anything about my existing modification to Marked.js, but... it could happen.

"But you've already modified Marked.js!", you say? That's true, but I've submitted an issue to Marked.js about the change -- markedjs/marked#54 -- and I have a faint hope that it might be fixed/changed someday.

Anyway, this is just an academic objection. Just stating it for completeness.

[bordaigorl]

I am glad you like the idea!

Few remarks:

1. It would be nice to support different renderers. It would allow particularly picky users to roll out their own server for rendering (even hosting it locally). I think it can be done by changing just slightly the current settings of marked.js:
   • I like the way marked.js implements the pedantic and gfm modes, I think it is easy to extend it with different extensions, i.e. adding inline.gfmwithtex = { math: MYCODE } and inline.pedantic = { math: noop } etc.
   • the URL for TeX rendering could be involved only in the setup of such inline.gfmwithtex object and fetched from the options.
   • In Firefox a good place to store those preferences is the built-in settings system, but I do not know how Chrome works.
2. I think the extra complication of a "plugin" system (inside an extension!) is not worth it to be honest. The use of "variants" of markdown as outlined in point 1 would, in my opinion, satisfy most users and allow fair flexibility.

I understand your concerns about modifying marked.js and I must say I was a bit surprised myself when I saw it was not the "ufficial" one. But Javascript is a very flexible language...there could be a way of wrapping it into another object and add features in the wrapper...just a dream though, no concrete ideas so far on how to do this.

[adam-p]

If you use Chrome, I just put out a release that has a TeX easter egg:

1. Open the Markdown Here options page.
2. Open the Developer Tools console panel (shift+ctrl+j or whatever).
3. Execute this: localStorage.setItem('ilikemath', 'true')
4. Try a Markdown Toggle with some mathy stuff between dollar signs: $\Delta$
   • If it doesn't work at first, try to reload your GMail

Proper TeX support still needs a bunch more work, but I had to push out a bugfix release last night, so I decided to sneak this in. Let me know if you have any problems or whatever.

Also, @bordaigorl, can you sometime give me a cool TeX example that I can use in samples and screenshots? Thanks.

[bordaigorl]

I would go with these examples
http://www.mathjax.org/demos/tex-samples/
they do not render as nicely with google charts but it's hard to do better without javascript.
Codecogs' renderer does a better job with some examples.

Will settings in Firefox be supported any soon?

[adam-p]

Firefox settings are totally implemented, as of a few days ago. I'm waiting for the currently-queued Mozilla review to finish -- I'm currently 4th in the queue, so that should be soon. (Cross your fingers that Markdown Here finally gets approved.) I'll put out a new release as soon as the review is finished.

You can pull head code if you want to take a look. (But if you've seen the Chrome settings... it looks the same.)

[adam-p]

Version 2.6.0 has bee released with TeX support. Options have been added to Firefox and Thunderbird, so they fully support it as well. Take a look at the options page to enable it.

Big caveat: The new version has just entered the Mozilla review queue, so it could be between a week and a month before it's actually available to install/upgrade.

@bordaigorl: Thanks for helping to implement this.

[adam-p]

Update regarding Firefox/Thunderbird installation: It looks like you can get the latest version of Markdown Here from the view-all-versions page:

https://addons.mozilla.org/en-US/firefox/addon/markdown-here/versions/

[bordaigorl]

This is great news! I just tried the latest version and it works great.
I like the template-like math setting. A small improvement could be a couple of buttons setting the Google Chart and CodeCogs templates (instead of "Reset to Default").

Thank you very much for the effort and enthusiasm you are putting in this brilliant extension!

[bordaigorl]

Just a quick comment: the info-leak issue should actually not occur if one uses the https version of Google Charts (as in my initial post)...that should fix it, shouldn't it?

[adam-p]

It fixes one sort of leak (eavesdropping on the network connection), but the one I was/am more concerned with was/is: Your formula is being sent to Google (or whatever rendering service you use).

If you use Gmail, then maybe that isn't a big deal -- although you're still sending it to a different business unit in a different data centre, with different data storage, retention, and security policies. But if you're using any other mail provider (and so is your recipient), then you're sending information to a third party that wouldn't otherwise be part of the equation.

I still think it's necessary for users to explicitly acknowledge and accept that "leak".

(For the record, https is used by default.)

[bordaigorl]

Good point!

[joanpau]

I though that this discussion in CommonMark (a temptative specification of a unified Markdown syntax)
could be relevant here:
http://talk.commonmark.org/t/mathematics-extension/457