Re: Review of WWW Mathematics Browsers, MathML and HTML.
Would it be possible for you to make available the mml that you used in
the tests? It is hard to really draw a judgement on comments such as
> Semantic difficulty is possibly implied by the excessively
> large parentheses on Es(ws),
unless the mathml input is available.
> but appears to require upright to be explicitly specified as well as
> bold to behave in standard TeX fashion,
I believe that is the correct behaviour. (Also in TeX it is perfectly
possible to switch to bold without being upright. eg \boldsymbol or \bm
in latex). You are probably refering to the behaviour of \bf but that
just selects a bold upright roman font for letters and doesn't make
symbols bold at all, which probably isn't the semantics you would want
for a fontweight="bold" attribute!
In many ways of course it is fairer to compare tth with using gif
images. (Which I know that you are quite willing to do:-) In that
they both produce something that is essentially `read only'.
MathML, even presentation MathML as tested here, is passing the
mathematics to the browser in some half way sensible format
so that it may be possible (eventually:-) to cut and paste sub
expressions and do searches. This does of course have an impact on the
amount of work that needs to be done in the browser. MathML technology
is in its infancy and improving. I do not doubt your conclusions that
_today_ a typical user (whatever that may mean) may not want to pay
the price in terms of speed. But with a bit of luck things may be better
> A difficulty all browsers are going to have with MathML is that the
> entity list is immense and there are numerous synonyms, so supporting
> the whole standard is going to be tough and there is no accepted subset
> choice that can be regarded as a de-facto standard.
It would be possible to make a list of those entities that could be
mapped to the glyphs (or combinations thereof)in the ISO latin-1 and
adobe symbol font encodings. But probably trying to define such a core
minimal set would not be useful as it is hard to give restrictions when
authoring based on the capabilities present on a remote browser.
Probably better would be for the browsers to accept all the entities but
just do something recognisable if they do not have a suitable font
available. (ie outputting the entity name in red would be preferable to
just silently skipping over the symbol).
The whole question of what symbols are available, and what entities
should point at them will probably have to be looked at again in the
future if the STIX proposal (or something like it) succeeds in getting
an agreed set of mathematical symbols into unicode.