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.
(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.
<rdar://problem/6259134>
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.