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_resolved=1 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/ See https://bugzilla.mozilla.org/show_bug.cgi?id=400938 for 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.) _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
