Bug 21127 - REGRESSION: CFF format fonts fail to load
Summary: REGRESSION: CFF format fonts fail to load
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P1 Major
Assignee: mitz
URL: http://opentype.info/demo/webfontdemo...
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2008-09-25 18:49 PDT by John Daggett
Modified: 2008-10-02 01:52 PDT (History)
2 users (show)

See Also:


Attachments
If TTLoadEmbeddedFont fails, use AddFontMemResourceEx after changing the font name in memory (11.41 KB, patch)
2008-09-30 16:39 PDT, mitz
hyatt: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Daggett 2008-09-25 18:49:02 PDT
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(?).
Comment 1 mitz 2008-09-26 14:36:05 PDT
<rdar://problem/6202962> is about TTLoadEmbeddedFont failing with E_NAMECHANGEFAILED.
Comment 2 Alexey Proskuryakov 2008-09-28 15:29:46 PDT
(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>.
Comment 3 mitz 2008-09-28 15:31:31 PDT
(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.
Comment 4 John Daggett 2008-09-28 16:42:57 PDT
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]

Comment 5 Dave Hyatt 2008-09-28 19:43:31 PDT
We could fall back to the CoreGraphics rendering path...

Comment 6 Dave Hyatt 2008-09-28 19:44:10 PDT
... if t2embed fails I mean ....

Comment 7 mitz 2008-09-28 19:48:02 PDT
(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.
Comment 8 mitz 2008-09-30 16:16:58 PDT
<rdar://problem/6259134>
Comment 9 mitz 2008-09-30 16:39:22 PDT
Created attachment 23962 [details]
If TTLoadEmbeddedFont fails, use AddFontMemResourceEx after changing the font name in memory
Comment 10 Dave Hyatt 2008-09-30 23:17:45 PDT
Comment on attachment 23962 [details]
If TTLoadEmbeddedFont fails, use AddFontMemResourceEx after changing the font name in memory

r=me
Comment 11 mitz 2008-09-30 23:25:49 PDT
Fixed in <http://trac.webkit.org/changeset/37139>.
Comment 12 John Daggett 2008-10-02 01:38:09 PDT
Um, don't you need some buffer length checks in renameAndActivateFont, given that the input data could be intentionally malformed font data?
Comment 13 mitz 2008-10-02 01:52:33 PDT
(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.