523717 - incorrect layout after downloadable font with smaller underline offset loads

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[David Baron :dbaron:]

Attachment: patch

I was trying to reproduce the problem in bug 522223 on Linux, but I couldn't.  However, while doing this, I noticed (bug 522223 comment 17) that the layout was incorrect after the user font loaded, since it changed after I did a zoom-in and then zoom-out.

This is because we're not clearing the cached underline offset.

The attached patch fixes the problem for me on Linux; I haven't yet written an automated test, since that's hard (for me anyway...I'd need to re-remember how to do font generation and generate test fonts with different underline offsets), though I might try later.

Presumably the Core Text backend needs the same fix.

I'd note that the clearing of mUnderlineOffset *was* added for Windows in http://hg.mozilla.org/mozilla-central/rev/28eea1633fe1 (inside InitFontList) and Mac ATSUI in http://hg.mozilla.org/mozilla-central/rev/c84b63d503df .

(Should we move the Windows one out of InitFontList to be consistent with the other platforms?)

Comment 1

[David Baron :dbaron:]

Attachment: patch

Here's a patch with a test that fails prior to the patch (it's the final != test that fails, actually).

Tomorrow I'll try to remember to figure out if the font I finally generated that made this work actually has a low underline or a high one.

Comment 2

[David Baron :dbaron:]

Attachment: patch

Yeah, the font that actually caused a failure without the patch is one with a higher underline offset, not lower.

Comment 3

[John Daggett (:jtd)]

Comment on attachment 407940 [details] [diff] [review]
patch

Looks good.

Comment 4

[David Baron :dbaron:]

http://hg.mozilla.org/mozilla-central/rev/b06d6479f8a4

Comment 5

[David Baron :dbaron:]

And I filed bug 534132 on generating the test font better so it works on Windows and Mac as well; I gave up trying after some fighting with it.