RE: [Axiom-developer] axiom opportunity

[Page, Bill]

On Tuesday, April 25, 2006 12:50 PM Bob McElrath wrote:
> ...
> Bill Page wrote: 
> > I think jsMath as an alternative to MathML has continued to
> > evolve and mature very rapidly:
> > 
> > http://www.math.union.edu/~dpvc/jsMath/changes.html
> > 
> > It uses just a subset of LaTeX embedded in HTML.
> > 
> > For use in a graphical user interface based on web browser
> > technology I still consider jsMath quite superior to MathML
> > in ease of use, compatibility and even performance.
> 
> Uh...Bill..."performance"?  I've done quite a few benchmarks 
> and jsMath is a dog when it comes to speed.

Could you point me to some examples of these benchmarks?
Identical pages rendered as MathML and jsMath? Are there
some cases that are especially bad? Worse case?

I have not done any rigorous tests but my experiments using
FireFox 1.5.0.2 on Windows makes me feel jsMath has the lead -
although both seem likely "fast enough" for the kinds of uses
I have in mind, e.g. rendering a single "page" of HTML online -
either from a web site or from a local copy of Axiom. Such a
"page" might contain say at most 10 equations and maybe 20
embedded symbols.

When working with the MathML output of tex4ht I was astounded
by the enourmous size of the MathML pages generated for quite
simple Axiom output. It seems to me that much of the performance
is dominated by the network and (perhaps) XML parsing.

> Davide and I have been discussing ways to cache jsMath output
> to improve speed.  (He sent me an experimental cache a few
> days ago that I haven't had a chance to look at yet...)
> jsMath requires the browser to draw each sub-component of an
> expression in a hidden <div> so that it can measure its metrics.
> This is very slow compared to just reading the metrics from the
> font.
>

Doing what you can to cache this information makes sense to
me. Even sending jsMath itself down the line takes a serious
amount of time and we should be careful to make sure the
browser is caching it.
 
> jsMath is a good transition tool, and Davide hopes to evolve 
> it to have a MathML output mode, but it is by no means fast.
>

Actually in the most recent "future work" he has mentioned
doing the opposite - MathML input with jsMath rendering. Even
this makes sense to me.
 
> In the long term the solution to math on the web is MathML.

In spite of all the effort, I remain sceptical.

> I think the sooner we (and the world) embrace this fact, and
> stop spending all our efforts on stop-gap solutions, the better
> we will be and the quicker we can advance.

What we need now to advance is considerably simpler - just
a reliable, simple and compatible way of rendering LaTeX
equations and symbols in HTML. Even rendering LaTeX as graphics
on the server, embedding them in HTML and caching the result
is "nearly good enough".

> Furthermore mathematics needs huge character sets.  Moving
> to unicode (implied by the move to MathML) will be a huge boon
> to math since we can use all kinds of characters and operators 
> outside of ASCII.
> 
> The Really Big Problem with MathML is fonts.  FYI the STIX 
> fonts project plans a beta release in the next few weeks:
> http://www.stixfonts.org/. The addition of this font, and its
> distribution with browsers will remove most of the problems
> with MathML, and it will begin to take off since every
> Firefox/Mozilla user will be able to "see" MathML without
> jumping through the extra hoops of installing fonts, as is
> currently required.

I am not going to hold my breath! :)

Anyway what prevents jsMath also from benefiting from these
new fonts?

> Axiom should jump on this opportunity.
> 

On the contrary, I think Axiom should continue to make use of
the most expedient solution available now. Axiom needs a better
user interface now. I think a possibly (much?) better interface
in the future (even the relatively near future, say 2 years) is
likely to be too late.

Regards,
Bill Page.