496573 - [@font-face] fonts whose fullname don't begin with the family name don't load under Windows

Status: RESOLVED FIXED

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

Description

[Steven Garrity [:sgarrity]]

Attachment: test case trying to use @font-face

Trying to use a true-type font via @font-face and it works on Linux and Mac, but not windows. Test case attached and also here:

http://labs.silverorange.com/files/mozilla/font-face/test.html

Comment 1

[Steven Garrity [:sgarrity]]

Attachment: The font in question

Oh, and this is in the latest Shiretoko nightly (as of June 5, 2009)

Comment 2

[Christopher Blizzard (:blizzard)]

Note that we're trying to use this font on our first run page.  Not sure if it's blocking, might just be something about the font.

Comment 3

[Christopher Blizzard (:blizzard)]

Jim Mathies did some testing on irc and he says "windows says it's not a valid font file",

Comment 4

[Jim Mathies [:jimm]]

This is failing in the windows embedded font loading library on the call TTLoadEmbeddedFont  w/ E_NAMECHANGEFAILED. We supply a unique font name to szWinFamilyName, but we supply null to szMacFamilyName which according msdn needs to be populated. cc'ing John for comment.
 
MSDN on TTLoadEmbeddedFont:

http://msdn.microsoft.com/en-us/library/dd145155%28VS.85%29.aspx

Comment 5

[Christopher Blizzard (:blizzard)]

Putting on the 1.9.1 radar.  Might affect one of our major features for 3.5.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Jim: do we know why it happens with this font specifically but not others? Is it the case that when Windows says something's an invalid font we fail, but in all other cases we win?

There's a bunch of other examples that work fine on Windows, like:

http://www.princexml.com/howcome/2008/webfonts/inel.html

Comment 7

[John Daggett (:jtd)]

Attachment: testcase font, full name revised

The root cause seems to be the way the names are organized in the name table of this font.  For the testcase font, the full font name is "Jaws Comic Pro JY", even though the family name is "Laffayette Comic Pro".  Full names are usually in the form family + style (e.g. Tahoma Bold). 

Changing the "Jaws Comic Pro JY" to "Laffayette Comic Pro" in the name record below fixes the problem:

<namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
  Laffayette Comic Pro
</namerecord>

[Note: used ttx to rebuild the font, http://sourceforge.net/projects/fonttools/]

Looks like Webkit already has code to work around this problem:

http://trac.webkit.org/browser/trunk/WebCore/platform/graphics/opentype/OpenTypeUtilities.cpp#L328

Man, Windows voodoo, argh.  I'll put together a patch for this in the next couple days.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Don't think I'd block on this, based on the diagnosis in comment 7, but of course we'd take a patch for 3.5 if it's reviewed and put up for approval (it has my pre-approval to land on mozilla-central once reviewed in order to bake). 

John: we should probably add this broken font as a testcase, too!

Steven: we should use the repaired font, for now, on our webpage ;)

Nice work, everyone.

Comment 9

[Steven Garrity [:sgarrity]]

The rebuilt version of the font seems to have killed the bold variant. Windows XP now shows only non-bold, and Mac OS X seems to only show bold.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Do you have a URL for the testcase that uses both bold and non-bold variants?

Comment 11

[Steven Garrity [:sgarrity]]

(In reply to comment #10)
> Do you have a URL for the testcase that uses both bold and non-bold variants?

Yeah - though I was partially mistaken. The OS X bold/non-bold is working fine (there was a typo in my code). However, it appears that Windows still doesn't show bold:

http://labs.silverorange.com/files/mozilla/font-face/re-built/test.html

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That test only links to a single font file, which is the non-bold version.  Maybe we're doing synthetic bold on Mac and Linux or something like that?  (I see bold on Linux with your testcase, too.)

If you wanted to use normal and bold weights of a font, I'd expect the style sheet to look more like:

@font-face {
	font-family: Laffayette;
	src: url('Laffayette_Comic_Pro.ttf');
}

@font-face {
	font-family: Laffayette;
        font-weight: bold;
	src: url('Laffayette_Comic_Pro_Bold.ttf');
}

(and likewise for italic, if you wanted that)

Comment 13

[Steven Garrity [:sgarrity]]

David, you're right - the font is only one style. Any idea why we might be doing synthetic bold on some platforms but not Windows? Is that the intended behaviour?

Comment 14

[John Daggett (:jtd)]

(In reply to comment #13)
> David, you're right - the font is only one style. Any idea why we might be
> doing synthetic bold on some platforms but not Windows? Is that the intended
> behaviour?

Argh, looks like synthetic bolding is busted on Windows, logged as bug 499621.

Comment 15

[John Daggett (:jtd)]

Attachment: patch, v.0.2, fallback to memory loading font api when t2embed api fails

This patch adjusts the fullname when the first portion of it differs from the family name and it falls back to the memory loading API when the t2embed API call fails.  For the original testcase, this fixes the problem (the original testcase fullname is shorter than the family name so it's the fallback that makes it work).

Need to do some more testing and cleanup.

Comment 17

[John Daggett (:jtd)]

Attachment: patch, clean up with reftest

This patch covers the two possible failures caused by family/fullname mismatch.  If the fullname is longer but the initial portion doesn't match the family name, set the fullname to contain the beginning of the family name via an overlay when streaming in the font data.  If a load fails using the t2embed API, try again via the font memory loader.  

Reftest uses two fonts tweaked to have fullnames in the two possible forms.

Comment 18

[John Daggett (:jtd)]

Also verified two testcases from bug 501902:

http://keryx.se/resources/firefox-experiments/trace-font-in.html
http://devfiles.myopera.com/articles/593/webfonts_in_svg.svg

Note: the SVG font not showing is not this bug.

Comment 19

[John Daggett (:jtd)]

Checked in on trunk
http://hg.mozilla.org/mozilla-central/rev/af66c8da4412

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 388038 [details] [diff] [review]
patch, clean up with reftest

>+        if (PRUint64(nameOffset) + PRUint64(nameStringsBase) + PRUint64(nameoff) 
>+            + PRUint64(namelen) > dataLength) {
>             return NS_ERROR_FAILURE;
>+        }
>     
>-        strOffset = nameOffset + PRUint32(nameHeader->stringOffset) + nameoff + namelen;
>+        strOffset = nameOffset + nameStringsBase + nameoff + namelen;

Do we need to worry about integer overflow in the strOffset calculation? If not then why all the PRUint64 casting a few lines above?

Comment 21

[John Daggett (:jtd)]

Funky offsets in name tables has been historically been a source of crashing errors in platform font API's.  This is just an attempt to avoid fonts with these sorts of problems.

Comment 22

[Daniel Veditz [:dveditz]]

Comment on attachment 388038 [details] [diff] [review]
patch, clean up with reftest

> Do we need to worry about integer overflow in the strOffset calculation?

No, we just vetted it, it's fine.

Approved for 1.9.1.4, a=dveditz for release-drivers

Comment 23

[John Daggett (:jtd)]

Pushed to 1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/82af716445d6

Comment 24

[Matteo Gazzoni]

Attachment: Font not loaded

Comment 25

[Matteo Gazzoni]

After the update to Firefox 3.5.4 the font attached doesn't work anymore.
@font-face {
font-family: Prototype;
src: url('Prototype.ttf');
}

Comment 26

[Jonathan Kew [:jfkthame]]

(In reply to comment #25)
> After the update to Firefox 3.5.4 the font attached doesn't work anymore.
> @font-face {
> font-family: Prototype;
> src: url('Prototype.ttf');
> }

The 'cmap' table in this font has an error (a spurious duplicate "sentinel" entry at the end of the format 4 subtable), and our validation code rejects it because of this. However, we may be able to relax the criteria so as to allow it to be used. See bug 534352.