erratic baseline for vertical text in reference files for 1136557-*-nested-spans reftests

RESOLVED WONTFIX

Status

()

Core
Layout: Text
RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: jfkthame, Assigned: jtd)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
In some cases involving fractional font sizes, the reference renderings of the writing-mode/1136557-*-nested-spans reftests on Windows show an erratic baseline for some of the vertical text: at some point within the test string, the glyphs suddenly shift right (upwards in line-relative terms) by a pixel.

There seems to be no consistency to when this happens: it's occurring within a single element, frame and textrun, so it's not caused by layout mispositioning frames in relation to each other; it happens purely within a single text frame.

I'm marking these tests fuzzy in bug 1145218, which seems to have exacerbated the problem (though one of them was already fuzzy), but we should try to figure out why this rendering glitch happens and how we can prevent it.

Updated

3 years ago
Assignee: nobody → jdaggett
(Reporter)

Updated

3 years ago
Blocks: 1138384
(Assignee)

Comment 1

3 years ago
I looked into this a bit yesterday. The problematic case is Windows/GDI
with integer pixel placement. The test/reftest content difference is
basically xyzzy with/without a <span> inserted after the xy, for
different font sizes. Both are shaped the same way, however the glyphs
are rendered ever so slightly differently. Differences occur for Times
New Roman at size = 12.75px, the two 'z' glyphs after the span shift one
pixel to the right compared to the reference image.

For spans of Latin text rendered sideways in vertical text runs, we
shape the text horizontally and apply a rotation to place the text
inline. See the code in gfxFont::Draw.

http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxFont.cpp#1896

Note that the above calculations don't take into account being on a
integer pixel grid.

Glyphs rendered without a span:

matrix: [ 0.000 1.000 -1.000 0.000 217.500 -102.000 ] 
glyphs: g:91 x:110.000 y:111.000 g:92 x:115.000 y:111.000
        g:93 x:122.000 y:111.000 g:93 x:127.000 y:111.000 g:92 x:132.000 y:111.000

Glyphs rendered with a span are split into two different flushes:

matrix: [ 0.000 1.000 -1.000 0.000 217.500 -102.000 ] 
glyphs: g:91 x:110.000 y:111.000 g:92 x:115.000 y:111.000

matrix: [ 0.000 1.000 -1.000 0.000 229.500 -90.000 ]  
glyphs: g:93 x:110.000 y:123.000 g:93 x:115.000 y:123.000 g:92 x:120.000 y:123.000

Note the horizontal translation by 0.5px, I'm guessing that's the
problem here. If that value is slightly more or less than a 0.5px
boundary, GDI integer pixel snapping will push the glyphs one way or the
other, such that the slightly different conditions of the test vs. the
reference is enough to cause different glyph placement.

At this point, I think I would be fine with simply noting these
differences and leave this as "won't fix", since all modern font
backends support subpixel placement and it's only in the integer pixel
placement case (e.g. GDI) where we run into minor placement problems
like this.
(Assignee)

Comment 2

3 years ago
Marking this as won't fix for now. If we decide that we really need to tackle this then we can think a little more how to try and maintain the same matrix across a line so that small rounding errors don't lead to odd pixel placement differences like this.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.