724231 - applying synthetic styles to a GDI font entry may result in garbage text (incorrect glyphs rendered)

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Jonathan Kew [:jfkthame]]

Attachment: testcase for synthetic styling

The GDI font back-end can end up rendering completely incorrect glyphs in certain cases. The problem arises when GDIFont is asked to apply a "synthetic" style (bold or italic) that is not inherent in the font-entry being used. In this situation, our shaping code assumes it is using the font face referenced by the font-entry; but when GDI creates the HFONT resource from the LogFont we set up, it may end up using a true styled face rather than applying synthetic styling to the face we thought we were using.

This isn't _usually_ a problem, because in most cases the character inventory, glyph IDs, etc., match across faces within a family. However, this does not always hold true, and when there's a mismatch, the result is garbage - glyph IDs of the regular face rendered using the italic face, for example, leading to incorrect or even undefined glyphs.

The easiest way to demonstrate the problem is to use @font-face src:local to identify a specific face, and then use CSS properties to try and apply synthetic styling to it. Under DWrite, we correctly use the specified face and apply our own synthetic styling, but the GDI back-end implements the styling by setting fields in the LogFont before creating its HFONT, and this means GDI will step in and substitute a styled font resource if it sees fit.

Testcase attached, demonstrating the problem with Times New Roman and with Cambria. The line of text should be the same in all cases, but when synthetic styling is applied to the @font-face text, we get junk glyphs.

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: patch, ensure we don't ask GDI to do synthetic styles for @font-face src:local() fonts

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: reftest to check that synthetic styles applied to src:local face do NOT result in a different face being used

This tests that applying font-style:italic to a family defined with a single, regular face using src:local does NOT result in using a true italic face from the same (platform) family, which would be a spec violation (as the font family defined using @font-face has no relation to "native" font families as understood by the platform), and can lead to incorrect glyphs.

Test assumes that one of various standard font families will be available; it passes tryserver on all our current platforms (once the patch here is applied - without, it fails under GDI), but may need to be enhanced for future platforms with different font collections.

Comment 3

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b343b7314918 (patch)
https://hg.mozilla.org/integration/mozilla-inbound/rev/d32d00967753 (reftest)

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/b343b7314918
https://hg.mozilla.org/mozilla-central/rev/d32d00967753

Comment 5

[Ekanan Ketunuti]

Attachment: example for comment 5

Hi, Jonathan Kew

I don't know what this bug does. after this bug landed on m-c. I see that an italic font rendering too ugly. see the attachment for example.

Is this a bug or intentional?

Comment 6

[Jonathan Kew [:jfkthame]]

That's really strange - it looks like the antialiasing is completely wrong (incorrect subpixel order?). Please file a new bug for this (and cc me on the report); it's not immediately clear how it would be connected to the original issue here.

Some details that would be helpful in a new report: Could you please confirm what system you're using (XP? Win7? ...?), as well as the exact versions you tested (last "good" build, first "bad" build).

Do you see this for *all* italic fonts, or does it happen only with certain fonts or on certain pages? Does a minimal example such as

  data:text/html,<div style="font: 24px Arial">regular and <i>italic text</i></div>

show the same problem?