The entities defined in mozilla's mathml.dtd are not in line with the w3c mathml entities http://www.w3.org/TR/2000/WD-MathML2-20000211/byalpha.html . Many w3c entities are not defined (eg isin (w3c) which is equivalent to Element (w3c and moz)) and other mozilla entities are not w3c (eg egr (moz only) instead of epsi (w3c only) - epsilon). My particular concern is that I am helping Eitan Gurari to make his tex4ht (la)tex to xhtml/mathml convertor work with mozilla.... If it would help I would be willing to make a new mathml.dtd for mozilla including all the w3c mathml entities. (Probably though a `real' programmer could write a little script to convert the above page automatically very quickly - it will take me a little longer.)

Entitities that are used are MathML 1.0 conformant (a spec). What you are suggesting is that they should be MathML 2.0 conformant (a draft still in flux). Updated title to reflect this.

I see. Thanks for explaining that. Not quite sure what to do re tex4ht...

I already wrote a script that will produce mathml.dtd from this byalpha.html (see the mathml/tools directory). Is there a large difference between the two lists of entities? Or in other words, is it worth moving to the new list now?

In light of Robert Miner's message on the newsgroup, may I suggest that we wait until 1) the new mathml2 entity list is out and 2) the xhtml namespace bug is fixed (current xhtml pages have a html4.0 namespace) -this should be fixed soon (its a PDT-). Then as soon as you make the changes I'll put out mztex and mzlatex (Eitan Gurari's tex4ht modified to be mozilla friendly). And, yes, there are significant changes.

This bug has not been touched for more than nine months. In most cases, that means it has "slipped through the net". Please could the owner take a moment to add a comment to the bug with current status, and/or close it. Thank you :-) Gerv

MathML 2 is a proposed recommendation as of 8 Jan 2001, see http://www.w3.org/Math/

Hopefully, this should be fixed by the M0.9 time frame. I now have the updated DTD, but to enable it requires sync.ing with the MathFont Encoding Tables so that the new Unicode points agree with the glyphs in the fonts. I am not getting much feeback on the encoding tables (they are tedious and undertstandbly people stay away from them). I may have to settle with whatever iteration I may reach at M0.9.

Would it be possible to include a test version of the new tables in Mozilla 0.8.1? It might be easier to test the encoging tables with MathML documents (as opposed to reading the encoding tables).

Since it is a whole system, all the pieces are important. But I now got all of the back-end ready to go -- bug 72161. I am not sure if it might be possible to still check-in M0.8.1. But if the back-end is checked-in, it still wouldn't be possible to test the encoding tables off the shelves -- because the ucvmath module needs to be updated with the changes. So re-compilation of the ucvmath is still needed. (once all the glyphs have been assigned, re-compilation will not be needed anymore because the same assignments will be re-used and no changes will arise in the ucvmath module) However, the perl script encode.pl produces a html output which is a visual form of what has been encoded internally. Here is an example for the Symbol font (the graycode (color gray) in the ultimate reference to the glyph -- which could be a generated PUA code, i.e., doing &#xgraycode; can really display the glyph in the browser): http://www.mozilla.org/projects/mathml/fonts/encoding/symbol-encoding.html

Checked-in. Since I have also updated ucvmath, there should be no question marks for missing glyphs when visiting the 'visual encoding results' (well, that's not quite acurate. CMR10 and CMMI10 will be alright when I land the patch on bug 73273). But with this fix, it is already possible to define new stretchy combinations in the other existing property files without recompilation.