508959 - [@font-face] font without version fails to load

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[John Daggett (:jtd)]

The testcase URL uses Chunk Five, a font which lacks a version field in the name table.  Our TTF font loading code on Windows tosses out fonts like this, it should just use a null string instead.

Expected result: testcase should show Chunk Five font, not Tahoma or a sans-serif font.

This only affects Windows.

Comment 1

[John Daggett (:jtd)]

Attachment: patch, v.0.2, allow null string names

Remove the requirement to have all names.  Any name that doesn't exist in the font will have a null string in the EOT header.

Reftest included.

Comment 2

[Jonathan Kew [:jfkthame]]

Does windows load fonts successfully if all the names are null? I wouldn't be surprised if the family name, at least, is required. But I haven't tested this; have you?

Comment 3

[John Daggett (:jtd)]

Attachment: patch, v.0.3, add more complete reftests

Additional reftest that tests fonts with various names missing.  No names are required except for the postscript name under Mac OS X(!), even though the name isn't used (I also tested for that using a src local testcase).  The missingnames-all.html isn't referenced in reftest.list but I included it for completeness.

http://people.mozilla.org/~jdaggett/font-face/missingnames-all.html

Note that this means that directly linked fonts can be obfuscated on all platforms by simply removing all name records except for copyright, license and postscript names.

Hmmm, Safari doesn't seem to require a postscript name, need to test that a bit.

Comment 4

[John Daggett (:jtd)]

Doh, forgot our Mac code does a sanity check on font loads, it looks up the postscript name.  Will revise patch to do a different sanity check when no psname present.

Comment 5

[John Daggett (:jtd)]

Attachment: patch, v.0.4, allow fonts without postscript names to load on Mac OS X

Detect fonts that lack Postscript names.  For these fonts, only fail if a ATSGetTable call fails for the 'head' table, since a 'head' table is required for all fonts on the Mac.

With this change, fonts with empty name tables will load on all platforms.

Comment 6

[Jonathan Kew [:jfkthame]]

I'm a bit nervous of allowing fonts with no PS name - this seems like a potential issue waiting to bite us in the future, even if they work today. For example, does OS X handle *multiple* such fonts simultaneously without getting confused? I believe Quartz and Cocoa use the PS name as a primary identifier to the font, so unless they're checking for this and synthesizing a unique name internally, it could lead to confusion. And what happens if someone tries to print to a PS printer with such a font?

(Guessing an answer: it probably depends on the driver, but in principle, the expected behavior is undefined. The MS spec says "If no name ID 6 is present, then there is no defined method for invoking this font on a PostScript interpreter"; the Apple version of the spec just says "The PostScript name is used by the LaserWriter print driver".)

So I'm wondering, is it really a good idea to remove this check? Or would it be wiser to retain this as one of our basic sanity-checks for the well-formedness of a font rather than let them through and take our chances on what the rest of the system will do?

Comment 7

[John Daggett (:jtd)]

(In reply to comment #6)

I don't think ATS is relying on PS names internally, that's what the unique id's that end up as ATSFontRef's are for.  Nor should it, since that would lead to all sorts of conflicts between documents containing embedded fonts with the same PS name.  ATS does use PS names as the preferred way of looking up a font when the unique key isn't known but that's not really an issue for privately loaded fonts like these.  The reference in the spec to the LaserWriter driver is noting that the PS name is used to look up fonts *resident* on the LaserWriter, but again that's not something that's really relevant anymore.

Requiring PS names does cause interoperability problems with Safari, which will load the fonts without PS names just fine.  It would also make the Mac loading code different from Windows/Linux which don't require it.  Unless there's a real problem related to this, I don't think it makes sense to exclude fonts without PS names.

Comment 8

[John Daggett (:jtd)]

You can view the reftest missingnames.html here:

http://people.mozilla.org/~jdaggett/font-face/missingnames.html

Note that the fonts used for both the "no postscript" and "copyright only" cases lack PS names.

Comment 9

[Jonathan Kew [:jfkthame]]

Comment on attachment 394778 [details] [diff] [review]
patch, v.0.4, allow fonts without postscript names to load on Mac OS X

Ok, I'm still a bit nervous of fonts without PS names when it comes to printing through a PS driver, but we can deal with that as a printing bug if it proves to be a real issue anywhere. (Testing with Safari, it looks like the Apple driver on OS X handles this ok by using a string of digits - maybe the ATSFontRef - in the PS /FontName when name ID 6 is missing. But who knows what other drivers may do...)

Maybe FontLoadedCorrectly() should also check that the returned dataLength value is >= 54 (otherwise it cannot be a valid 'head' table). It's highly unlikely we'd ever see such an error, but having retrieved the table length it seems a shame not to check it.

For testing purposes, maybe you could disable the PSname check altogether and rely only on FontLoadedCorrectly(), and check whether this does seem to detect failed ATS activation in a similar way? Marking r+ on the understanding you will confirm this in some local bad-font-cache testing. (I don't see how we can do a reliable automated test for this... or at least, the ideas I can think of are out of all proportion to the importance.)

Comment 10

[Bas Schouten (:bas.schouten)]

John, what's the status on this?

Comment 11

[RNicoletto]

Testcase URL is WFM (Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1)