Summary: | REGRESSION: CFF format fonts fail to load | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | John Daggett <jdaggett> | ||||
Component: | Text | Assignee: | mitz | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Major | CC: | mitz, phiw2 | ||||
Priority: | P1 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
URL: | http://opentype.info/demo/webfontdemo.html | ||||||
Attachments: |
|
Description
John Daggett
2008-09-25 18:49:02 PDT
<rdar://problem/6202962> is about TTLoadEmbeddedFont failing with E_NAMECHANGEFAILED. (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. 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] We could fall back to the CoreGraphics rendering path... ... 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. Created attachment 23962 [details]
If TTLoadEmbeddedFont fails, use AddFontMemResourceEx after changing the font name in memory
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>. 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. |