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.

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.

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.