Bug 21127 - REGRESSION: CFF format fonts fail to load
: REGRESSION: CFF format fonts fail to load
Status: RESOLVED FIXED
: WebKit
Text
: 528+ (Nightly build)
: PC Windows XP
: P1 Major
Assigned To:
: http://opentype.info/demo/webfontdemo...
: InRadar
:
:
  Show dependency treegraph
 
Reported: 2008-09-25 18:49 PST by
Modified: 2008-10-02 01:52 PST (History)


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


Note

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


Description From 2008-09-25 18:49:02 PST
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 From 2008-09-26 14:36:05 PST -------
<rdar://problem/6202962> is about TTLoadEmbeddedFont failing with E_NAMECHANGEFAILED.
------- Comment #2 From 2008-09-28 15:29:46 PST -------
(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 From 2008-09-28 15:31:31 PST -------
(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 From 2008-09-28 16:42:57 PST -------
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 From 2008-09-28 19:43:31 PST -------
We could fall back to the CoreGraphics rendering path...
------- Comment #6 From 2008-09-28 19:44:10 PST -------
... if t2embed fails I mean ....
------- Comment #7 From 2008-09-28 19:48:02 PST -------
(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 From 2008-09-30 16:16:58 PST -------
<rdar://problem/6259134>
------- Comment #9 From 2008-09-30 16:39:22 PST -------
Created an attachment (id=23962) [details]
If TTLoadEmbeddedFont fails, use AddFontMemResourceEx after changing the font name in memory
------- Comment #10 From 2008-09-30 23:17:45 PST -------
(From update of attachment 23962 [details])
r=me
------- Comment #11 From 2008-09-30 23:25:49 PST -------
Fixed in <http://trac.webkit.org/changeset/37139>.
------- Comment #12 From 2008-10-02 01:38:09 PST -------
Um, don't you need some buffer length checks in renameAndActivateFont, given that the input data could be intentionally malformed font data?
------- Comment #13 From 2008-10-02 01:52:33 PST -------
(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.