Update: MathJax in an Android app

[Thomas Leathrum]

I have added a new feature to my MathJax app for Android, in a way that provides a sort of intermediate solution for providing the ability to use a local MathJax installation in the app.  What I did was provide a way to modify the MathJax URL.  The new feature is a "Configure" button in the app which brings up a dialog box with a text field where you can modify the URL.  Buttons provide two preset URLs:  the MathJax CDN latest URL and a local loopback URL.  Using a local MathJax installation does require a second app install, though -- in particular, a local HTTP server.  I like the PAW Server app by Fun2Code (for its strong support of PHP and MySQL), but there are a few other HTTP server apps in the Google Play store -- pick your favorite. Once you have the server app installed, download and install MathJax in the server app's HTML directory, in a subdirectory called "MathJax", and then the local loopback address will point to the local install.  Start the server app first, then the MathJax app, make sure the URL is configured for your local install, and the MathJax will render even if you are offline.

The Android source and installation APK are available at:
http://cs.jsu.edu/wordpress/?p=488

This is not a final answer to using MathJax locally, though -- I still want to get MathJax working from the app's assets directory so that no second app or extra install is needed.  I just haven't had a chance to finish that work yet.

-- This updates the discussion at:
https://groups.google.com/forum/#!searchin/mathjax-users/mathjax$20in$20an$20android$20app/mathjax-users/6JANlr-pFIQ/VO3t7CcgoMAJ

[Dr. Dayal D. Purohit]

I like the info about local server. That can be very useful in other applications. However for the sake of displaying local math using local copy of MathJax, it is adding up extra resources.

All we need is a nice minimized version of MathJax. I have read that it can be in the order of 1.5MB in size after removing the docs and such.

d^3p

[Thomas Leathrum]

I did say that the modifiable URL was not the final answer.  Just to keep you updated on my progress, I sorted through the diagnostics last night and figured out what I need to do for an app using a local copy of MathJax packaged with the app, no need for a server app.  I have a working prototype, but need to do some tweaking before I post download links.  I have cut out enough from the MathJax directory to get it down to about 2Mb.  Interestingly, the WebView seems happiest with the OTF fonts, cutting out the others saved a lot of space.

[Davide P. Cervone]

Tom:

The page

https://github.com/mathjax/MathJax/wiki/Shrinking-MathJax-for-%22local%22-installation

gives information about what can be removed to get a "minimal" MathJax installation.

Davide

[Thomas Leathrum]

Davide:

I had already been following these instructions -- the only thing I hadn't sorted through was the config directory.  I have done that now (and got rid of most of it, but had to keep MMLorHTML.js), so now the MathJax directory is under 1.5Mb.  I think that's good enough for this purpose.

[Davide P. Cervone]

OK, sounds good. I think that is a small as you can reasonably get it.

Davide

[Dr. Dayal D. Purohit]

I have downsized to 1.37MB. I believe that it can be brought down further if one specific device is targeted and only one specific input and one specific output is supported.

d^3p

[Thomas Leathrum]

I was able to tweak the configuration enough to get rid of MMLorHTML.js and thus delete the config folder altogether, so I am now at 1.42Mb.  I am keeping things like the license and readme files in the main directory, though, which probably accounts for these few 10's of Kb.  (My ultimate goal is to package this up for Google Play, so I want to keep those files in place.) 

The one thing I have never been able to get working in the app is the MathJax contextual menu.  It probably has to do with whether the WebView lets HTML divs behave the way the menu is supposed to behave (a bit of research indicates that the problem may be with the CSS position:fixed property, but the fixes I have seen using <meta> tags don't seem to work).  I can either keep trying to track down the problem or give up and disable the menu altogether -- if I take the latter approach, I can delete the menu scripts, which may save a few more Kb.

[Dr. Dayal D. Purohit]

I think contextual menu should be disabled for touch devices. First of all I have never seen it work, instead when math is touched, it highlights it like a clickable zone with different color, and that does not look good. What is there anyway in context menu, set the renderer, I think you should just fix it as html-css or svg in devices, also the menu allows the viewer to view the raw math, I think the viewer should have no reason to see raw math, they should just be happy with rendered math. Also math-zoom, I think it is useless when you can use regular zoom on the entire content. I have discovered a neat trick to maginify and still keep content in frame as in IPhone or IPad. Set the viewport to device dimension and set min and max scale to 1 in the html. Then do the zoom in code and redraw. 

Knowing what you feature you are allowing will certainly reduce a lot of unnecessary stuff. I think it can be brought below 1MB easily. I have close to 300 files in my package now. But some have reduced to much below that.

d^3p

[Thomas Leathrum]

The main thing I would want to keep from the contextual menu is the math zooming.  Pinch-to-zoom doesn't work in the WebView, either.

[Dr. Dayal D. Purohit]

The way I have it by min and max scale at 1, the pinch to zoom won't work. And, that is by design. If you allow pinch to zoom, things will zoom, but what can't fit will be out of view and horizontal scroll will be necessary.

If you have the max scale more than 1 for your view port and you have set UseWideViewPort(true) and setBuiltInZoomControls(true) on the webview, the pinch to zoom will work.

d^3p

[Thomas Leathrum]

Thanks for the tip on the WebSettings -- I had already tried setSupportZoom(true), and that didn't work, but I didn't dig any deeper.  It turns out that I get the behavior I want by just setting setBuiltInZoomControls(true) without any of the other settings.  With just this, I can pinch-zoom and the rendered expression recenters itself at the top of the WebView.

I did discover that I was testing with an older version of MJ.  (I realized this when I tried to enable and test SVG output, and it wasn't there.)  So I updated.  By taking out a few extra extensions, I got the HTML-CSS version down to 1.40Mb, the SVG version to 1.43Mb (even with deleting the font directory entirely).  I wasn't happy with the SVG output because to me the glyphs looked too heavy, and it takes a bit more space anyway, so I'm sticking with HTML-CSS with the OTF fonts.

Anyway, I'm closing in on a finished app.  Two, actually -- the lightweight version that uses online MJ with a configurable URL, and the heavier one with MJ built into the app assets.  (Plus a third one I have been working on, unrelated to MJ, that calculates derivatives symbolically.)  I figure different people will have uses for both versions of the MJ app, so there's no reason not to make both available.

[Dr. Dayal D. Purohit]

I am happy about your progress. I think HTML-CSS output is much better than SVG. Not sure why the need for SVG to render math.

Please check out my dynamic math for derivatives at the following link:

http://mathematics.jds.com

The last 15 or so deal with derivatives - polynomials, rational, exponential, logarithm, and the trignometric functions. The code is in Tex.

also at

http://www.jds.com/integralcalculus.asp 

where there are a few integral by substitution. Here the code is in MathML.

All examples are created dynamically and randomly, yet in a calculated manner.

Thanks,

d^3p

[Thomas Leathrum]

I can see lots of advantages of SVG:  no fonts needed at all for MJ (all glyph data are in the JavaScript), fully standards-based XML (so shouldn't be any problems between browsers, as long as they support enough of SVG), compatible with next-gen HTML5 (for future browser standards).....  I just don't like the look of the SVG glyphs in MJ, because they're heavier than the OTF or WOFF glyphs.  That's a matter of personal taste, though, not long-term advantage.

[Thomas Leathrum]

For the very latest on these apps:

http://cs.jsu.edu/wordpress/?p=498

I will put this link into a new thread soon so that the info about the new standalone app doesn't stay buried in this thread.

[Davide P. Cervone]

> I wasn't happy with the SVG output because to me the glyphs looked
> too heavy, and it takes a bit more space anyway, so I'm sticking
> with HTML-CSS with the OTF fonts.

You should be able to use the WOFF fonts, I think, which should be a
little smaller for you.

As for the SVG, there is a configuration parameter (blacker) in the
SVG block that is currently set to 10 that you could reduce or set to
0 if you want to lighten the fonts a bit. Try that out and see if
that looks better for you.

Davide

[Thomas Leathrum]

On Wednesday, August 1, 2012 3:37:30 PM UTC-5, Davide Cervone wrote:

You should be able to use the WOFF fonts, I think, which should be a  
little smaller for you.

I tried the WOFF fonts from within the assets directory, and I got file-not-loading errors and no math output.  Not sure why, but OTF works and WOFF doesn't.  May have to do with the "file:" URLs used in loading stuff from the assets directory.
 

As for the SVG, there is a configuration parameter (blacker) in the  
SVG block that is currently set to 10 that you could reduce or set to  
0 if you want to lighten the fonts a bit.  Try that out and see if  
that looks better for you.

Aha -- I didn't know about that parameter.  Very clever!  I will check that out and see what looks best.  (Fun with SVG -- I wonder what happens if I set blacker to a negative value...)

[Davide P. Cervone]

> I tried the WOFF fonts from within the assets directory, and I got
> file-not-loading errors and no math output. Not sure why, but OTF
> works and WOFF doesn't. May have to do with the "file:" URLs used
> in loading stuff from the assets directory.

Might also be that the Android browser's version of WebKit doesn't
support it (WebKit was the last to implement it, as I recall).

> As for the SVG, there is a configuration parameter (blacker) in the
> SVG block that is currently set to 10 that you could reduce or set to
> 0 if you want to lighten the fonts a bit. Try that out and see if
> that looks better for you.
>
> Aha -- I didn't know about that parameter. Very clever! I will
> check that out and see what looks best. (Fun with SVG -- I wonder
> what happens if I set blacker to a negative value...)

Since it is a path width, I expect it will either throw an error, or
act like 0.

Davide

[Thomas Leathrum]

On Wednesday, August 1, 2012 4:03:04 PM UTC-5, Davide Cervone wrote:

> I tried the WOFF fonts from within the assets directory, and I got  
> file-not-loading errors and no math output.  Not sure why, but OTF  
> works and WOFF doesn't.  May have to do with the "file:" URLs used  
> in loading stuff from the assets directory.

Might also be that the Android browser's version of WebKit doesn't  
support it (WebKit was the last to implement it, as I recall).

A bit of googling indicates that there are some general problems with @font-face on Android, such as only supporting TTF and OTF, if it works at all.  WOFF may be hopeless here unless this situation changes.  But OTF works, so no biggie.

[Thomas Leathrum]

On Wednesday, August 1, 2012 3:37:30 PM UTC-5, Davide Cervone wrote:

As for the SVG, there is a configuration parameter (blacker) in the  
SVG block that is currently set to 10 that you could reduce or set to  
0 if you want to lighten the fonts a bit.  Try that out and see if  
that looks better for you.

"blacker: 0" is better, but still heavier than OTF.  It is especially noticeable when not zoomed at all -- there may be a screen resolution issue here, too, but the glyphs are heavy enough that the characters look fuzzy and even seem to touch in a couple of places.  I have an example with "e^{-x^2}", and the "-x^2" part looks like all three characters are blending together.  But when I zoom in, they separate out just fine.  For now, I will stick with OTF, but I will re-evaluate later.  I figure I will need to update the app when MJ2.1 comes out anyway.

[Davide P. Cervone]

The SVG output handle the characters as paths, not as text (that's why
you don't need any fonts for it), and that means that they are anti-
aliased as geometric paths, not as text. That does produce a slightly
fuzzier look, as the path anti-aliasing is not optimized for fonts. I
suspect that is what you are seeing.

Davide

[Dr. Dayal D. Purohit]

That is fantastic. Your mathjax package contains 23 more files than I have. But the difference in size is minimal. Mine is 1.35MB compared to your 1.4MB. I got rid of most of the files in the autoload directory as Davide had suggested in another thread.

Also, I have the config directory that contains the singleton tex-ams_html.js file. Not sure why you got rid of the entire config directory. When is that directory used anyway?

You have couple of extra dirrectories off \jax\output\html-css\fonts\tex . Davide had mentioned that you could delete directories greek, size1, size2, size3, size4, winie6. Not sure about the typewriter.

Also, I would like to know if i can delete \jax\output\html-css\fonts\tex\stix font directory. 

d^3p

[Dr. Dayal D. Purohit]

Also, I have kept the woff and got rid of otf. You have the other way around. I think Davide had said woff should be sufficient.

d^3p

[Dr. Dayal D. Purohit]

woff works fine in ics and also in jb. I have not compiled it for IPad, but I assume it should work there too. I am having some trouble downloading Mountain Lion for some reason, it seems stuck while downloading.

d^3p

[Dr. Dayal D. Purohit]

Downloaded and installed your app. It works fine in ics and jb without net connection.

d^3p

[Thomas Leathrum]

I just tested WOFF again, same result -- lots of file-not-loaded errors, math processing error message appears instead of math output.  I am working in Honeycomb -- maybe the problem is actually fixed in ICS, but I need to think about the older platforms too (I am compiling with minimum SDK level for Froyo).  I'm going to stick with OTF because I know it works.

[Thomas Leathrum]

On Wednesday, August 1, 2012 8:55:45 PM UTC-5, Dr. Dayal D. Purohit wrote:

Also, I have the config directory that contains the singleton tex-ams_html.js file. Not sure why you got rid of the entire config directory. When is that directory used anyway?

The configuration files in the config directory are what you load when you use "?config=..." in the URL -- one thing I figured out in my diagnostics is that these URL parameters are utterly incompatible with the "file:///android_asset/..." URLs, so you need to use <script type="x-mathjax-config"> tags in the HTML instead.  If you do the configurations that way, nothing in the config directory is used anyway, so you can delete the whole directory.

[Thomas Leathrum]

If you have an iPad, have you tried running the MathJax app using Myriad Alien Dalvik?  That is supposed to provide a compatibility layer so that APKs can be installed and run in iOS.  If it works, that means no recompiling needed for it to run on the iPad.  I don't think Apple lets you compile Java/Android source into native iPad binary anyway.

[Thomas Leathrum]

Davide -- is it possible to tweak the "shape-rendering" property in the SVG output with the "crispEdges" value to maybe clear up that fuzziness in the small sizes?  Or does that introduce too much of a performance hit?

[Frédéric WANG]

On 02/08/2012 06:46, Thomas Leathrum wrote:

Davide -- is it possible to tweak the "shape-rendering" property in the SVG output with the "crispEdges" value to maybe clear up that fuzziness in the small sizes?  Or does that introduce too much of a performance hit?

The testing framework uses the configuration option

"SVG" : {
  styles: {
    // Disable antialiasing for SVG rects
    rect: {
      "shape-rendering": "crispEdges"
    }
  }
}

which improves the rendering and does not seem to decrease performance. If I remember well, this property didn't seem to improve the rendering for paths (in particular the text drawn as path).

I'm wondering if the SVG output would look better if MathJax fonts inside normal <text> were used instead. Of course that would require fonts instead of path data but that also has some advantages. So maybe providing this as an option? In that case, perhaps "text-rendering" would help to improve the quality.

See also https://groups.google.com/forum/?fromgroups#!topic/mathjax-dev/9M2drjjsJBw

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

[Davide P. Cervone]

> I got rid of most of the files in the autoload directory as Davide
> had suggested in another thread.

Note that this will disable those features, so you need to be careful
not to use them. But if your input is TeX rather than MathML, you
won't need most of them. The important ones for TeX are mtable.js and
multiline.js (if you are using automatic line breaks), and maction.js
and menclose.js if you use the extensions that call on those (e.g.,
the cancel extension needs menclose).

> Also, I have the config directory that contains the singleton tex-
> ams_html.js file. Not sure why you got rid of the entire config
> directory. When is that directory used anyway?

Tom has already indicated that it is the config=filename that causes
these to load. You can also add a config array to your configuration
that would cause files from this directory to load. The combined
configuration files contain copies of the compressed code that is also
in the jax and extensions directories, so if you use the combined
configuration file, you can remove the originals. But for local
access in an app, there probably is not much advantage in that (it
helps for network access, but not really for local file access). So I
think Tom's approach of putting the in-line configuration that loads
the jax and extensions individually is probably best. Then the config
directory can be removed entirely, as he has done.

> You have couple of extra directories off \jax\output\html-css\fonts

> \tex . Davide had mentioned that you could delete directories greek,
> size1, size2, size3, size4, winie6. Not sure about the typewriter.

Typewriter is for the \tt font. If you don't use that, you can remove
it. The Greek and WinIE6 directories are only for IE, so you won't
need those. If you don't use \cal, \frak, \sf, or \scr you can get
rid of the Caligraphic, Fraktur, SanSerif, and Script directories as
well (and can remove the corresponding OTF fonts). But if you forget
and try to use these, you will get errors, as there is no way to tell
MathJax that these files are not there.

> Also, I would like to know if i can delete \jax\output\html-css\fonts
> \tex\stix font directory.

I don't know if you can install STIX on Android or iOS, but if not,
then sure, go ahead. If you want to force the use of MathJax fonts
even if STIX is available, then remove the directory, but be sure to
configure availableFonts: ["TeX"] so that MathJax won't try to use
STIX fonts.

Davide

[Davide P. Cervone]

Fred has already mentioned how you could add that yourself. I haven't
done much with it, but my few experiments didn't show any difference
with it set or not. I don't remember now how many browsers I tried.
Fred has had success in his use of it for rectangles, but I think it
is browser dependent, and it may not be implemented for all object
types, as he suggests (e.g., not paths). If you try it out and have
success, I would be interested in the details.

Davide

[Thomas Leathrum]

Fred - based on your suggestion, I played around some with this setting.  I finally saw a real difference when I replaced "rect" with "path".  With that, I actually had to set "blacker" to a higher value or dashes disappeared in small sizes.  With "blacker: 40" it looked pretty close to the weight of the OTF, but the edges were rougher on curvy symbols, almost looking like the pixel-y image fonts.  Setting "shape-rendering: geometricPrecision" and "blacker: 0" smooths out the edges but still leaves glyphs a bit too heavy.  In all of these cases, the OTF still looks better.

[Frédéric WANG]

OK, that's great to know it works.

I use this for rect because the test suite contains many tests based on
comparison of rectangles. In practice, I'm not sure there are many
rectangles in "normal" formulas.

I didn't notice a real difference for paths probably because I didn't
try with small sizes and also didn't know about this blacker option.

If I remember correctly, "shape-rendering" is well implemented among
browsers while that's not really the case for "text-rendering" which is
more browser dependent (and didn't seem to help anyway).

--
Fr�d�ric Wang
maths-informatique-jeux.com/blog/frederic

[Thomas Leathrum]

On Thursday, August 2, 2012 9:02:46 AM UTC-5, Davide Cervone wrote:

I don't know if you can install STIX on Android or iOS, but if not,  
then sure, go ahead.  If you want to force the use of MathJax fonts  
even if STIX is available, then remove the directory, but be sure to  
configure  availableFonts: ["TeX"] so that MathJax won't try to use  
STIX fonts.

Davide -- Fred has done some work on this:

https://addons.mozilla.org/en-Us/android/addon/mathml-fonts/

But this is for Firefox Mobile, and I don't think it makes Stix fonts available for an in-app WebView.  I haven't seen any other work on making Stix available for Android.

[Davide P. Cervone]

> I'm wondering if the SVG output would look better if MathJax fonts
> inside normal <text> were used instead. Of course that would require
> fonts instead of path data but that also has some advantages. So
> maybe providing this as an option? In that case, perhaps "text-
> rendering" would help to improve the quality.

It would have the advantage of using the antialiasing specifically
optimized for fonts. But it has some important drawbacks as well.
Currently, SVG output doesn't use web-based fonts, so it doesn't have
any of the problems that @font-face introduces. One of the most
fragile parts of MathJax's HTML-CSS output is the detection of when
the web fonts are actually available once they have been requested
(MathJax has to wait for that in order to measure the results
properly). This has been a constant source of trouble for the HTML-
CSS output jax, and I am thrilled not to have it be part of the SVG
output. Another issue is that, with the paths rather than fonts,
MathJax knows the sizes of what it renders exactly, without having to
ask the browser to measure it, since it knows the sizes of the paths
it is drawing. If we were to switch to text rendering, then we need
to ask the browser to measure the results. Historically, this has
been one of the main sources of performance problems, particularly in
IE. Of course, there are different mechanisms for doing that in SVG,
and I haven't done any testing to see whether these have the same
performance problems as the corresponding HTML-CSS versions, but being
able to know the size of things without measuring was a real advantage
in the SVG output code. I would hate to reintroduce that problem.
Finally, not having to depend on the browser for text rendering means
that the SVG output is browser independent, and going to the system
text routines (whose sizes vary from browser to browser) would mean
that is no longer the case. That would be a significant loss, in my
opinion.

Davide

[Frédéric WANG]

On 02/08/2012 16:41, Thomas Leathrum wrote:
> Davide -- Fred has done some work on this:
>
> https://addons.mozilla.org/en-Us/android/addon/mathml-fonts/
>
> But this is for Firefox Mobile, and I don't think it makes Stix fonts
> available for an in-app WebView. I haven't seen any other work on
> making Stix available for Android.
>

This add-on does not really install the fonts but make them available as
resources in Firefox Mobile and automatically attaches a stylesheet with
@font-face rules to use these fonts. It works for the MathML output but
I don't think MathJax can detect them for other output modes. From what
I have heard, it is hard to install fonts on Android (I remember this
bug, which is one of the reason for the add-on to exist:
https://bugzilla.mozilla.org/show_bug.cgi?id=709159)

[Frédéric WANG]

On 02/08/2012 16:47, Davide P. Cervone wrote:
>> I'm wondering if the SVG output would look better if MathJax fonts
>> inside normal <text> were used instead. Of course that would require
>> fonts instead of path data but that also has some advantages. So
>> maybe providing this as an option? In that case, perhaps

>> "text-rendering" would help to improve the quality.

>
> It would have the advantage of using the antialiasing specifically
> optimized for fonts. But it has some important drawbacks as well.
> Currently, SVG output doesn't use web-based fonts, so it doesn't have
> any of the problems that @font-face introduces. One of the most
> fragile parts of MathJax's HTML-CSS output is the detection of when
> the web fonts are actually available once they have been requested
> (MathJax has to wait for that in order to measure the results
> properly). This has been a constant source of trouble for the

> HTML-CSS output jax, and I am thrilled not to have it be part of the

> SVG output. Another issue is that, with the paths rather than fonts,
> MathJax knows the sizes of what it renders exactly, without having to
> ask the browser to measure it, since it knows the sizes of the paths
> it is drawing. If we were to switch to text rendering, then we need
> to ask the browser to measure the results. Historically, this has
> been one of the main sources of performance problems, particularly in
> IE. Of course, there are different mechanisms for doing that in SVG,
> and I haven't done any testing to see whether these have the same
> performance problems as the corresponding HTML-CSS versions, but being
> able to know the size of things without measuring was a real advantage
> in the SVG output code. I would hate to reintroduce that problem.
> Finally, not having to depend on the browser for text rendering means
> that the SVG output is browser independent, and going to the system
> text routines (whose sizes vary from browser to browser) would mean
> that is no longer the case. That would be a significant loss, in my
> opinion.
>
> Davide
>

Thanks for the information, Davide.

[Thomas Leathrum]

On Thursday, August 2, 2012 9:53:45 AM UTC-5, fred wrote:

This add-on does not really install the fonts but make them available as
resources in Firefox Mobile and automatically attaches a stylesheet with
@font-face rules to use these fonts. It works for the MathML output but
I don't think MathJax can detect them for other output modes. From what
I have heard, it is hard to install fonts on Android (I remember this
bug, which is one of the reason for the add-on to exist:
https://bugzilla.mozilla.org/show_bug.cgi?id=709159)

Installing system fonts on Android requires root access, which can be nontrivial depending on your device.  There are font packs available in the Google Play store, but they tend to be app-specific, not system font installations.  I suppose we could lobby for an Android font pack specifically for Firefox Mobile, Opera Mobile and the stock Chrome-based browser, to avoid the root issue.

[Frédéric WANG]

I just searched "font" on the Android issue tracker and found many issues on missing Unicode support:

https://code.google.com/p/android/issues/detail?id=5925
https://code.google.com/p/android/issues/detail?id=10246
https://code.google.com/p/android/issues/detail?id=507
...

We could probably suggest them to add more math fonts in the default installation, such as STIX fonts.

If the Android font packs do not install fonts on the system, I guess they use something similar to my add-on, based on Web fonts? BTW, my search also returned many issues about Web fonts.

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic