Last Comment Bug 724231 - applying synthetic styles to a GDI font entry may result in garbage text (incorrect glyphs rendered)
: applying synthetic styles to a GDI font entry may result in garbage text (inc...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: unspecified
: x86_64 Windows 7
: -- normal (vote)
: mozilla13
Assigned To: Jonathan Kew (:jfkthame)
:
Mentors:
Depends on: 754452 764805
Blocks: 668813
  Show dependency treegraph
 
Reported: 2012-02-04 03:49 PST by Jonathan Kew (:jfkthame)
Modified: 2012-07-03 08:08 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase for synthetic styling (3.12 KB, text/html)
2012-02-04 03:49 PST, Jonathan Kew (:jfkthame)
no flags Details
patch, ensure we don't ask GDI to do synthetic styles for @font-face src:local() fonts (8.51 KB, patch)
2012-02-06 14:05 PST, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
Details | Diff | Review
reftest to check that synthetic styles applied to src:local face do NOT result in a different face being used (3.74 KB, patch)
2012-02-06 14:09 PST, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
Details | Diff | Review
example for comment 5 (82.96 KB, image/png)
2012-02-16 19:42 PST, Ekanan Ketunuti
no flags Details

Description Jonathan Kew (:jfkthame) 2012-02-04 03:49:55 PST
Created attachment 594419 [details]
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) 2012-02-06 14:05:23 PST
Created attachment 594802 [details] [diff] [review]
patch, ensure we don't ask GDI to do synthetic styles for @font-face src:local() fonts
Comment 2 Jonathan Kew (:jfkthame) 2012-02-06 14:09:42 PST
Created attachment 594803 [details] [diff] [review]
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 5 Ekanan Ketunuti 2012-02-16 19:42:47 PST
Created attachment 598108 [details]
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) 2012-02-17 00:02:40 PST
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?

Note You need to log in before you can comment on or make changes to this bug.