incomplete glyphs in mathml torture test page

RESOLVED FIXED

Status

()

Core
MathML
P2
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Joe Java, Assigned: karlt)

Tracking

({fixed1.9.1, polish, regression})

Trunk
PowerPC
All
fixed1.9.1, polish, regression
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(15 attachments)

18.57 KB, image/png
Details
19.14 KB, image/png
Details
36.61 KB, image/jpeg
Details
36.24 KB, image/jpeg
Details
19.56 KB, image/png
Details
39.03 KB, image/jpeg
Details
9.83 KB, image/png
Details
38.94 KB, image/jpeg
Details
18.88 KB, image/png
Details
72.34 KB, image/png
Details
59.47 KB, image/png
Details
59.53 KB, image/png
Details
60.27 KB, image/png
Details
61.32 KB, image/png
Details
5.23 KB, patch
vlad
: review+
Details | Diff | Splinter Review
(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
Created attachment 343220 [details]
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
(Reporter)

Comment 2

9 years ago
Created attachment 343221 [details]
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.
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).
(Reporter)

Comment 4

9 years ago
Created attachment 344566 [details]
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.
(Reporter)

Comment 5

9 years ago
Created attachment 344567 [details]
Vista snip after refresh of page
(Reporter)

Updated

9 years ago
Keywords: polish

Comment 6

9 years ago
Created attachment 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.
(Reporter)

Comment 7

9 years ago
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.
(Reporter)

Comment 8

9 years ago
Created attachment 349384 [details]
made on Vista with build 20081120120920
(Reporter)

Comment 9

9 years ago
Created attachment 349409 [details]
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.
(Reporter)

Comment 10

9 years ago
Created attachment 353390 [details]
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.
(Reporter)

Comment 11

9 years ago
Created attachment 353408 [details]
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.
(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?
(Reporter)

Comment 13

9 years ago
(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.
(Reporter)

Comment 15

9 years ago
Created attachment 353488 [details]
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.
Created attachment 353504 [details]
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.
Created attachment 353508 [details]
No STIX fonts, tests 13, 14, 19, Minefield, OS X 10.4.11
Interestingly, I didn't see any warning about not having the STIX fonts installed ... though I've definitely never installed them.
(Reporter)

Comment 19

9 years ago
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).
Created attachment 353511 [details]
No STIX fonts, tests 19, 22, 23, FF3.0.4, OS X 10.4.11
Created attachment 353513 [details]
No STIX fonts, tests 19, 22, 23, Minefield, OS X 10.4.11
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

9 years ago
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
(Assignee)

Comment 24

9 years ago
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.
Assignee: nobody → mozbugz
Status: UNCONFIRMED → NEW
Component: General → MathML
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → mathml
Target Milestone: --- → mozilla1.9
Version: unspecified → Trunk
(Assignee)

Updated

9 years ago
Flags: blocking1.9.1?
Priority: -- → P4
(Assignee)

Comment 25

9 years ago
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
Keywords: regressionwindow-wanted
(Assignee)

Comment 26

9 years ago
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.
Blocks: 446323
Depends on: 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.
Target Milestone: mozilla1.9 → ---
Flags: blocking1.9.1? → blocking1.9.1+
Priority: P4 → P2
(Assignee)

Comment 28

9 years ago
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

9 years ago
(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
(Assignee)

Comment 30

9 years ago
(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

9 years ago
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

9 years ago
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)
(Assignee)

Comment 33

9 years ago
(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.
(Assignee)

Updated

9 years ago
No longer depends on: 453519
(Assignee)

Comment 34

9 years ago
Created attachment 358511 [details] [diff] [review]
cherry pick patch from cairo for 1.9.1

(And tree rules mean we'll need to land this on m-c too.)
Attachment #358511 - Flags: review?(vladimir)
Whiteboard: [needs landing]
Attachment #358511 - Flags: review?(vladimir) → review+
Pushed http://hg.mozilla.org/mozilla-central/rev/3c88df574438

I wonder if we could get a reftest here.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]

Comment 36

9 years ago
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=460023
Keywords: fixed1.9.1
Whiteboard: [needs 191 landing]
You need to log in before you can comment on or make changes to this bug.