# Dollar sign used as currency renders incorrectly in Android app

I came across an answer today on Electronic Engineering: How to go from newbie to manufactured? in the Android app. The answer gives monetary figures in (presumably) USD using the dollar sign. When viewed in the app, the rendering of the answer is incorrect:

I then tried viewing the question in a few other ways, all of which rendered correctly:

Firefox 32.0 on Android (mobile site):

Firefox 32.0 on Android (desktop site):

Chrome 37.0 on Android:

Firefox 32.0 on Windows 7:

There seems to be different recommended ways of writing the raw dollar sign on different SE sites from the searches I've done (writing it raw, escape each with a backslash, surround in backticks, just write it in maths mode with backslash-dollar-dollar-backslash-dollar), but I think that the app should still render consistently with other browsers.

Using Stack Exchange Android app version 1.0.48
Motorola Moto G (XT1032)
Android version 4.4.4

• Ha this is awesome, looks like our MathJax renderer is being over-eager. Taking a look. – Kasra Rahjerdi Sep 15 '14 at 15:53
• Great. I kinda like that it only messes up the posts of Americans who assume that there's only one type of dollar in the world though... – Xcodo Sep 15 '14 at 16:04

As of last night, the current experimental version of the API (which the app uses) returns both MathJax and EscapedMathJaxDelimiters under markdown_extensions for sites that require using \$ to render MathJax (currently only EE and Code Review), so as of the next app update the sites and app will render situations like this the same way. So I've spent a good chunk of today playing around with this and have reached two conclusions: 1. The error displayed on the Android app also happens on most MathJax enabled sites, but not on EE. 2. I can't really come up with a good way of fixing this. The reasoning for (1) is that EE uses different MathJax settings than most of our other sites, the value we have set up for inlineMath in the MathJax setup for EE is [ ["\\$", "\\$"] ], on most sites that have MathJax enabled it is instead [ ["$", "$"], ["\\\$$","\\\$$"] ]. Since the Android application doesn't have access to the custom settings the sites are using to differentiate their MathJax extensions, we use a combination of all of them. The Android app's value for inlineMath is [ ["$", "$"], ["\\$", "\\$"], ["\\\$$","\\\$$"] ], a combination of the one that is used just on some sites (EE and a couple others) and the normal one. This is why the screenshots you posted show it working incorrectly in the Android app, but not on any regular webpage views of the question. The app is incorrectly assuming everything between the dollar sign on the "47" and the dollar sign on the "747" is supposed to be MathJax formatted. What makes this worse is if you go on one of the sites with the default inlineMath attribute like math.stackexchange.com, you can recreate this issue. If you post anything that includes two dollar signs all of the text gets parsed by MathJax, so the fact that the answer in question isn't being incorrectly rendered on your other screenshots is actually a weird artifact of EE having different site settings than most of our other sites. Here's a screenshot from my local development setup, which is currently set to emulate the settings of math.stackexchange.com: MathJax supports escaping of inlineMath attributes, by changing the dollar signs in text to \$ and I've played around with doing different regex search and replaces to do things like "If there is text between two dollar signs and it looks like regular text, not LaTeX, switch the dollar signs to escaped dollar signs" but I've so far been unable to figure out a way to reliably do this that doesn't mess up actual attempts at using MathJax.
• Hrm, why can't you retrieve the inlineMath tokens per-site in the app? – ThiefMaster Sep 17 '14 at 20:55
• @ThiefMaster the attribute that's going into inlineMath on the webpages is retrieved from a database table that each site has which also includes lots of other site-settings. Those site settings are not available via the API (and I don't think they should be). – Kasra Rahjerdi Sep 17 '14 at 20:58
• @ThiefMaster each site currently has 981 possible settings, and we add/remove settings from that list very regularly. Adding it to a public API would be a huge pain. I think we're going to end up adding a new markdown_extension to the /sites call for these special-cased sites. – Kasra Rahjerdi Sep 17 '14 at 21:01
• @KasraRahjerdi Wow, thanks for all the time you put in to that. I thought it would just be we bug fix! From what you say, I think adding a new markdown_extension option to the public API seems right the right way to go - the markdown settings information is required for any user of the API to be able to parse or render the output consistently with the website. – Xcodo Sep 18 '14 at 12:45