Bug 21127 – REGRESSION: CFF format fonts fail to load

• Status: RESOLVED
• Resolution: FIXED
• Component: Text

[John Daggett]

For pages using web fonts via @font-face rules, CFF formatted fonts fail to load (i.e. .otf fonts) under Windows XP.

Traced this a bit in the debugger, within createFontCustomPlatformData (FontCustomPlatformData.cpp) the call to load the font via TTLoadEmbeddedFont fails with return code 0x0103, E_NAMECHANGEFAILED (defined in t2embapi.h).

This is a regression, the page renders correctly with the latest Windows version of Safari, 3.1.2 (525.21).  I'm guessing the difference is that 525.21 was using CoreGraphics to load the font(?).

<rdar://problem/6202962> is about TTLoadEmbeddedFont failing with E_NAMECHANGEFAILED.

[Alexey Proskuryakov]

(In reply to comment #1)
> <rdar://problem/6202962> is about TTLoadEmbeddedFont failing with
> E_NAMECHANGEFAILED.

That was fixed in <http://trac.webkit.org/changeset/37042>.

(In reply to comment #2)
> (In reply to comment #1)
> > <rdar://problem/6202962> is about TTLoadEmbeddedFont failing with
> > E_NAMECHANGEFAILED.
> 
> That was fixed in <http://trac.webkit.org/changeset/37042>.
> 

Yup. Now loading the fonts in this bug fails with different error codes.

[John Daggett]

From Simon Daniels, Microsoft:

> Do you know if the font embedding API's under Windows support CFF
> OpenType fonts?

Yes we consider this a bug in t2embed.dll - historically (pre-OpenType)
it rejected fonts without a glyf table. The fix is easy, but was not
fixed in Vista due to concerns over the number of machines without CFF
rasterizers.

[Note: Windows 7 bug 257987]

[Dave Hyatt]

We could fall back to the CoreGraphics rendering path...

[Dave Hyatt]

... if t2embed fails I mean ....

(In reply to comment #5)
> We could fall back to the CoreGraphics rendering path...

An HFONT is required for the complex script code path regardless of the rendering mode.

<rdar://problem/6259134>

Created attachment 23962 [details]
If TTLoadEmbeddedFont fails, use AddFontMemResourceEx after changing the font name in memory

[Dave Hyatt]

Comment on attachment 23962 [details]
If TTLoadEmbeddedFont fails, use AddFontMemResourceEx after changing the font name in memory

r=me

Fixed in <http://trac.webkit.org/changeset/37139>.

[John Daggett]

Um, don't you need some buffer length checks in renameAndActivateFont, given that the input data could be intentionally malformed font data?

(In reply to comment #12)
> Um, don't you need some buffer length checks in renameAndActivateFont, given
> that the input data could be intentionally malformed font data?

I think I do not, given that data is passed to renameAndActivateFont only if getEOTHeader succeeds with the same data. If there is a deficiency in the code, please file a new bug, as the patch has landed and this bug is resolved.