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.
Created attachment 594802 [details] [diff] [review]
patch, ensure we don't ask GDI to do synthetic styles for @font-face src:local() fonts
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.
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?
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?