Last Comment Bug 324857 - MathML all screwed up in Cairo builds
: MathML all screwed up in Cairo builds
Status: RESOLVED FIXED
cairo
: regression, testcase
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: P1 critical with 16 votes (vote)
: ---
Assigned To: Karl Tomlinson (:karlt)
:
Mentors:
http://www.mozilla.org/projects/mathm...
: 363776 370411 380646 394957 (view as bug list)
Depends on: 96041 161155 289938 324560 348577 363240 385265 397288 399940 400207 400938 401178 401988 410284 410331 410557 410701 412033 412880 413115 416062
Blocks: 334737 371481 377499 405081
  Show dependency treegraph
 
Reported: 2006-01-26 13:47 PST by Martijn Wargers [:mwargers] (not working for Mozilla)
Modified: 2014-04-26 03:06 PDT (History)
62 users (show)
pavlov: blocking1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
implement nsThebesRenderingContext::GetBoundingMetrics() on Windows (16.75 KB, patch)
2006-05-18 16:18 PDT, steve.swanson
no flags Details | Diff | Splinter Review
screenshot using the default mathml.css (33.70 KB, image/png)
2006-05-18 16:19 PDT, steve.swanson
no flags Details
screenshot using Lucida Sans Unicode as primary math font-family (33.60 KB, image/png)
2006-05-18 16:20 PDT, steve.swanson
no flags Details
Windows screenshot after changes from bug 324560 (33.31 KB, image/png)
2006-06-12 12:01 PDT, steve.swanson
no flags Details
implement nsThebesRenderingContext::GetBoundingMetrics() on Windows (21.13 KB, patch)
2006-06-21 16:21 PDT, steve.swanson
no flags Details | Diff | Splinter Review
screenshot base on Uniscribe version of patch (with Lucida Sans Unicode) (32.08 KB, image/png)
2006-06-21 16:32 PDT, steve.swanson
no flags Details
revised patch, removing duplicate code (21.37 KB, patch)
2006-07-08 09:43 PDT, steve.swanson
no flags Details | Diff | Splinter Review
get bounding metrics directly from GetGlyphOutline() (28.61 KB, patch)
2006-07-11 15:25 PDT, steve.swanson
no flags Details | Diff | Splinter Review
screenshot based on new patch w/ default MathML CSS (33.73 KB, image/png)
2006-07-11 15:37 PDT, steve.swanson
no flags Details
first draft: support aTightBoundingBox in gfxFont::Measure (11.86 KB, patch)
2007-04-20 09:42 PDT, steve.swanson
no flags Details | Diff | Splinter Review
second draft: support aTightBoundingBox in gfxFont::Measure (13.91 KB, patch)
2007-04-23 20:47 PDT, steve.swanson
no flags Details | Diff | Splinter Review
revised as per comments (14.43 KB, patch)
2007-04-26 16:37 PDT, steve.swanson
no flags Details | Diff | Splinter Review
further improvements (14.03 KB, patch)
2007-04-26 17:54 PDT, steve.swanson
no flags Details | Diff | Splinter Review
fix one more problem (14.01 KB, patch)
2007-04-26 21:21 PDT, steve.swanson
roc: review+
roc: superreview+
Details | Diff | Splinter Review
add implementation of nsThebesRenderingContext::GetBoundingMetricsInternal (28.64 KB, patch)
2007-04-29 21:33 PDT, steve.swanson
no flags Details | Diff | Splinter Review
screenshot based on last patch (with Lucide Sans Unicode) (35.57 KB, image/png)
2007-04-29 21:37 PDT, steve.swanson
no flags Details
bounding box & symbolic font converter for mac (145.61 KB, patch)
2007-07-29 05:13 PDT, YAMASHITA Makoto
no flags Details | Diff | Splinter Review
symbolic font -> uconv converter table (4.09 KB, text/plain)
2007-07-29 05:15 PDT, YAMASHITA Makoto
no flags Details
thebes.pkg (50 bytes, text/plain)
2007-07-29 05:17 PDT, YAMASHITA Makoto
no flags Details
Incorporate fixes from bug: 96041 (193.60 KB, patch)
2007-07-31 19:12 PDT, YAMASHITA Makoto
no flags Details | Diff | Splinter Review
nsBoundingMetrics changes (12.29 KB, patch)
2007-09-23 21:37 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
symbolic font converter for mac (110.34 KB, patch)
2007-09-23 21:41 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
macos firefox build of "MathML in Action" screenshot (101.73 KB, image/png)
2007-09-24 03:09 PDT, Vlad Sukhoy
no flags Details
MathML start page on Windows using a port of above symfont converter (31.35 KB, image/png)
2007-10-09 00:01 PDT, Vlad Sukhoy
no flags Details
implement nsIRenderingContext::GetBoundingMetrics() (10.73 KB, patch)
2007-11-08 18:34 PST, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
implement nsIRenderingContext::GetBoundingMetrics() v3 [checked in] (10.72 KB, patch)
2007-11-11 16:38 PST, Karl Tomlinson (:karlt)
pavlov: review+
Details | Diff | Splinter Review
A short and simple MathML test XHTML page (13.17 KB, application/xml)
2007-12-16 16:37 PST, Aleksander Adamowski
no flags Details
Screenshot from firefox 2.0.0.11 - correct rendering (28.98 KB, image/png)
2007-12-16 16:38 PST, Aleksander Adamowski
no flags Details
Screenshot from firefox 3 nightly 2007121604 - incorrect rendering (29.62 KB, image/png)
2007-12-16 16:42 PST, Aleksander Adamowski
no flags Details
Testcase for repainting problems (38.40 KB, application/xhtml+xml)
2007-12-30 03:41 PST, Szabolcs Horvát
no flags Details

Description Martijn Wargers [:mwargers] (not working for Mozilla) 2006-01-26 13:47:33 PST
See url.
The MathML all looks very funny and things doesn't seem to get repainted.
Comment 1 Tim Hanson 2006-02-01 14:24:54 PST
indeed
examine the top of my dumb page
http://hardcarve.com/muse/muse.pl/Scratch
Comment 2 Justin Kerk 2006-02-11 15:37:43 PST
A lot of this is probably bug 324560 since those are Unicode mathematical symbols.
Comment 3 Jungshik Shin 2006-02-25 14:08:59 PST
(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.



Comment 4 Henri Sivonen (:hsivonen) 2006-03-01 01:57:34 PST
Fixing this would be a good opportunity to fix bug 289938 as well.
Comment 5 rbs 2006-04-17 15:47:13 PDT
*** Bug 334203 has been marked as a duplicate of this bug. ***
Comment 6 Chris Chiasson 2006-04-18 12:36:03 PDT
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.
Comment 7 Chris Chiasson 2006-04-20 10:04:36 PDT
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.
Comment 8 Vincent Lefevre 2006-05-09 00:52:03 PDT
Dup of bug 321994?
Comment 9 Bill Gianopoulos [:WG9s] 2006-05-09 07:36:08 PDT
(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.
Comment 10 steve.swanson 2006-05-18 16:18:26 PDT
Created attachment 222561 [details] [diff] [review]
implement nsThebesRenderingContext::GetBoundingMetrics() on Windows

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?
Comment 11 steve.swanson 2006-05-18 16:19:35 PDT
Created attachment 222562 [details]
screenshot using the default mathml.css
Comment 12 steve.swanson 2006-05-18 16:20:46 PDT
Created attachment 222563 [details]
screenshot using Lucida Sans Unicode as primary math font-family
Comment 13 Stuart Parmenter 2006-05-18 19:17:34 PDT
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.
Comment 14 steve.swanson 2006-05-19 10:33:04 PDT
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).
Comment 15 Hixie (not reading bugmail) 2006-06-08 15:35:46 PDT
Pav, any news on this? I can't use MathML at all at the moment on the trunk.
Comment 16 steve.swanson 2006-06-12 12:01:29 PDT
Created attachment 225298 [details]
Windows screenshot after changes from bug 324560

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.
Comment 17 Stuart Parmenter 2006-06-12 12:22:51 PDT
You need GetBoundingMetrics to be implemented for the uniscribe case for mathml to really work.
Comment 18 steve.swanson 2006-06-21 16:21:32 PDT
Created attachment 226559 [details] [diff] [review]
implement nsThebesRenderingContext::GetBoundingMetrics() on Windows

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.
Comment 19 steve.swanson 2006-06-21 16:32:20 PDT
Created attachment 226561 [details]
screenshot base on Uniscribe version of patch (with Lucida Sans Unicode)

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).
Comment 20 steve.swanson 2006-07-05 17:44:43 PDT
What can I do to help move this bug along?  Are we waiting for STIX fonts, other platforms, or something else?
Comment 21 Stuart Parmenter 2006-07-05 20:04:17 PDT
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.
Comment 22 Stuart Parmenter 2006-07-05 20:15:01 PDT
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
Comment 23 steve.swanson 2006-07-08 09:43:38 PDT
Created attachment 228542 [details] [diff] [review]
revised patch, removing duplicate code

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.
Comment 24 steve.swanson 2006-07-10 21:33:24 PDT
Ah.  The transformation matrix argument to GetGlyphOutline() is required!  Working on an improved patch.
Comment 25 steve.swanson 2006-07-11 15:25:53 PDT
Created attachment 228865 [details] [diff] [review]
get bounding metrics directly from GetGlyphOutline()

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.
Comment 26 steve.swanson 2006-07-11 15:37:34 PDT
Created attachment 228868 [details]
screenshot based on new patch w/ default MathML CSS

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.
Comment 27 Joe Java 2006-08-14 10:32:25 PDT
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).




Comment 28 YAMASHITA Makoto 2006-08-18 06:22:03 PDT
(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.
Comment 29 Stuart Parmenter 2006-09-21 15:36:11 PDT
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.
Comment 30 Justin Kerk 2006-12-13 19:12:39 PST
*** Bug 363776 has been marked as a duplicate of this bug. ***
Comment 31 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-01-18 15:49:00 PST
This bug has got blocking 1.9- now, do we really want to possibly ship Firefox with this bug?
Comment 32 Alex Vincent [:WeirdAl] 2007-01-18 15:59:12 PST
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...
Comment 33 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-01-18 16:03:20 PST
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.
Comment 34 Brendan Eich [:brendan] 2007-01-18 16:16:07 PST
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
Comment 35 Brendan Eich [:brendan] 2007-01-18 16:19:07 PST
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
Comment 36 Brendan Eich [:brendan] 2007-01-18 16:29:23 PST
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
Comment 37 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-01-18 17:31:56 PST
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.
Comment 38 steve.swanson 2007-01-18 17:39:38 PST
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.
Comment 39 rbs 2007-01-19 16:38:48 PST
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.
Comment 40 Brendan Eich [:brendan] 2007-01-19 16:46:06 PST
Yay -- thanks, rbs.

/be
Comment 41 Henri Sivonen (:hsivonen) 2007-01-25 08:37:44 PST
> 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).
Comment 42 rbs 2007-01-25 13:12:48 PST
>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.
Comment 43 Henri Sivonen (:hsivonen) 2007-01-29 06:38:05 PST
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.)
Comment 44 Henri Sivonen (:hsivonen) 2007-01-29 06:45:04 PST
Just a thought: Would it be feasible to draw stretchy glyphs as graphics from the Cairo point of view instead of using a font?
Comment 45 Wayne Mery (:wsmwk, NI for questions) 2007-02-23 15:04:25 PST
*** Bug 370411 has been marked as a duplicate of this bug. ***
Comment 46 Vlad Sukhoy 2007-04-08 18:59:05 PDT
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?
Comment 47 steve.swanson 2007-04-08 19:41:57 PDT
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.

Comment 48 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-04-09 17:40:08 PDT
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.
Comment 49 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-04-09 17:42:27 PDT
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.
Comment 50 steve.swanson 2007-04-20 09:42:46 PDT
Created attachment 262272 [details] [diff] [review]
first draft: support aTightBoundingBox in gfxFont::Measure

(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.
Comment 51 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-04-21 04:40:43 PDT
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).
Comment 52 steve.swanson 2007-04-23 20:47:53 PDT
Created attachment 262593 [details] [diff] [review]
second draft: support aTightBoundingBox in gfxFont::Measure

Factored out duplicate code into a static helper.  Omitted outer spacing in tight case.
Comment 53 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-04-25 18:04:52 PDT
+    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.
Comment 54 steve.swanson 2007-04-26 16:37:15 PDT
Created attachment 262960 [details] [diff] [review]
revised as per comments

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.
Comment 55 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-04-26 16:53:26 PDT
+        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.
Comment 56 steve.swanson 2007-04-26 17:54:45 PDT
Created attachment 262968 [details] [diff] [review]
further improvements

Cleaned up as per comments.

I don't know anything about Pango, so can't say whether it needs its own Measure().
Comment 57 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-04-26 19:48:05 PDT
What about this?

> +        double bb_width = (-extents.x_bearing +
> extents.width)*appUnitsPerDevUnit;
>
> Why isn't this just extents.width*appUnitsPerDevUnit?
Comment 58 steve.swanson 2007-04-26 21:21:29 PDT
Created attachment 262984 [details] [diff] [review]
fix one more problem

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.
Comment 59 steve.swanson 2007-04-27 08:15:30 PDT
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.
Comment 60 rbs 2007-04-27 15:42:28 PDT
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
Comment 61 rbs 2007-04-28 01:26:03 PDT
Also of note is the activation of the hook in nsThebesRenderingContext::GetBoundingMetricsInternal.
Comment 62 steve.swanson 2007-04-29 21:33:42 PDT
Created attachment 263230 [details] [diff] [review]
add implementation of nsThebesRenderingContext::GetBoundingMetricsInternal

GetBoundingMetricsInternal just calls nsThebesFontMetrics::GetBoundingMetrics, which I implemented.
Comment 63 steve.swanson 2007-04-29 21:37:19 PDT
Created attachment 263231 [details]
screenshot based on last patch (with Lucide Sans Unicode)

I guess I don't understand exactly what works and what doesn't, but it's not complete nonsense.
Comment 64 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-05-19 08:58:48 PDT
*** Bug 380646 has been marked as a duplicate of this bug. ***
Comment 65 YAMASHITA Makoto 2007-07-29 05:13:13 PDT
Created attachment 274342 [details] [diff] [review]
bounding box & symbolic font converter for mac

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.
Comment 66 YAMASHITA Makoto 2007-07-29 05:15:31 PDT
Created attachment 274343 [details]
symbolic font -> uconv converter table

fontEncoding.properties: should go into gfx/thebes/src
Comment 67 YAMASHITA Makoto 2007-07-29 05:17:04 PDT
Created attachment 274344 [details]
thebes.pkg

thebes.pkg: should go into gfx/thebes/src/
Comment 68 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-07-29 15:54:09 PDT
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.
Comment 69 YAMASHITA Makoto 2007-07-31 19:12:34 PDT
Created attachment 274711 [details] [diff] [review]
Incorporate fixes from bug: 96041

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).
Comment 70 Joe Java 2007-08-14 05:39:04 PDT
*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).
Comment 71 Ray Kiddy 2007-09-04 23:03:36 PDT
*** Bug 394957 has been marked as a duplicate of this bug. ***
Comment 72 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-09-17 15:40:27 PDT
> 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.
Comment 73 Karl Tomlinson (:karlt) 2007-09-23 21:37:19 PDT
Created attachment 282067 [details] [diff] [review]
nsBoundingMetrics changes

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.)
Comment 74 Karl Tomlinson (:karlt) 2007-09-23 21:41:46 PDT
Created attachment 282068 [details] [diff] [review]
symbolic font converter for mac

Remaining changes from patch in comment #69 that are not handled in bug 385265.
Comment 75 Vlad Sukhoy 2007-09-24 03:09:37 PDT
Created attachment 282094 [details]
macos firefox build of "MathML in Action" screenshot

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..
Comment 76 Vlad Sukhoy 2007-10-09 00:01:27 PDT
Created attachment 284111 [details]
MathML start page on Windows using a port of above symfont converter

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.
Comment 77 Karl Tomlinson (:karlt) 2007-10-09 23:02:02 PDT
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/
Comment 78 Vlad Sukhoy 2007-10-09 23:25:26 PDT
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.
Comment 79 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-10-24 01:27:30 PDT
Karl's the man
Comment 80 Joe Java 2007-10-31 13:44:31 PDT
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.

 
Comment 81 Chris Chiasson 2007-10-31 14:03:20 PDT
(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) ...
Comment 82 Karl Tomlinson (:karlt) 2007-11-08 18:34:21 PST
Created attachment 287939 [details] [diff] [review]
implement nsIRenderingContext::GetBoundingMetrics()

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.
Comment 83 Karl Tomlinson (:karlt) 2007-11-11 16:38:55 PST
Created attachment 288247 [details] [diff] [review]
implement nsIRenderingContext::GetBoundingMetrics() v3 [checked in]

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.)
Comment 84 -fullmetaljacket- 2007-11-11 20:55:45 PST
removing [wanted-1.9], since was already blocking 1.9

Comment 85 Karl Tomlinson (:karlt) 2007-11-11 21:18:18 PST
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
Comment 86 distler 2007-11-12 07:12:35 PST
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. :-(
Comment 87 Karl Tomlinson (:karlt) 2007-12-05 16:20:16 PST
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.
Comment 88 Bill Gianopoulos [:WG9s] 2007-12-06 03:31:27 PST
(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.
Comment 89 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-12-06 13:16:54 PST
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 ;)
Comment 90 Peter van der Woude [:Peter6] 2007-12-06 14:26:26 PST
(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
Comment 91 Jean-Marc Desperrier 2007-12-12 08:32:31 PST
(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.

Comment 92 Aleksander Adamowski 2007-12-16 16:37:00 PST
Created attachment 293443 [details]
A short and simple MathML test XHTML page

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).
Comment 93 Aleksander Adamowski 2007-12-16 16:38:50 PST
Created attachment 293444 [details]
Screenshot from firefox 2.0.0.11 - correct rendering
Comment 94 Aleksander Adamowski 2007-12-16 16:42:07 PST
Created attachment 293445 [details]
Screenshot from firefox 3 nightly 2007121604 - incorrect rendering
Comment 95 Aleksander Adamowski 2007-12-16 16:48:03 PST
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.
Comment 96 Karl Tomlinson (:karlt) 2007-12-16 17:34:55 PST
(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.
Comment 97 Bill Gianopoulos [:WG9s] 2007-12-29 09:13:23 PST
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.
Comment 98 Ryan VanderMeulen [:RyanVM] 2007-12-29 09:16:24 PST
I see it as well with an Opteron 165 and an ATI X300 video card.
Comment 99 Bill Gianopoulos [:WG9s] 2007-12-29 09:22:53 PST
(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.
Comment 100 Bill Gianopoulos [:WG9s] 2007-12-29 15:16:21 PST
(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?
Comment 101 Karl Tomlinson (:karlt) 2007-12-29 16:52:08 PST
The fix for bug 161155 may have helped this issue.  Is anyone still not seeing any math with this morning's nightlies?
Comment 102 Szabolcs Horvát 2007-12-30 03:41:19 PST
Created attachment 294891 [details]
Testcase for repainting problems

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.
Comment 103 Bill Gianopoulos [:WG9s] 2007-12-30 05:03:37 PST
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.
Comment 104 Bill Gianopoulos [:WG9s] 2007-12-30 07:44:00 PST
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.
Comment 105 Ryan VanderMeulen [:RyanVM] 2007-12-30 08:00:47 PST
With the Cambria and STIX fonts installed, are the Mathematica fonts still required for proper MathML support?
Comment 106 Bill Gianopoulos [:WG9s] 2007-12-30 08:07:42 PST
(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.

Comment 107 Szabolcs Horvát 2007-12-30 08:57:54 PST
(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.)
Comment 108 Karl Tomlinson (:karlt) 2007-12-30 17:05:14 PST
(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.
Comment 109 Karl Tomlinson (:karlt) 2007-12-30 17:22:42 PST
(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.
Comment 110 Karl Tomlinson (:karlt) 2007-12-30 17:36:14 PST
(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).
Comment 111 Bill Gianopoulos [:WG9s] 2007-12-31 04:37:12 PST
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.
Comment 112 Bill Gianopoulos [:WG9s] 2007-12-31 06:38:14 PST
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?
Comment 113 Bill Gianopoulos [:WG9s] 2007-12-31 07:15:31 PST
(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.
Comment 114 Karl Tomlinson (:karlt) 2008-01-01 17:29:24 PST
(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.
Comment 115 Aleksander Adamowski 2008-01-15 08:00:39 PST
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
Comment 116 Karl Tomlinson (:karlt) 2008-02-01 21:58:45 PST
Moving relnote keyword to bug 363240, as that better represents the most noticeable remaining issue.
Comment 117 Joe Java 2008-02-14 10:51:26 PST
*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.
Comment 118 Szabolcs Horvát 2008-02-14 12:41:03 PST
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

Comment 119 Karl Tomlinson (:karlt) 2008-02-14 12:59:45 PST
(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).
Comment 120 Karl Tomlinson (:karlt) 2008-03-16 13:27:46 PDT
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).
Comment 121 Karl Tomlinson (:karlt) 2008-03-16 16:00:42 PDT
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.
Comment 122 Karl Tomlinson (:karlt) 2008-03-16 16:09:37 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.