513719 - [@font-face] ttf fonts with large name table records don't load on windows

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, defect)

Description

[Nick Nguyen [:osunick]]

I'm using a downloadable truetype file on my blog- http://www.osunick.com, using font-face to point to Pigiarniq, a free truetype font.  On OS X, the font loads and renders properly, but it doesn't appear at all on Windows.  

Here's my @font-face rule:

@font-face {
  font-family: "Pigiarniq";
  src: url("/fonts/Pigiarniq.ttf") format("truetype");
}

and here's my body class:

body { font-family: "Pigiarniq", Verdana, Helvetica, Arial, sans-serif; font-size: 90%; line-height: 120%; color: #404040; background: #fff; }

Comment 1

[Jonathan Kew [:jfkthame]]

It's a Microsoft issue, really, though I guess we should hack around it. The license field in that font is over 5000 characters, which causes the Windows t2embed library to reject it.

John, are you intending to put together a workaround for this?

Comment 2

[John Daggett (:jtd)]

Yes, it looks like MS is pushing this update to Vista/XP.  Attached is a testcase with the original font and a version with name tables removed.

Nick, could you confirm the behavior on Vista?  The last line, displayed with the modified font, should display correctly.

This appears to be the motivation behind the fix:
http://www.microsoft.com/technet/security/Bulletin/MS09-029.mspx

I need to figure out more about the specifics to make sure we work around this correctly.

Comment 3

[John Daggett (:jtd)]

I'm seeing really odd behavior here, after updating to get the latest security updates for XP, Vista and Windows 7, Vista doesn't load the corrected font (i.e. the one without the long name fields) but XP and Win7 do.

Comment 4

[John Daggett (:jtd)]

Changing the URL because the Pigiarniq font license does not appear to allow @font-face usage.  It's a font that can be freely downloaded but the terms to not allow "redistribution" so unless someone has explicit permission from the owners, this should not be used as a web font.

The regular face of Pigiarniq can be fixed by adjusting the name table records to be less than 2500 characters (use ttx).  The PigiarniqBold face does not load even with this corrected, there's something else involved.

The testcase uses edited versions of Gentium.

Comment 5

[John Daggett (:jtd)]

Note: with the KB 961371 fix that Microsoft pushed out mid-July, fonts with name table records >5000 bytes don't load.

Comment 7

[Jonathan Kew [:jfkthame]]

Hmm, do we have a fix for this on trunk already? On Vista, the Gentium-based test page shows the expected failures with 3.5.2, but all the lines display correctly (even the unmodified Gentium) with latest Minefield nightly.

Comment 8

[John Daggett (:jtd)]

As part of the fix for funky fullname/family name mismatches, I changed the Windows font loading logic for ttf fonts to be "load with t2embed but if an error occurs use the AddFontMemResourceEx path".  This means lots of extra work and a full font copy (ick!) but the Gentium testcases will always succeed with this logic.  Probably a good idea to experiment with simply always throwing away the name table and using the AddFontMemResourceEx path.

Comment 9

[Jonathan Kew [:jfkthame]]

But will Uniscribe shape fonts that are loaded through AddFontMemResourceEx? I thought that was why we're not simply using that for everything, rather than messing around with EOT headers and such. If so, we really want to fix up the name table and use t2embed instead of falling back to AFMREx.

Comment 10

[John Daggett (:jtd)]

I posted some screenshots that show loading behavior on WinXP / Windows7 using only AddFontMemResourceEx loading (i.e. no use of the t2embed library) on bug 510440.  Uniscribe only refuses to shape AddFontMemResourceEx-loaded fonts on WinXP for CFF fonts, all other combinations function correctly, TTF on WinXP/Win7 and CFF on Win7.  So dumping the use of t2embed is definitely an option here.

The t2embed library does have a streaming routine that allows us to tweak font data without recopying the entire font and the API call explicitly allows for font renaming.  But I have a feeling internally it's just copying the data around and passing it down to AddFontMemResourceEx, this is something I need to confirm.  If this is the case we're not really saving a copy because it's just going to happen internally within t2embed, we might as well manage the font mangling ourselves.  I'll do some timing tests to see if there are any perf gains or losses to trimming out the use of t2embed.  It would certainly be nicer to have a simpler codepath for Windows.