Bug 324857 - MathML all screwed up in Cairo builds
 Summary: MathML all screwed up in Cairo builds
 Status: RESOLVED FIXED cairo regression, testcase Core Components Graphics (show other bugs) Trunk All All P1 critical --- Karl Tomlinson (ni?:karlt) (view as bug list) 96041 161155 289938 324560 348577 363240 385265 397288 399940 400207 400938 401178 401988 410284 410331 410557 410701 412033 412880 413115 416062 334737 371481 377499 405081 Show dependency tree / graph

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+
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 | 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 | 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 | Review
get bounding metrics directly from GetGlyphOutline() (28.61 KB, patch)
2006-07-11 15:25 PDT, steve.swanson
no flags Details | Diff | 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 | Review
second draft: support aTightBoundingBox in gfxFont::Measure (13.91 KB, patch)
2007-04-23 20:47 PDT, steve.swanson
no flags Details | Diff | Review
revised as per comments (14.43 KB, patch)
2007-04-26 16:37 PDT, steve.swanson
no flags Details | Diff | Review
further improvements (14.03 KB, patch)
2007-04-26 17:54 PDT, steve.swanson
no flags Details | Diff | Review
fix one more problem (14.01 KB, patch)
2007-04-26 21:21 PDT, steve.swanson
roc: review+
roc: superreview+
Details | Diff | Review
add implementation of nsThebesRenderingContext::GetBoundingMetricsInternal (28.64 KB, patch)
2007-04-29 21:33 PDT, steve.swanson
no flags Details | Diff | 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 | 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 | Review
nsBoundingMetrics changes (12.29 KB, patch)
2007-09-23 21:37 PDT, Karl Tomlinson (ni?:karlt)
no flags Details | Diff | Review
symbolic font converter for mac (110.34 KB, patch)
2007-09-23 21:41 PDT, Karl Tomlinson (ni?:karlt)
no flags Details | Diff | Review
macos firefox build of "MathML in Action" screenshot (101.73 KB, image/png)
no flags Details
MathML start page on Windows using a port of above symfont converter (31.35 KB, image/png)
no flags Details
implement nsIRenderingContext::GetBoundingMetrics() (10.73 KB, patch)
2007-11-08 18:34 PST, Karl Tomlinson (ni?:karlt)
no flags Details | Diff | Review
implement nsIRenderingContext::GetBoundingMetrics() v3 [checked in] (10.72 KB, patch)
2007-11-11 16:38 PST, Karl Tomlinson (ni?:karlt)
pavlov: review+
Details | Diff | Review
A short and simple MathML test XHTML page (13.17 KB, application/xml)
no flags Details
Screenshot from firefox 2.0.0.11 - correct rendering (28.98 KB, image/png)
 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. Tim Hanson 2006-02-01 14:24:54 PST indeed examine the top of my dumb page http://hardcarve.com/muse/muse.pl/Scratch Justin Kerk 2006-02-11 15:37:43 PST A lot of this is probably bug 324560 since those are Unicode mathematical symbols. 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.  Henri Sivonen (:hsivonen) 2006-03-01 01:57:34 PST Fixing this would be a good opportunity to fix bug 289938 as well. rbs 2006-04-17 15:47:13 PDT *** Bug 334203 has been marked as a duplicate of this bug. *** 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. 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. Vincent Lefevre 2006-05-09 00:52:03 PDT Dup of bug 321994? 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.  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? steve.swanson 2006-05-18 16:19:35 PDT Created attachment 222562 [details] screenshot using the default mathml.css steve.swanson 2006-05-18 16:20:46 PDT Created attachment 222563 [details] screenshot using Lucida Sans Unicode as primary math font-family 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. 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). 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. 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. Stuart Parmenter 2006-06-12 12:22:51 PDT You need GetBoundingMetrics to be implemented for the uniscribe case for mathml to really work. 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. 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). 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? 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. 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 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. steve.swanson 2006-07-10 21:33:24 PDT Ah. The transformation matrix argument to GetGlyphOutline() is required! Working on an improved patch. 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. 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. 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).  YAMASHITA Makoto 2006-08-18 06:22:03 PDT (In reply to comment #26) > Results are similar to those seen in attachment 222562 [details] . 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. 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. Justin Kerk 2006-12-13 19:12:39 PST *** Bug 363776 has been marked as a duplicate of this bug. *** 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? 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... 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. 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 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 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 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. 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. 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. Brendan Eich [:brendan] 2007-01-19 16:46:06 PST Yay -- thanks, rbs. /be 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). 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. 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.) 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? Wayne Mery (:wsmwk, NI for questions) 2007-02-23 15:04:25 PST *** Bug 370411 has been marked as a duplicate of this bug. *** 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? 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.  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. 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. 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. 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). 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. 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. 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. Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-04-26 16:53:26 PDT + nsAutoTArray 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. 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(). 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?  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. 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 a 0 x [/itex] you don't see the a, but in 0 x [/itex] you don't see the 0. 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 rbs 2007-04-28 01:26:03 PDT Also of note is the activation of the hook in nsThebesRenderingContext::GetBoundingMetricsInternal. 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. 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. 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. *** 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. 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 YAMASHITA Makoto 2007-07-29 05:17:04 PDT Created attachment 274344 [details] thebes.pkg thebes.pkg: should go into gfx/thebes/src/ 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. 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). 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).  Ray Kiddy 2007-09-04 23:03:36 PDT *** Bug 394957 has been marked as a duplicate of this bug. *** 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. Karl Tomlinson (ni?: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.) Karl Tomlinson (ni?: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. 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.. 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. Karl Tomlinson (ni?: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/ 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. Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-10-24 01:27:30 PDT Karl's the man 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.  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) ...  Karl Tomlinson (ni?: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. Karl Tomlinson (ni?: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.) -fullmetaljacket- 2007-11-11 20:55:45 PST removing [wanted-1.9], since was already blocking 1.9  Karl Tomlinson (ni?: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 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. :-( Karl Tomlinson (ni?: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. 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. 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 ;) 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  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.  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). Aleksander Adamowski 2007-12-16 16:38:50 PST Created attachment 293444 [details] Screenshot from firefox 2.0.0.11 - correct rendering Aleksander Adamowski 2007-12-16 16:42:07 PST Created attachment 293445 [details] Screenshot from firefox 3 nightly 2007121604 - incorrect rendering 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.  Karl Tomlinson (ni?: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.  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. 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. 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. 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? Karl Tomlinson (ni?: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? 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. 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. 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. 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? 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.  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.) Karl Tomlinson (ni?: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.  Karl Tomlinson (ni?: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. Karl Tomlinson (ni?: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). 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. 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? 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. Karl Tomlinson (ni?: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. 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  Karl Tomlinson (ni?:karlt) 2008-02-01 21:58:45 PST Moving relnote keyword to bug 363240, as that better represents the most noticeable remaining issue. 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. 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}'
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021404 Minefield/3.0b4pre ID:2008021404  Karl Tomlinson (ni?: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).  Karl Tomlinson (ni?: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). Karl Tomlinson (ni?: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 (𝒜), for example, can be rendered with STIX Beta fonts (bug 412880) even without Cambria Math installed. Karl Tomlinson (ni?:karlt) 2008-03-16 16:09:37 PDT The gfx issues here are now fixed. There are still positioning issues when tables enclose either (bug 363240) or (e.g. italic) characters with glyph extents outside their advanced widths (bug 415413), but those are layout (not gfx) issues.