Chronological Thread 

< Chronological >      < Thread >

---

Hi,

I am forwarding this message on the state of MathML in Mozilla for your
reference.

We might want to consider applying some of the patches discussed here
after our release (until they get committed to the standard trunk) to
get the MathML rendering working.

Best regards,
Andrew

-------- Original Message --------
Subject: Mozilla 1.9 MathML status
Date: Thu, 01 Nov 2007 00:10:18 +1300
From: Karl Tomlinson <moznews at karlt.net>
Reply-To: dev-tech-mathml at lists.mozilla.org
Newsgroups:
mozilla.dev.tech.mathml,mozilla.dev.tech.layout,mozilla.dev.platform
Followup-To: mozilla.dev.tech.mathml

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

---

• [cellml-dev] [Fwd: Mozilla 1.9 MathML status], Andrew Miller, 11/01/2007

---

Archive powered by MHonArc 2.6.18.