Open Bug 1139269 Opened 5 years ago Updated 4 years ago
synthetic subscripts/superscripts are clipped
Bug 1024804 implemented support for font-variant-position fallback. When 'font-variant-position' is set to 'sub' or 'super' and the font used lacks OpenType subscript/superscript variants, synthetic fallback glyphs are displayed. Steps: open the URL link Result: fallback superscript glyphs are clipped The immediate cause of this is part 6 patch of bug 1024804, which clips text frames to mVisibleRect: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsTextFrame.cpp#4658 I suspect the subscript/superscript fallback code doesn't adjust the mVisibleRect correctly.
Ooops, I meant to say part 6 of bug 1059033.
Simple testcase that displays initially with Helvetica red text and then switches to Arial white text. Result is the screen is left with two lines of red turds.
Revised to switch between Georgia and Arial, so that the problem will display on both Windows/OSX (under Windows Arial is automagically substituted for Helvetica).
Attachment #8572470 - Attachment is obsolete: true
Example failure on Android emulator from bug 1140413. Note how the pile-of-poo glyph displays fine when the line above it overlaps but is clipped when there's no explicit overlap. Reftest analyzer view of this: http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=http://email@example.com/try-android-api-11-debug/try_ubuntu64_vm_armv7_large-debug_test-plain-reftest-8-bm53-tests1-linux64-build108.txt.gz&only_show_unexpected=1 We're still seeing a lot of sporadic failures related to this problem (see bug 1140413). I suspect part of the problem may be the way the bounds are determined for a given line. Synthetic sub/superscripts are drawn by tweaking the baseline position with the draw code: http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxFont.cpp#1999 I'm guessing that there's some bounds value that also needs to be correctly adjusted for this shift. Why this is so non-deterministic is a bit puzzling.
Bas or Jeff, any tips on how to track this down? Note that the attached testcase reproduces the problem on OSX/Windows.
You need to log in before you can comment on or make changes to this bug.