460023 - incomplete glyphs in mathml torture test page

Status: RESOLVED FIXED

(Core :: MathML, defect, P2)

Description

[Joe Java]

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.

Comment 1

[Joe Java]

Attachment: image of incomplete glyphs for tests 13 and 14

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

Comment 2

[Joe Java]

Attachment: image of correct rendering of tests 13 and 14

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

Comment 3

[Steven Michaud [:smichaud] (Retired)]

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

Comment 4

[Joe Java]

Attachment: Vista snip using build 20081023034205

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.

Comment 5

[Joe Java]

Attachment: Vista snip after refresh of page

Comment 6

[Ray Kiddy]

Attachment: 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.

Comment 7

[Joe Java]

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.

Comment 8

[Joe Java]

Attachment: made on Vista with build 20081120120920

Comment 9

[Joe Java]

Attachment: on OS X build 2008112002235

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.

Comment 10

[Joe Java]

Attachment: Notice missing diagonal on square root and incomplete brackets on test 14

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.

Comment 11

[Joe Java]

Attachment: squareroots are not correct

OS X 10.4.11 build 20081217020325

Scrolling up and down a few times and squareroots displayed wrong.

This should never happen.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

(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?

Comment 13

[Joe Java]

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

Comment 14

[Steven Michaud [:smichaud] (Retired)]

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

Comment 15

[Joe Java]

Attachment: Without Stix fonts: test 13, 19, 22, 23 ('j' intersect rightbracket) fail

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.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

Attachment: No STIX fonts, tests 13, 14, 19, FF3.0.4, OS X 10.4.11

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.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

Attachment: No STIX fonts, tests 13, 14, 19, Minefield, OS X 10.4.11

Comment 18

[Steven Michaud [:smichaud] (Retired)]

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

Comment 19

[Joe Java]

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

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Attachment: No STIX fonts, tests 19, 22, 23, FF3.0.4, OS X 10.4.11

Comment 21

[Steven Michaud [:smichaud] (Retired)]

Attachment: No STIX fonts, tests 19, 22, 23, Minefield, OS X 10.4.11

Comment 22

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 23

[Ray Kiddy]

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

Comment 24

[Karl Tomlinson (:karlt)]

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.

Comment 25

[Karl Tomlinson (:karlt)]

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

Comment 26

[Karl Tomlinson (:karlt)]

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.

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 28

[Karl Tomlinson (:karlt)]

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

Comment 29

[Behdad Esfahbod]

(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

Comment 30

[Karl Tomlinson (:karlt)]

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

Comment 31

[Behdad Esfahbod]

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.

Comment 32

[Behdad Esfahbod]

I committed the 10em change upstream:

commit 28a72648ba7abe02ebd4df7234424e333b85dc9c
Author: Behdad Esfahbod <[e-mail]>
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)

Comment 33

[Karl Tomlinson (:karlt)]

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

Comment 34

[Karl Tomlinson (:karlt)]

Attachment: cherry pick patch from cairo for 1.9.1

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

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pushed http://hg.mozilla.org/mozilla-central/rev/3c88df574438

I wonder if we could get a reftest here.

Comment 36

[Ray Kiddy]

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.

Comment 37

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 38

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://bugzilla.mozilla.org/show_bug.cgi?id=460023