Re: Mozilla 1.9 MathML status

On Oct 31, 12:10 pm, Karl Tomlinson <[email protected]> wrote:
> If anyone has tried viewing MathML with a trunk build recently
> they may have noticed that the rendering is not quite up to the
> quality of the 1.8 branch.
>
> This post is a summary of what needs doing to restore the
> rendering to its former glory, and also links to a few patches
> that you can use if you want to beat out a few dents right now.
>
> This bugzilla search for MathML 1.9 blockers and noms provides a
> good way of tracking the relevant bugs:
>
>  http://tinyurl.com/yummjb
>
> Or you can use the dependency tree on this bug
>
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=324857&hide_re...
>
> The work that needs doing falls into two categories: layout, and
> font/glyph selection.  I'll start with layout:
>
> Since "Bug 300030 (reflow-refactor) - Refactor intrinsic width
>   computation out of nsIFrame::Reflow"
>  https://bugzilla.mozilla.org/show_bug.cgi?id=300030
> frames should now provide implementations of GetPrefWidth() and
> GetMinWidth() to determine these width values before Reflow.  A
> patch providing a basic start on this is here:
>
>  https://bugzilla.mozilla.org/show_bug.cgi?id=400207#c5
>
> I think we can currently assume that nsMathMLContainerFrames don't
> line break, but in the future line breaking may be added as an
> enhancement:
>
>  http://www.w3.org/TR/MathML2/chapter3.html#id.3.3.1.2(mrow)
>  http://www.w3.org/TR/MathML2/chapter3.html#id.3.2.7.2(mspace)
>
> As a result of "Bug 397518 - \"ASSERTION: The block in an {ib}
>   split shouldn't be living inside an inline\" with mathml"
>  https://bugzilla.mozilla.org/show_bug.cgi?id=397518
> and "Bug 367332 - redesign ascent computation to allow for
>   multiple baselines for inline-block vs. inline-table"
>  https://bugzilla.mozilla.org/show_bug.cgi?id=397518
> the ascent is not necessarily available in the nsHTMLReflowMetrics
> from Reflow().  The patch here
>
>  https://bugzilla.mozilla.org/show_bug.cgi?id=401178#c1
>
> gets the right answers with (nsBlockFrame's) GetBaseline(), but
> this method should not be used until after DidReflow.  (The
> nsFrame implementation uses the frame's height in the
> calculation.)  So something like nsLineLayout::VerticalAlignFrames
> must be added to the MathML layout code to separate its Reflow
> calculations appropriately before and after calling DidReflow on
> its children.
>
> If you then add the following patch from Robert O'Callahan (which
> is ready to land after M9)
>
>  https://bugzilla.mozilla.org/show_bug.cgi?id=399940#c1
>
> and Steve Swanson's thebes implementation of
> nsIRenderingContext::GetBoundingMetrics()
>
>  https://bugzilla.mozilla.org/show_bug.cgi?id=324857#c73
>
> then you will have MathML frames positioned and sized mostly
> reasonably.
>
> But you will notice that some or the characters are rendered with
> the wrong glyphs.  The Mozilla 1.8 MathML implementation had its
> own Unicode Private Use Area assignments for these characters,
> which gfx translated, through explicit tables of mappings for each
> of several (often non-Unicode fonts), to pick up the desired
> glyphs.  (http://www.mozilla.org/projects/mathml/fonts/encoding/)
>
> Yamashita Makoto has provided a patch that implements this on Mac
> in thebes for Mozilla 1.9:
>
>  https://bugzilla.mozilla.org/show_bug.cgi?id=324857#c74
>
> However, it looks like we are not going to map Unicode code points
> to appropriate glyphs in non-Unicode fonts in Mozilla 1.9
> (https://bugzilla.mozilla.org/show_bug.cgi?id=399636), and we
> should be able to provide a MathML implementation without doing
> this.
>
> We now have more fonts with Unicode character maps available, and
> most significantly a beta release of the STIX fonts is due out in
> the next 24 hours.
>
>  http://www.stixfonts.org/
>
> Seehttps://bugzilla.mozilla.org/show_bug.cgi?id=400938for more
> info on how these fonts can be used in a more generic and
> cross-platform manner.
>
> (I've set Followup-To mozilla.dev.tech.mathml, but there is a bit
> of layout-speak here, so if following up on a layout-specific
> issue then please feel free to use mozilla.dev.tech.layout.)

It's really a good new that Mathml support in Gecko is going to be
improved. Some months ago, I created a MathML test when I worked on
the W3C's browser/editor : http://www.maths-informatique-jeux.com/international/mathml_test/index.xml
. This test is not complete yet but I believe it could be useful for
the unicode character & stretchy  issues...