Closed Bug 324857 Opened 18 years ago Closed 16 years ago

MathML all screwed up in Cairo builds

Categories

(Core :: Graphics, defect, P1)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Assigned: karlt)

References

()

Details

(Keywords: regression, testcase, Whiteboard: cairo)

Attachments

(16 files, 14 obsolete files)

33.70 KB, image/png
Details
33.60 KB, image/png
Details
33.31 KB, image/png
Details
32.08 KB, image/png
Details
33.73 KB, image/png
Details
35.57 KB, image/png
Details
4.09 KB, text/plain
Details
50 bytes, text/plain
Details
110.34 KB, patch
Details | Diff | Splinter Review
101.73 KB, image/png
Details
31.35 KB, image/png
Details
10.72 KB, patch
pavlov
: review+
Details | Diff | Splinter Review
13.17 KB, application/xml
Details
28.98 KB, image/png
Details
29.62 KB, image/png
Details
38.40 KB, application/xhtml+xml
Details
See url.
The MathML all looks very funny and things doesn't seem to get repainted.
Whiteboard: cairo
indeed
examine the top of my dumb page
http://hardcarve.com/muse/muse.pl/Scratch
A lot of this is probably bug 324560 since those are Unicode mathematical symbols.
Depends on: 324560
(In reply to comment #2)
> A lot of this is probably bug 324560 since those are Unicode mathematical
> symbols.
 
Additionally due to the lack of custom-font support in Thebe at the moment (as mentioned in bug 324560) among many other causes.



Fixing this would be a good opportunity to fix bug 289938 as well.
Severity: major → critical
OS: Windows XP → All
*** Bug 334203 has been marked as a duplicate of this bug. ***
Depends on: 334512
Honestly, I do not see how https://bugzilla.mozilla.org/show_bug.cgi?id=334203 is a duplicate of this bug. Maybe I am just blind, but I don't see any markup errors on start.xhtml page. ??? Someone please enlighten me. BTW, I am all for MathML rendering improvements in general.
Blocks: 334512
No longer depends on: 334512
Blocks: 334737
No longer blocks: 334512
Let me rephrase my last comment. I do not see any problems on the example page while using Firefox 1.5.0.2. However, https://bugzilla.mozilla.org/show_bug.cgi?id=334203 does show up in Firefox 1.5.0.2, the current production branch.
Flags: blocking1.9a1?
Dup of bug 321994?
(In reply to comment #8)
> Dup of bug 321994?
> 
Well, in bug 321994 you say you are running Firefox 1.5.  This is a post 1.5 Trunk only issue, so it is not he same.
By implementing nsThebesRenderingContext::GetBoundingMetrics() and nsThebesFontMetrics::GetBoundingMetrics() I was able to get some MathML functionality. I only did this for Windows, but the code is straightforward and short easily port to other Cairo platforms.

However, this is still far from a fix for the MathML problems.  With the default mathml.css, you pretty much get garbage on the screen.  Switching around the fonts so that Lucida Sans Unicode is used instead of CMSY10, it looks at least partially correct.  See my screenshots.

So I have a question for any Thebes experts out there.  How are we supposed to handle this case?  In particular, current MathML implementations on Gecko pull glyphs out of various fonts, depending on what each font provides.  It seems like gfxTextRun was meant to do that, but I don't see any evidence of an implementation in gfxWindowsTextRun.  Is that just work in progress?  Or was it assumed that MathML on Thebes would (only) work with the STIX fonts?
I have a very large patch in progress I'm hoping to land in the next week or two (I'm on vacation next week).  It fixes most of the font selection problems dealing with the use of multiple fonts.

The biggest problem you'll have with the patch you wrote is that you need the uniscribe path to (better) handle fallback fonts with all its crazy goto madness.  The fast case doesn't currently deal with the case where all the glyphs aren't in the first font.  Thats why it returns early in that case and the caller function calls the uniscribe methods.

That said, DrawAndMeasure* should probably just be made to deal with whatever GetBoundingMetrics needs.
Thanks for the info.  I'm looking forward to your patch.  In the meantime, I'll look into the Uniscribe path (b/c I ignored that before).
Pav, any news on this? I can't use MathML at all at the moment on the trunk.
Keywords: regression, testcase
After building this morning, I get this screenshot on Windows using the default mathml.css.  Not much different from before. Note that I have the MathML fonts installed. AFAIK my other font preferences are just defaults.
You need GetBoundingMetrics to be implemented for the uniscribe case for mathml to really work.
I don't think that's the whole story, but this revised patch does cover the Uniscribe case.  I still don't have an answer to my question in comment 10 about MathML fonts.  See revised screenshot below.
Attachment #222561 - Attachment is obsolete: true
When the primary font in mathml.css is set to Lucida Sans Unicode, most characters seem to draw correctly, but square roots and stretchy fences are messed up.  I did check that it will sometimes take the Uniscribe path, so the behavior is different from the last patch.

I also noticed that I'm now getting CSS errors from mathml.css, tex.css and mathematica.css along the lines of

CSS Error (resource://gre/res/mathml.css :436.21): Unknown pseudo-class or pseud
o-element '-moz-math-stretchy'.  Ruleset ignored due to bad selector.

I think this is new; and it's possible this explains the drawing errors (though I doubt it).
What can I do to help move this bug along?  Are we waiting for STIX fonts, other platforms, or something else?
so there are 2 pretty basic problems with this patch... a) I don't want duplicate copies of functions in the code and b) I want to avoid using cairo for getting the metrics of the text.  the way it does it is slow and we can do it faster and more correctly given the info we have in the functions.  The old code goes glyph-by-glyph and gets the metrics assuming a 1-1 mapping of character to glyph, which would work fine in the "fast" case but is wrong in the uniscribe case.
I guess really in both cases, you need to do GetGlyphOutline(dc, glyphs[i], GGO_METRICS|GGO_GLYPH_INDEX, &gm, 0, nsnull, nsnull) with the glyph indicies and do  something similar to what the old code does with the results...

Also, please don't pass old-style gfx classes in to thebes (i.e. nsBoundingMetrics).  Make something new and toss it in to gfxFont.h
How about 2 out of 3?

I removed the duplicate code in gfxWindowsFonts.cpp.  I added gfxBoundingMetrics to gfxFont.h.

But I was unable to get GetGlyphOutline to work.  I'd just get GDI_ERROR and GetLastError() returned 0.  I stepped into the cairo code and it seemed to make the same call I did.  Hmmm.

There's something I still don't understand.  The first call which comes in is asking for the metrics of "x".  The first MathML font is CMSY10 and the code happily queries that font for the metrics of "x".  But CMSY10 doesn't have an "x" so you get back the metrics for something else.  What's supposed to happen here?  a) CMSY10 should be recognized as a non-Unicode font and skipped over, b) some other mechanism (mathfont.properties?) would be used to skip over CMSY10, c) something else.
Attachment #226559 - Attachment is obsolete: true
Ah.  The transformation matrix argument to GetGlyphOutline() is required!  Working on an improved patch.
Using GetGlyphOutline() instead of cairo_scale_font_glyph_extents(), this now seems to do the right thing on the MathML start page.  (The display is still not right, see comment 23 above.)

I left the cairo code in an #ifdef clause because cairo caches the outline data. I expect that for most pages, cairo would actually be faster than my direct technique.

Note that I also corrected a problem in gfxWindowsFont::ComputeMetrics().  The transformation matrix mMat was not being initialized correctly, so the call to GetGlyphOutlineW() always failed, so the "real x-height" was not being computed.
Attachment #228542 - Attachment is obsolete: true
Results are similar to those seen in attachment 222562 [details].  Character data is usually wrong because of font selection.  Stretchy fences and radicals have empty boxes instead of the expected pieces. Note, however, that the width of fractions and the height of fences and radicals is roughly correct.
Using Minefield (Build 2006081304) the page http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml
looks OK on OS X 10.4.7 , but is all screwed up for MS XP .
When Firefox 1 and 2 are used the MS XP view of this page looks OK (i.e. All the required fonts are on the machine).




(In reply to comment #26)
> Results are similar to those seen in attachment 222562 [details] [edit].  Character data is
> usually wrong because of font selection.  Stretchy fences and radicals have
We really need to implement symbolic font handling. One quick optimistic way is to use the math font converters in intl/uconv/ucvmath as we did before and put the result (though we need to convert it into pseudo-unicode from raw 8-bit seq) back into usual text drawing path. The font object retains the converter. I think the right place for symbolic font conversion is the text run constructor. Anyway we might need to handle character representability of each font as I briefly tried at bug 246527 and bug 121540.

(In reply to comment #27)
> Using Minefield (Build 2006081304) the page
> http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml
> looks OK on OS X 10.4.7 , but is all screwed up for MS XP .
This is just because thebes is not turned on for Mac.
We're planning on moving to the new textframe code and the new gfxTextRun and friends.  Going to need to update the mathml code to the new thebes text stuff once it is done.
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: cairo → cairo [wanted-1.9]
*** Bug 363776 has been marked as a duplicate of this bug. ***
Flags: blocking1.9- → blocking1.9?
Hardware: PC → All
Flags: blocking1.9? → blocking1.9-
This bug has got blocking 1.9- now, do we really want to possibly ship Firefox with this bug?
Martijn: while I agree with you that this bug should block 1.9 (because it's a serious MathML regression, and it affects more than just Firefox 3), I do note there's a wanted-1.9 whiteboard marker on this bug.  This is also the second time the bug has been minused for blocking1.9 (brendan pulled it out after the first time).

However, this bug is assigned to nobody, and there is no patch in the pipeline with a r? flag or r+ flag on it...
Well, when the times comes there, maybe it is better to disable MathML completely then, because the url testcase renders useless in the latest trunk builds.
Let's have some better communication, and a rational plan. Minusing blocking-1.9 because the s.b. has [wanted-1.9] is not convincing unless the bug also goes on someone's list. Minusing blocking-1.9 for a regression that breaks MathML without either a different bug that's blocking-1.9 and fixes MathML, or a turn-off-MathML decision involving me, is not convincing.

If this bug is a MathML regression that we can't afford to ship with 1.9, then it is blocking-1.9, period, end of story. Why shouldn't the flag say so?

I'm happy to listen to reason, but silence is, again, unconvincing.

/be
Flags: blocking1.9- → blocking1.9?
Really, I meant "s.w.b." or just whiteboard, not "s.b.".  And the issue of this bug being assigned to nobody@mozilla.org is not the main one. If it were assigned to someone likely to fix it, it could have [wanted-1.9] for all I care, but in any event if it is truly a blocking-1.9 regression, it should have that flag +'d.

/be
Vlad stopped by to say that there's no one really working on MathML enough to have confidence that this bug will get fixed.  Roger, are you there?  Roc, what can be done?  I agree we need a human owner for this bug to believe it will be fixed.  I also think it should be blocking-1.9, but that needs a wider debate.

/be
I don't think this will be too hard to fix once the new textrun interfaces are in but I certainly can't commit to doing it.
I stopped thinking about this bug once Comment #29 came in (the new textrun stuff).  From the partial work I did, that and the (promised) STIX fonts are needed for a complete bug fix.
I am back from my trips but in the midst of some end-of-the year stuff/reports. I have been watching for the dependency chain. As this is clearly a blocker for MathML, I am taking the bug to get the 1.9+ status. Others are welcome to be beat me to it too.

It should be recalled that after the new textrun interfaces, the nub of the matter (which is specific to MathML) becomes the support of those symbolic or custom fonts (such as the TeX/Mathematica/STIX fonts). As far as I can tell, we will still need the hand-made glyph mappings that we had in the old GFX world. This matter is in the nature of the task, not of the old vs. new APIs.
Assignee: nobody → rbs
Yay -- thanks, rbs.

/be
> As far as I can tell, we will still need the hand-made glyph mappings that 
> we had in the old GFX world. This matter is in the nature of the task, 
> not of the old vs. new APIs.

Could that be avoided if there was a volunteer with enough font expertise and tools to recast the YandY Type 1 version of Computer Modern as a properly mapped OpenType font? (I don't have font editing expertise myself.)

If that's not feasible, I think the remapping belongs in gfx--not in content (see bug 289938).
>Could that be avoided if there was a volunteer with enough font expertise and
>tools to recast the YandY Type 1 version of Computer Modern as a properly
>mapped OpenType font? (I don't have font editing expertise myself.)

Possibly. For example, it is conceivable that the stretching code (that we currently have in Gecko's C++) could be pushed into the glyph drawing code inside the font. And perhaps other approaches could also be possible (e.g., with transformations that replicate certain portions of a glyph -- thus emulating a stretching process that doesn't require individual/separate glyphs for the parts). But we can only dream of designing/shipping our own fonts.
[Any taker? That's how Knuth ended up doing his TeX's Computer Modern fonts. When he was writing TeX, he got stuck in these font problems and realized that if he had to ever finish TeX, he had to make his own fonts - and so came METAFONT, http://en.wikipedia.org/wiki/METAFONT.]

>If that's not feasible, I think the remapping belongs in gfx--not in content
>(see bug 289938).

I have this in mind. Let's aim for that in the new Cairo world.
http://canopus.iacp.dvo.ru/%7Epanov/cm-unicode/

That project may already have what is needed in terms of fonts or is likely to be very close. (I can't find stretchy math glyphs with Apple's Font Book.)
Just a thought: Would it be feasible to draw stretchy glyphs as graphics from the Cairo point of view instead of using a font?
Hi, I'm a Google SoC student with a Mozilla MathML-enhancement proposal. Chris Hoffman of the mentor team asked if I could take on "MathML in trunk rendering getting working" as a part of the project, hence this inquiry. Looking at this bug, which seems to be the core of the issue, I wonder what is the best and the most realistic approach towards it which can be included in the proposal?

Is it possible to summarize at least approximately what has to be done?
Welcome, Vlad.

Yes, this is the core of the MathML issue.  My position is summarized in Comment #41...if the STIX fonts perform as expected we should be able to come up with a less platform-dependent solution than the old one.

My patches above simply try to put in the lowest level support for MathML by implementing GetBoundingMetrics.  There's still a huge amount of work needed in regards to glyph mapping and supporting stretchy-ness.  The reference here is the old gfx code.

Text has changed on trunk.

You want to use the gfxTextRun API now. Create textruns with gfxFontGroup::MakeTextRun and measure them with gfxTextRun::MeasureText. We'll need some way to create textruns from glyph indices instead of Unicode characters (right?). That may require an API change.
Note that to get glyph bounds, MeasureText calls gfxFont::MeasureText. On Mac and Windows, that doesn't really measure glyph bounds. You'll want to change that at least for the aTight true case. If you don't have access to all the platforms, that's fine, just get things working on the platform(s) you have access to.
Blocks: 377499
(This patch assumes you're working inside the new text run.)

So I just gather up the glyphs and ask cairo for the bounding box.  Loading the MathML start page, the behavior is basically correct.

This is really just a proof of concept.  The glyph gathering code is duplicated from gfxFont::Draw.  I'm not sure whether aSpacing should be included in the bounded box (or if that's relevant).

I've only compiled on Windows.  I put in the code for ATSUI and Pango, but have not tested there...it should work.  But platform implementers may want to optimize.

Loading the MathML start page, many ASSERTs fire.  Some of the noise is from the new text run code, some from nsFrame::CorrectStyleParentFrame.  I think those are all unrelated to this patch.
aSpacing should be included when computing the glyph positions. Spacing at the ends should not be included in the tight bounding box, though.

This looks good. I think we should share code with Draw though. How about creating a helper function (could be static) that fills in the glyph array from the textrun? It would take the current position as an in/out parameter. Should also take some kind of callback function that gets called for missing-glyph boxes (to draw them for Draw; tight bounding-box measurement should include the size of the missing-glyph box).
Factored out duplicate code into a static helper.  Omitted outer spacing in tight case.
Attachment #262272 - Attachment is obsolete: true
Attachment #262272 - Flags: superreview?(roc)
Attachment #262272 - Flags: review?(roc)
Attachment #262593 - Flags: superreview?(roc)
Attachment #262593 - Flags: review?(roc)
+    if (aSpacing && !aTight) {
         x += direction*aSpacing[0].mBefore;

+        if (aSpacing && !aTight) {
             double space = aSpacing[i - aStart].mAfter;

You're not including the spacing when computing the glyph positions, as I suggested above. Just take out these aTight checks.

+        GatherGlyphs(aTextRun, aStart, aEnd, PR_FALSE, &dummyPt, aSpacing, PR_FALSE,
+                     nsnull, &glyphBuffer);

You should pass a missing-glyph callback that accumulates the missing-glyph rect into the bounding box you're going to compute.

+        double bb_width = (-extents.x_bearing + extents.width)*appUnitsPerDevUnit;
+        double bb_y = extents.y_bearing*appUnitsPerDevUnit;
+        double bb_height = extents.height*appUnitsPerDevUnit;
+        metrics.mBoundingBox =
+            gfxRect(0, bb_y, bb_width, bb_height);

mBoundingBox.x need not be zero. If there's spacing at the start of the string, it could be positive. It could be negative if some character in the string has a glyph with left bearing. I think basically you just want to return cairo's extents here and everything should be fine.
Attached patch revised as per comments (obsolete) — Splinter Review
This should be better.

Missing glyphs seem to wind up in their own text run.  I think my calculation of the bounding box does the right thing, but I don't have a test case where there are actual and missing glyphs together.

AFAICT MathML is not using the tight bounding box.  But this is hard to diagnose because script elements (msub,msup,msubsup) aren't drawing their first child (the base).  The text in that first child never gets to gfxFont::Measure().  The scripts are positioned correctly (assuming a zero width base), but it seems that their bounding box is not tight.
Attachment #262593 - Attachment is obsolete: true
Attachment #262960 - Flags: superreview?(roc)
Attachment #262960 - Flags: review?(roc)
Attachment #262593 - Flags: superreview?(roc)
Attachment #262593 - Flags: review?(roc)
+        nsAutoTArray<cairo_glyph_t,10> glyphBuffer;

Make it 200 like the others

+        double bb_width = (-extents.x_bearing + extents.width)*appUnitsPerDevUnit;

Why isn't this just extents.width*appUnitsPerDevUnit?

+        if (missingCallback.Count()) {

Don't bother with this shortcut.

Instead of storing an array of rects in MissingGlyph, why not just have one rect and union each rect into it?

I think we should just eliminate gfxPangoFont::Measure and use the base class version.
Attached patch further improvements (obsolete) — Splinter Review
Cleaned up as per comments.

I don't know anything about Pango, so can't say whether it needs its own Measure().
Attachment #262960 - Attachment is obsolete: true
Attachment #262968 - Flags: superreview?(roc)
Attachment #262968 - Flags: review?(roc)
Attachment #262960 - Flags: superreview?(roc)
Attachment #262960 - Flags: review?(roc)
What about this?

> +        double bb_width = (-extents.x_bearing +
> extents.width)*appUnitsPerDevUnit;
>
> Why isn't this just extents.width*appUnitsPerDevUnit?
Attached patch fix one more problem (obsolete) — Splinter Review
Sorry, I made that change too, but I guess I didn't update the diff.  After reading the Cairo documentation, I decided that adjusting for the x-bearing was wrong.
Attachment #262968 - Attachment is obsolete: true
Attachment #262984 - Flags: superreview?(roc)
Attachment #262984 - Flags: review?(roc)
Attachment #262968 - Flags: superreview?(roc)
Attachment #262968 - Flags: review?(roc)
Attachment #262984 - Flags: superreview?(roc)
Attachment #262984 - Flags: superreview+
Attachment #262984 - Flags: review?(roc)
Attachment #262984 - Flags: review+
Re last paragraph of comment #54.  It's the first text child of the math element which is not being measured/drawn.

So in 
   <math xmlns="http://www.w3.org/1998/Math/MathML">
     <mi>a</mi>
     <msup>
       <mn>0</mn>
       <mi>x</mi>
     </msup>
   </math>
you don't see the a, but in
   <math xmlns="http://www.w3.org/1998/Math/MathML">
     <msup>
       <mn>0</mn>
       <mi>x</mi>
     </msup>
   </math>
you don't see the 0.
BTW, below is a spot that needs to be tweaked in
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsTextFrameThebes.cpp

Unlike mainline, MathML positioning needs/expects the raw metrics as-is. So, we wouldn't need the PR_MAX() below -- otherwise the information is lost with no way to recover it at a higher level (there are also sort of strange glyphs in math fonts). I also wonder about aMetrics.mBoundingMetrics.width -- it is allowed to be negative in MathML positioning (also because of strange glyphs):
http://lxr.mozilla.org/seamonkey/source/gfx/public/nsIRenderingContext.h#1044

4850 #ifdef MOZ_MATHML
4851   // Store MathML bounding metrics. We've already calculated them above.
4852   if (needTightBoundingBox) {
4853     aMetrics.mBoundingMetrics.ascent =
4854       NSToCoordCeil(PR_MAX(0, -textMetrics.mBoundingBox.Y()));
4855     aMetrics.mBoundingMetrics.descent =
4856       NSToCoordCeil(PR_MAX(0, textMetrics.mBoundingBox.YMost()));
4857     aMetrics.mBoundingMetrics.leftBearing =
4858       NSToCoordFloor(textMetrics.mBoundingBox.X());
4859     aMetrics.mBoundingMetrics.rightBearing =
4860       NSToCoordCeil(textMetrics.mBoundingBox.XMost());
4861     aMetrics.mBoundingMetrics.width = aMetrics.width;
4862   }
4863 #endif
Also of note is the activation of the hook in nsThebesRenderingContext::GetBoundingMetricsInternal.
GetBoundingMetricsInternal just calls nsThebesFontMetrics::GetBoundingMetrics, which I implemented.
I guess I don't understand exactly what works and what doesn't, but it's not complete nonsense.
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9beta1
Blocks: 371481
This patch and the following files implement get-bounding-metrics of glyphs and symbolic font conversions for mac.  Summary of the changes:
gfx/thebes/src: main ingredients are GetConverterForFont and GetImageRectForGlyph.
* GetConverterForFont looks for ucvmath symbolic font converters defined in fontEncoding.properties.
* GetImageRectForGlyph is called from measurement code (AccumulateMetricsForRun) when aTight is on. 
** The gfxFont.cpp code for GetImageRect... is just a stub similar to current no-tight-bounding-box code.
** In the mac code (gfxAtsuiFonts.cpp), actual implementation is achieved by ATSUGetScreenMetrics.
intl/uconv/ucvmath: Mathematica font converters were modified to output 2-byte codes.
layout/ The changes are mostly dependency (on uconov) fixes or the ones incorporated from Bug 385265.
fontEncoding.properties: should go into gfx/thebes/src
Attached file thebes.pkg
thebes.pkg: should go into gfx/thebes/src/
See bug 96041 --- there's glyph bounds code in there for all platforms. Please use that patch instead for glyph bounds and just post the rest of the code here.
fixes from bug: 96041
- patch update , add content/ fix for gfxTextRun->Measure(...)
- added overflow area fix right before FinishAndStoreOverflow call (enclosed within #ifdef DEBUG). I needed this to kill "Computed overflow area must contain frame bounds" assertions which led to blank math rendering, but I'm not sure this is the right place to fix it.
Now platform dependant part is just the symbolic font conversion part in gfxAtsuiFonts.cpp. (gfxAtsuiFontGroup::InitTextRun).
Attachment #274342 - Attachment is obsolete: true
*ONE YEAR LATER* (see comment #27)

Using Minefield (Build 2007081404) the page
http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml
is all screwed up for MS Vista Business and OS X 10.4.10 .
When Firefox 2 is used the MS Vista view and the OS X of this page 
looks OK (All the required fonts are on the machine).
> I needed this to kill "Computed overflow area must
> contain frame bounds" assertions which led to blank math rendering, but I'm not
> sure this is the right place to fix it.

I assume you only saw that assertion while testing MathML? Then I think this is not the right place to fix it.
Depends on: 397288
Attached patch nsBoundingMetrics changes (obsolete) — Splinter Review
Changes from Steve, including nsTextFrame::Reflow changes from comment #60
(YAMASHITA I'm assuming these weren't removed intentionally) that are not handled in bug 96041.

(Breaking up the patch in comment #69 into more manageable chunks.)
Attachment #228865 - Attachment is obsolete: true
Attachment #263230 - Attachment is obsolete: true
Remaining changes from patch in comment #69 that are not handled in bug 385265.
Attachment #274711 - Attachment is obsolete: true
Depends on: 96041, 385265
The following patches were applied:

attachment 282067 [details] [diff] [review], attachment 282068 [details] [diff] [review], attachment 274343 [details], and the overflow area fix described in comment 69. It seems that we have a problem with tables, some stuff that used to be bold on 1.8 is no longer bold, and the hat over x is gone. Otherwise, better than it used to be..
A code from attachment 282068 [details] [diff] [review] was copied over to gfxWindowsFont.cpp into uniscribe path (the fast path was disabled). attachment 275732 [details] [diff] [review], attachment 274343 [details], attachment 282067 [details] [diff] [review], attachment 282068 [details] [diff] [review] and the hack from comment 69 were also applied.
Adding Cambria Math to math font-family is helpful.  This font shouldn't need (as much?) encoding conversion.  (Doesn't help with square roots without other changes, but adds a few other symbols.)  When the STIX fonts are available they should go in the font-family too, these won't require non Vista/Office people to do strange things to get the fonts.

http://www.webspaceworks.com/resources/fonts-web-typography/74/
http://www.stixfonts.org/
We will need symbolic font in any case for things that are assembled from fragments, so fonts availability won't change the code that has to be written for this bug (much), and on windows symbolic font seems to be less straightforward than on MacOS due to some weirdness, maybe we can port only a subset of it that is needed for nsMathMLChar.cpp.. But now that glyph bounds code is available at least one can see the results of one's efforts on symbolic font, which is different from the state this bug was in a few months back.
Priority: -- → P1
Depends on: 400207
Target Milestone: mozilla1.9 M8 → ---
Karl's the man
Assignee: rbs → mozbugz
Depends on: 400938
Depends on: 401178
Depends on: 399940
Beta release of the Stix Fonts is available at http://www.stixfonts.org/

Perhaps the release of the Stix Fonts will bring more attention to fixing this bug.  It would be nice if this bug was closed before the first beta release of 
FF 3.0.

 
(In reply to comment #80)
> Beta release of the Stix Fonts is available at http://www.stixfonts.org/
> 
> Perhaps the release of the Stix Fonts will bring more attention to fixing this
> bug.  It would be nice if this bug was closed before the first beta release of 
> FF 3.0.
> 
> 
> 

Especially if FF 3 were made to automatically download and use the STIX fonts as needed for MathML (and periodically update them, until we have the final version) ...
Based on Steve Swanson's patch.

I don't think we're going to move MathML to gfxTextRuns at this stage,
so lets get this in.

Changes:
  Used a helper function to get the bounding metrics of a gfxTextRun.
    Corrected the ascent conversion.
    Added NSToCoord* functions in conversions from gfxFloat to nscoord.
      I've rounded in because this seems best for joining parts of
      stretchy chars.
  Only aBoundingMetrics.Clear() when necessary.
  Removed changes to nsTextFrameThebes.cpp that are no longer applicable.
Attachment #262984 - Attachment is obsolete: true
Attachment #282067 - Attachment is obsolete: true
Attachment #287939 - Flags: review?
Attachment #287939 - Flags: review? → review?(pavlov)
I've changed my mind on the rounding and decided to round out for consistency with nsHTMLReflowMetrics::mOverflowArea and nsIFrame::ComputeTightBounds().
The code for joining parts of stretchy chars does overlapping anyway.
The old nsRenderingContextWin used NSToCoordRound but that left neither an upper nor lower bound.  (These are 1/60th CSS pixels so I guess it doesn't make too much difference.)
Attachment #287939 - Attachment is obsolete: true
Attachment #288247 - Flags: review?(pavlov)
Attachment #287939 - Flags: review?(pavlov)
Attachment #288247 - Flags: review?(pavlov) → review+
removing [wanted-1.9], since was already blocking 1.9

Whiteboard: cairo [wanted-1.9] → cairo
Comment on attachment 288247 [details] [diff] [review]
implement nsIRenderingContext::GetBoundingMetrics() v3 [checked in]

checked in this patch:
1.7         mozilla/gfx/src/thebes/nsIThebesFontMetrics.h
1.43        mozilla/gfx/src/thebes/nsThebesFontMetrics.cpp
1.21        mozilla/gfx/src/thebes/nsThebesFontMetrics.h
1.48        mozilla/gfx/src/thebes/nsThebesRenderingContext.cpp
Hmmm. In eager anticipation, I grabbed the latest nightly Firefox build,

 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O 10.5; en-US; rv:1.9b2pre)
 Gecko/2007111204 Minefield/3.0b2pre (12-Nov-2007 05:08 PST)

which (I think) should have this patch incorporated.

MathML is as broken as ever. :-(
Keywords: relnote
Blocks: 405081
Attachment #288247 - Attachment description: implement nsIRenderingContext::GetBoundingMetrics() v3 → implement nsIRenderingContext::GetBoundingMetrics() v3 [checked in]
Depends on: 363240
Depends on: 348577
This has become a tracking bug, and will be fixed in its dependencies, so I'm removing the priority to help our bug searches.  (This is still a top priority, though.)  Dependency bugs will instead be prioritized.

Much of the "looks very funny" originally reported has been fixed through bug 400938.  The other incorrect glyphs should be fixed by an update to the mathml.dtd for bug 289938.

The "things doesn't seem to get repainted" is really bug 161155 and bug 335405, and should be fixed when they are fixed.
Depends on: 161155, 289938, 335405
Priority: P1 → --
Depends on: 382542, 401988
(In reply to comment #87)
> This has become a tracking bug, and will be fixed in its dependencies, so I'm
> removing the priority to help our bug searches.  (This is still a top priority,
> though.)  Dependency bugs will instead be prioritized.

Good work on this.  I can finally see the light at the end of the tunnel!  Most fo the test on http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml render either correctly or just have spacing issues.

Sorry fo the bugspam, but i just felt an atta boy was deserved on this effort.
Just a fyi, now nothing show anymore at http://www.mozilla.org/projects/mathml/start.xhtml , unless I do some scrolling.
It's getting worse for me ;)
(In reply to comment #89)
> Just a fyi, now nothing show anymore at
> http://www.mozilla.org/projects/mathml/start.xhtml , unless I do some
> scrolling.
> It's getting worse for me ;)
> 
Same here, it renders 2 signs throught this page when I click on your link which opens in the same tab.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007120606 Minefield/3.0b2pre ID:2007120606
(In reply to comment #89 / #90)
It works quite better than that for me with 2007121205 Minefield/3.0b2pre (2007120505 is the same) and the Stix fonts, but I had a similar behaviour on the texvsmml.xhtml page after initial loading when switching tab with many different tab opened. After reducing the number of opened tabs to just three, it happened no more.

Well if the three open tabs are http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml , http://www.mozilla.org/projects/mathml/start.xhtml and http://devfiles.myopera.com/articles/186/stress.xhtml, it's enough to get the problem. The opera stress.xhtml pages seem to be quite less sensible to this problem (because with the three tabs opened, it occured on the texvsmml.xhtml tab, but not on that one).

I have already seen something similar happen without MathML when I had many tabs with very large page opened (from www.theoildrum.com for example), so I suspect that it might be a "too many complex element more" more than a strictly MathML problem, but I could not repro the theoildrum problem with recent Fx nightlies.

Anyway under any condition the test from 18 and up on texvsmml.xhtml are quite broken. With the opera stress page, it might be easier to see it's mostly the Case (if), Matrices, Determinants and Vectors tests that break.

This testcase renders incorrectly under today's nightly build (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007121604 Minefield/3.0b3pre).

Renders correctly under Firefox 2.0.0.11 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11).
The attached files show the problem with MathML rendering on my installation of Firefox nightly build on GNU/Linux (Ubuntu Gutsy Gibbon).

Please don't pay attention to the semantics and correctness of the notation, there might be some errors :)

However, the example demonstrates a clear problem with Firefox 3 MathML rendering.
(In reply to comment #94)
> Screenshot from firefox 3 nightly 2007121604 - incorrect rendering

Try uninstalling CMSY10 and CMEX10 or at least removing them from the font-family specifications in the document.

See bug 161137 comment 39 and bug 400938 comment 0 for discussion on why not to use these (forms of these) fonts.  If you replace your Computer Modern fonts with those from http://www.ctan.org/tex-archive/fonts/cm/ps-type1/bakoma/otf/ then you won't have the same problem, as that version uses PUA Unicode points, but these won't be used to render (non-PUA) Unicode characters.
You may also like to investigate the fonts from http://www.math.utah.edu/~beebe/fonts/computer-modern.html which have Unicode cmaps but don't seem to provide all the Computer Modern fonts/glyphs.
No longer depends on: 335405
Re: issue mentioned in comment #89, comment #90 and comment#91.

I have 2 windows laptops and see this issue on one but not the other.  Perhaps If I detail the differences someone can see what is similar on the failing systems.

Laptop A (the one that works)  This has an Intel Core 2 CPU T7600 @2.33GHz and an ATI Mobility FireGL V5200 graphics adapter.

Laptop B (the one that doesn't) has an AMD Turion 64 mobile MT-37 at 800Mhz and an ATI Mobility Radeon M700 graphics adapter.

Both tested under 32 bit Windows/XP using the official Firefox Beta 2 build.
I see it as well with an Opteron 165 and an ATI X300 video card.
(In reply to comment #97)
> Laptop B (the one that doesn't) has an AMD Turion 64 mobile MT-37 at 800Mhz and
> an ATI Mobility Radeon M700 graphics adapter.

I should have also mentioned that this second laptop, which shows the issue under Windows/XP, is actually my Linux Laptop.  Under 64-bit Fedora Core6 with the Open source ATI driver, I do not see this issue using the official 32-bit Linux Firefox Beta 2 build.
(In reply to comment #98)
> I see it as well with an Opteron 165 and an ATI X300 video card.
> 

OK.

1.  Does anyone who does not have an AMD 64 see this issue under Windows?

2.  Does anyone who has an AMD 64 NOT see this issue under Windows?
The fix for bug 161155 may have helped this issue.  Is anyone still not seeing any math with this morning's nightlies?
I still see severe repainting problems with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007123002 Minefield/3.0b3pre

Only two half-paragraphs are painted before scrolling.  All of my XHTML+MathML files generated with tex4ht are like this (or worse).  This is on WinXP SP2 with Intel GMA 900 integrated graphics card.
OK.  Forget about CPU types and graphics cards and posting more testcases.  The problem is font related.  The PC that worked correctly had 208 more fonts installed than the one with the issues.  Adding all 208 fonts resolved the issue.  I will figure out what font(s) actually fixed this and post a followup comment.
Duh!  Silly me.  To fix this issue install the Cambria fonts as suggested in comment #77.  Just follow the first link in the comment to install the powerpoint viewer.  It would seem there is still a bug here, as the lack of a proper font should not screw up the entire page layout including the display of images or even preventing the initial reflow of the page.
With the Cambria and STIX fonts installed, are the Mathematica fonts still required for proper MathML support?
(In reply to comment #104)
> Duh!  Silly me.  To fix this issue install the Cambria fonts as suggested in
> comment #77.  Just follow the first link in the comment to install the
> powerpoint viewer.

I should have mentioned that if you do not wish to install the powerpoint viewer, no problem.  Just install it anyway and then go to add/remove programs and remove it.  The install installs the fonts, but the uninstall does not remove them, in case they are required for another program.

Doing it this way, install then uninstall, gets you the fonts you need in a way that does not violate any Microsoft license provisions.

(In reply to comment #104)
> Duh!  Silly me.  To fix this issue install the Cambria fonts as suggested in
> comment #77.

Installing the Cambria Math font did not solve the repainting problem for me, but *uninstalling* the STIX fonts did.  Of course, without Cambria some characters are missing, but it was not necessary to install it to solve the repainting problem.

(BTW I just noticed that I forgot to include the style sheet in the problem document I attached earlier, so it is broken even in Fx2.  If anyone knows of a way to edit attachments, please mail me.)
Depends on: 410284
(In reply to comment #104)
> It would seem there is still a bug here, as the lack of a
> proper font should not screw up the entire page layout including the display of
> images or even preventing the initial reflow of the page.

Thanks for the analysis.  Filed bug 410284.
(In reply to comment #107)
> Installing the Cambria Math font did not solve the repainting problem for me,
> but *uninstalling* the STIX fonts did.  Of course, without Cambria some
> characters are missing, but it was not necessary to install it to solve the
> repainting problem.

I'm surprised that uninstalling the STIX fonts helped.  Maybe related to bug 382542.

> (BTW I just noticed that I forgot to include the style sheet in the problem
> document I attached earlier, so it is broken even in Fx2.  If anyone knows
> of a way to edit attachments, please mail me.)

If you still have painting issues when bug 410284 is fixed, then just mark your previous attachment obsolete and attach a new version with the style sheet changes, and perhaps attach a screenshot too.
(In reply to comment #105)
> With the Cambria and STIX fonts installed, are the Mathematica fonts still
> required for proper MathML support?

Either STIX fonts or Cambria Math should provide glyphs for all necessary characters once bug 289938 is fixed.

There is better stretchy operator support with the STIX fonts than Cambria Math.

The most noticeable unstretched operator with Cambria Math will be the radical signs.  This operator could be built from parts in this font
(bug 372351 comment 6).

It should be sufficient to just have STIX fonts installed, but bug 382542 and bug 401988 may cause the wrong glyphs to be selected in a few situations.

Mathematica fonts are currently not used (due to lack of Unicode support).  Math2, Mathematica2, and Mathematica5 may even get in the way if a style sheet tries to select those fonts due to bug 399636.  (CMSY10 and CMEX10 can also get in the way - comment 96).
Karl-

On the Mozilla MathML project page there is a link to a MathML Torture test.
http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml

The current state of things is that 4 of the 28 tests still have issues.  These are test 13 (which actually displays the math correctly, but seems to not compute it's width correctly, so it does not cause the table column width to expand sufficiently to accommodate the cell, and tests 18, 23 and 24.

For the benefit of those of us playing along at home, could you comment on each of these 4 tests indicating what bugs should fix which tests?

Also, if you know of anything that is failing that is not shown by this test, it might be nice to see if we can add cases to the test and make the whole test be a reftest once this is all working.
I tried switching from the cambria fonts to the stix fonts under windows (mostly because Cambria seems to be missing the over/under braces) and found that braces seem to end up with gaps in them when stretched.  This does not happen under Linux.  Is there a bug filed on this?
Depends on: 410331
(In reply to comment #112)
> I tried switching from the cambria fonts to the stix fonts under windows
> (mostly because Cambria seems to be missing the over/under braces) and found
> that braces seem to end up with gaps in them when stretched.  This does not
> happen under Linux.  Is there a bug filed on this?
> 

I filed bug 410331 on this issue.
(In reply to comment #111)
> On the Mozilla MathML project page there is a link to a MathML Torture test.
> http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml
> 
> The current state of things is that 4 of the 28 tests still have issues.
> These are test 13 (which actually displays the math correctly, but seems to
> not compute it's width correctly, so it does not cause the table column width
> to expand sufficiently to accommodate the cell, and tests 18, 23 and 24.

These are all rendering incorrectly due to bug 363240 and bug 348577.
(bug 363240 comment 7).

> Also, if you know of anything that is failing that is not shown by this test,
> it might be nice to see if we can add cases to the test and make the whole
> test be a reftest once this is all working.

I'm not aware of any issues other than what are marked as dependencies for this bug, but I haven't really looked too hard beyond this test page.

Some of the bugs already fixed could do with some reftests, but I'm not sure how easy it is to turn the testcases into reftests.  Several smaller reftests would be better than one large test.
Depends on: 410557
Depends on: 412033
karlt: uninstalling cmsy10 and cmex10 has corrected the issue for me.

For the record, on Ubuntu the package that needs uninstalling is latex-xft-fonts:

apt-get remove latex-xft-fonts
Depends on: 412880
Moving relnote keyword to bug 363240, as that better represents the most noticeable remaining issue.
Keywords: relnote
Depends on: 416062
*18 MONTHS LATER* (see comment #27)

Using Minefield (Build 2008021404) the page
http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml
is mostly OK for MS Vista Ultimate and OS X 10.4.11 .
The tests that are 'failing' most are 13, 18, 22, 23, and 24.

Now that the Stix Fonts are "out", when FireFox is loaded onto a machine it should check if the machine has appropriate fonts for displaying MathML, and if not, suggest the Stix Fonts be installed.
Apart from the misalignments visible on that test page, I had problems with some special characters not showing (more precisely they're showing as a box with the charcode).

I have both the STIX fonts and Cambria Math installed.  An apostrophe does not show in the example below.  The example is from one of my older documents, which was generated with tex4ht: \vec{v}'

<?xml version="1.0" encoding="iso-8859-1" ?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" 
"http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd" > 
<html  
xmlns="http://www.w3.org/1999/xhtml"  
><head>  <title></title> 
</head>
<body>
<div>
<math 
 xmlns="http://www.w3.org/1998/Math/MathML" display="inline" ><msup><mrow 
><mover 
accent="true"><mrow 
><mi 
>v</mi></mrow><mo>&#x2192;</mo></mover></mrow><mrow 
><mi 
>&#x2032;</mi></mrow></msup 
></math>
</div>
</body>
</html>


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021404 Minefield/3.0b4pre ID:2008021404

(In reply to comment #118)
> Apart from the misalignments visible on that test page, I had problems with
> some special characters not showing (more precisely they're showing as a box
> with the charcode).

The hex boxes for U+2030 and other characters is bug 413115 and bug 382542.
Mac users will be seeing similar issues (bug 416062).
Flags: tracking1.9+ → blocking1.9+
Depends on: 413115
With the changes in bug 413115, bug 382542 is (normally) no longer causing the issue described in comment 118.  The upright normal-weight character is now normally used for such characters, so bug 382542 should now only be causing hex boxes if italic or bold style is explicitly requested (on characters that would not be expected to have such styles).
No longer depends on: 382542
The fix for bug 410701 seems to have resulted in glyphs from italic PostScript OpenType faces (STIX) being used (in font fallback) instead instead of hex boxes when the style is non-italic but the glyph is only present in the italic face. This means that U+1D49C MATHEMATICAL SCRIPT CAPITAL A (<mi>&#x1d49c;</mi>), for example, can be rendered with STIX Beta fonts (bug 412880) even without Cambria Math installed.
Depends on: 410701
The gfx issues here are now fixed.

There are still positioning issues when tables enclose either <msqrt> (bug 363240) or (e.g. italic) characters with glyph extents outside their advanced widths (bug 415413), but those are layout (not gfx) issues.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.