30543 - Mozilla MathML entities not MathML 2.0 conformant

Status: RESOLVED FIXED

(Core :: MathML, defect, P3)

Description

[Paul Gartside]

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.)

Comment 1

[rbs]

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.

Comment 2

[Paul Gartside]

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

Comment 3

[rbs]

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?

Comment 4

[Paul Gartside]

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.

Comment 5

[Gervase Markham [:gerv]]

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

Comment 6

[Anand Kumria]

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

Comment 7

[rbs]

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.

Comment 8

[Henri Sivonen (:hsivonen)]

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).

Comment 9

[rbs]

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

Comment 10

[rbs]

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.