User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081014 Minefield/3.1b2pre Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081014 Minefield/3.1b2pre The glyphs that represent the square roots in test 13 and the brackets used in test 14 do not display completely, BUT DO show completely if the page is refreshed. I am using the beta Stix fonts. Reproducible: Sometimes Steps to Reproduce: 1.go to http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml 2.look at tests 13 and 14 3.reload the page and tests look correct Actual Results: There is an image of the incorrect rendering http://joejava.wetpaint.com/photo/2254398/incorrect+rendering Expected Results: Here is an image of the correct rendering (refreshed the page) http://joejava.wetpaint.com/photo/2254433/correct+rendering The same behavior is observed on Vista with latest build and beta Stix fonts.

Notice that the square roots in test 13 are wrong. Notice that the round brackets in test 14 only have the bottom half

The page was refreshed and now the square roots of test 13 are complete as are the round brackets of test 14.

I can't reproduce this, even on my old PowerPC G4 running OS X 10.4.11. I tested in both Firefox 3.0.3 and today's Minefield nightly (what will become Firefox 3.1).

Notice the squareroots in test 13 have "holes" in the glyph and in test 14 the rounded brackets are incomplete. These problems go away when the page is refreshed. I am using a 24inch display on Vista and a 23inch display on OS X. Perhaps smaller displays do not show this problem. The problem does not always show, you only see it when the page is first loaded.

I see behavior that is different than the others shown. Both of these versions were on a Mac OS X 10.4.11 machine, but one was 3.0.4 and one was built by me. They look the same, though.

You need the STIX beta fonts to get the correct look. (In reply to comment #6) > Created an attachment (id=349336) [details] > different problem visible on Mac OS X 10.4.11 > > > I see behavior that is different than the others shown. Both of these versions > were on a Mac OS X 10.4.11 machine, but one was 3.0.4 and one was built by me. > They look the same, though.

Note that the slants on some of the square roots is not drawn, this goes away if the page is refreshed. The effect can also occur by scrolling up and down revealing test 13 several times.

Same error using Vista and build 20081216044608 After a refresh the glyphs are drawn correctly. Static Web pages should not need to be refreshed to look OK.

OS X 10.4.11 build 20081217020325 Scrolling up and down a few times and squareroots displayed wrong. This should never happen.

(In reply to comment #7) > You need the STIX beta fonts to get the correct look. So you need to install these fonts to see these problems?

(In reply to comment #12) > (In reply to comment #7) > > > You need the STIX beta fonts to get the correct look. > > So you need to install these fonts to see these problems? Hmmm... does it look OK without the STIX beta fonts? (I don't know, since I have had them installed since they first came out over a year ago) I think they are need to view the page. The final version of the STIX fonts is set to be released... soon.

(In reply to comment #13) > Hmmm... does it look OK without the STIX beta fonts? Yes. See comment #3. Try temporarily uninstalling your STIX fonts (and maybe also other fonts that you've installed), and see what happens.

Here is what the page looks like without STIX fonts. The whole idea of the STIX fonts is fix this problem. Whenever people load a page with mathml, they will either already have the STIX font or be prompted to download it and then the rendered page will look the same everywhere.

That's not what I see. Here's part of your example (including tests 13, 14, and 19). I tested on OS X 10.4.11 (on an early MacBook Pro), in this case using Firefox 3.0.4. I didn't reload the page (what you see is what I got the first time I loaded the page). I don't have any fonts beyond what came with the OS.

Interestingly, I didn't see any warning about not having the STIX fonts installed ... though I've definitely never installed them.

You listed the failed tests, I think you meant test 16 (super small integration sign) and not 14. No, FF does not prompt for download of STIX fonts (they are still in beta), but "should" when they are released in their final version (real soon now).

Frankly I'm not a font maven. So people may be able to see problems in my attached screenshots that I can't see. But they're guaranteed to be uncomplicated by extraneous font issues ... since I've never installed any "extra" fonts.

With FF 3.1 et seq, you can use downloadable fonts in a web page. So, that means that if the page is using downloadable fonts, you do not have to install the fonts on your machine. I think we can I think this may make MathML testing easier. I recently posted about this in the mathml newsgroup. Also, you can see this article on using downloadable fonts: http://www.alistapart.com/articles/cssatten

Let's keep this bug to the originally reported issue of partial painting of glyphs until a complete repaint. This is also reproducible on Linux, particularly noticeable when scrolling. It is a regression since Firefox 3.0.

This bug was not present in Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1a1pre) Gecko/2008072202 Minefield/3.1a1pre but appeared in Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1a1pre) Gecko/2008072302 Minefield/3.1a1pre but was not in Shiretoko Alpha 1. That suggests this regression window: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=july+21+2008+23%3A00&enddate=july+23+2008+3%3A00

This bug was triggered by this changeset: http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=5305b356a7b1 I would be a bit surprised that I cairo upgraded would be the root cause, but maybe it's related to bug 453519.

Since this is a regression it would be nice if we could fix it --- especially since it's likely to be in cairo so it could affect other things.

The heuristics in _cairo_gstate_transform_glyphs_to_backend for determining whether a glyph needs to be drawn based on the em height of the font are failing here. http://cgit.freedesktop.org/cairo/commit/?id=a30209402c7160af257e1ea027e9e2cdab5b5aec "scale" is effectively the em height in pixels. If a glyph extends more than 2 em above or to the left of its origin or more than 1 em below or to the right of its origin, then the extending part of the glyph will sometimes not get drawn. Seems like the glyph bounding boxes from the head table are wanted here: http://www.microsoft.com/typography/otspec/head.htm

(In reply to comment #28) > The heuristics in _cairo_gstate_transform_glyphs_to_backend for determining > whether a glyph needs to be drawn based on the em height of the font are > failing here. > > http://cgit.freedesktop.org/cairo/commit/?id=a30209402c7160af257e1ea027e9e2cdab5b5aec > > "scale" is effectively the em height in pixels. > > If a glyph extends more than 2 em above or to the left of its origin or more > than 1 em below or to the right of its origin, then the extending part of the > glyph will sometimes not get drawn. Karl, that doesn't explain why a glyph that is in the visible area of the drawable is not displayed. And is it really a full glyph not being displayed? (not sure how the sqrt sign is constructed). And why would have a font have glyphs so large compared to its em anyway? > Seems like the glyph bounding boxes from the head table are wanted here: > > http://www.microsoft.com/typography/otspec/head.htm

(In reply to comment #29) > (In reply to comment #28) > > Karl, that doesn't explain why a glyph that is in the visible area of the > drawable is not displayed. And is it really a full glyph not being > displayed? It's only part glyphs that are not being displayed. And this is happening when the parts are not within the 3 em square. Often only the invalidated rectangle is painted, and so only a part of a glyph is drawn. The most common situation for this is scrolling where only the new content entering the visible rectangle gets drawn. > (not sure how the sqrt sign is constructed). The horizontal line is always drawn. The sqrt root symbol to the left of the expression, can be drawn in a couple of different ways depending on the height of the expression. * For shorter to medium height expressions, the sqrt root symbol (without the horizontal line) is a single glyph, chosen to match the height of the expression. It is the larger of these glyphs that demonstrate the problem most clearly. * For taller expressions, a taller sqrt symbol is constructed from a radical symbol bottom (U+23B7) as well as simple straight vertical extenders (and a corner which is not really necessary). It looks like (but I haven't checked this particular glyph) the radical symbol bottom extends slightly further than 2 em above the origin and so displays this bug occassionally. > And why would have a font have glyphs so large compared to its em anyway? In mathematics, grouping symbols (such as parentheses), accents, n-ary operators, and radical symbols vary in height according to their related expression. Fonts such as Computer Modern, Cambria Math, and STIX support these symbols by providing glyphs of different sizes. (Sometimes some symbols are drawn by combining multiple glyphs, but not all symbols can be easily constructed this way - joining is only supported in directions aligned with the vertical and horizontal axes.) The thickness of the strokes in these symbols is mostly independent of the height of the expression, and so symbols of different sizes come from a font with a single em height. The extents of the glyphs could be several ems. I imagine there are likely to be non-mathematical situations having the same issues. * Glyphs for some non-spacing combining characters may have the origin positioned next to an imaginary base character and so the distance from the origin could be larger. Double combining characters U+035C to U+0362 could possibly extended further than 1 em to the right of their origin. * Arabic format characters U+0600 to U+0603 may be supported by fonts providing several glyphs of different sizes. * Some characters are wide. U+0B94 TAMIL LETTER AU and U+0D10 MALAYALAM LETTER AI look like they may be examples of this. * IIUC ligatures for multiple characters could be arbitrarily wide or high.

Thanks Karl. So, we can do two things: - Use the font bounding box from the os2 table. I'm not sure that all fonts set this value correctly. - Use a margin of 10em instead of current 2em. Can we just do the latter? Even if I do the former I can only do it for the FreeType backend and have to wait for others to implement it on the other backends. If the latter works good enough, lets go with it.

I committed the 10em change upstream: commit 28a72648ba7abe02ebd4df7234424e333b85dc9c Author: Behdad Esfahbod <behdad@behdad.org> Date: Tue Dec 30 13:48:47 2008 -0500 [gstate] Change the glyph dropping safety margin from 2em to 10em The small margin caused bugs with math fonts. See: https://bugzilla.mozilla.org/show_bug.cgi?id=460023 diff --git a/src/cairo-gstate.c b/src/cairo-gstate.c index df7ec5c..c79e799 100644 --- a/src/cairo-gstate.c +++ b/src/cairo-gstate.c @@ -1804,7 +1804,6 @@ _cairo_gstate_transform_glyphs_to_backend (cairo_gstate_t*gstate, if (num_transformed_glyphs != NULL) { cairo_rectangle_int_t surface_extents; - double scale = _cairo_scaled_font_get_max_scale (gstate->scaled_font); drop = TRUE; status = _cairo_gstate_int_clip_extents (gstate, &surface_extents); @@ -1814,6 +1813,7 @@ _cairo_gstate_transform_glyphs_to_backend (cairo_gstate_t*gstate, if (status == CAIRO_INT_STATUS_UNSUPPORTED) { drop = FALSE; /* unbounded surface */ } else { + double scale10 = 10 * _cairo_scaled_font_get_max_scale (gstate->scaled_font); if (surface_extents.width == 0 || surface_extents.height == 0) { /* No visible area. Don't draw anything */ *num_transformed_glyphs = 0; @@ -1827,10 +1827,10 @@ _cairo_gstate_transform_glyphs_to_backend (cairo_gstate_t *gstate, * to device if it's going to be visible, but I'm not inclined to * do that now. */ - x1 = surface_extents.x - 2*scale; - y1 = surface_extents.y - 2*scale; - x2 = surface_extents.x + (int) surface_extents.width + scale; - y2 = surface_extents.y + (int) surface_extents.height + scale; + x1 = surface_extents.x - scale10; + y1 = surface_extents.y - scale10; + x2 = surface_extents.x + (int) surface_extents.width + scale10; + y2 = surface_extents.y + (int) surface_extents.height + scale10; } if (!drop)

(In reply to comment #32) > I committed the 10em change upstream: Thanks, Behdad. The largest global bounding box coordinate that I found from a quick look at STIX, Cambria Math, and Asana Math fonts was 4.58 em, so 10 em should be fine for these.

(And tree rules mean we'll need to land this on m-c too.)

Pushed http://hg.mozilla.org/mozilla-central/rev/3c88df574438 I wonder if we could get a reftest here.

I use reftests for MathML testing, but there is a problem in that the images are platform-specific. If there was a way to specify mac|lnx|win in the manifest, and perhaps agree to a canonical screen resolution (per platform) for reference images and test machines, it would be very doable.

I wouldn't want to use reference images, but since the bug is about partial repaints not matching full repaints, we may be able to use the new invalidation support in reftests to test the bug.