737315 - Fennec not properly showing font awesome

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[JR Conlin [:jrconlin,:jconlin]]

Attachment: nightly screen capture

Trying to display the page:

http://evilonastick.com/hacks/dvr

which uses Font Awesome
http://fortawesome.github.com/Font-Awesome/#examples

Characters are not displaying properly.

Comment 1

[JR Conlin [:jrconlin,:jconlin]]

Attachment: native browser screen capture

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

This looks fine to me using a current nightly and a phone. The screnshot provided looks like the Android stock browser.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #2)
> This looks fine to me using a current nightly and a phone.

Do the symbols/icons on the buttons appear properly? They don't for me, with current Nightly - I just see gray boxes.

I'm guessing this may be related to the font using the old Windows "symbol" encoding hack, where the glyphs are mapped to PUA values in the U+Fxxx block; perhaps the FT2 backend doesn't handle this nicely.

Comment 4

[JR Conlin [:jrconlin,:jconlin]]

kbrosnan: There are two attachments. "Nightly screen capture" is a capture of the Nightly Fennec (note the gray boxes). The other screen capture is provided from the native browser for comparison.

Both are running on a Motorola Xoom running ICS.

jfkthame: Font Awesome works by loading characters into the first 0x94 characters (e.g. the power button (called by the class tag "font-off") is defined in the css as:

 .icon-off:before {
    content: "\f011";
  }

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #4)
>  .icon-off:before {
>     content: "\f011";
>   }

Note that the character code here is U+F011, which is within the Private Use area U+E000..F8FF, not one of the "first 0x94 characters" (of ASCII or Unicode). This is characteristic of "symbol-encoded" fonts from the pre-Unicode Windows world. I'm guessing that this may be the root of the problem, though I haven't tracked down exactly why; provided the font and the character codes in the text or CSS match, it ought to work. Still, it would be better practice to use standard Unicode values.

Comment 6

[Aaron Train [:aaronmt]]

Is this a widespread issue? I havn't seen this anywhere else

Comment 7

[Jonathan Kew [:jfkthame]]

I'd guess it is unlikely to be widespread, as the use of PUA codepoints to access the glyphs in "symbol" fonts is an archaic Windows-ism. I doubt such fonts are widely used as webfonts.

I suspect this might affect other (more appropriate) use cases of the Private Use Area, too - which are still unlikely to be widespread, but they really ought to work for the sake of those who actually need them.

Comment 8

[Jeff Balogh (:jbalogh)]

Attachment: font awesome homepage

Font Awesome does not work for me either.

(In reply to Aaron Train [:aaronmt] from comment #6)
> Is this a widespread issue? I havn't seen this anywhere else

Font Awesome is touted as a plugin for Twitter Bootstrap (http://twitter.github.com/bootstrap/), which is becoming the go-to design template for web developers.

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> Note that the character code here is U+F011, which is within the Private Use
> area U+E000..F8FF, not one of the "first 0x94 characters" (of ASCII or
> Unicode). This is characteristic of "symbol-encoded" fonts from the
> pre-Unicode Windows world. I'm guessing that this may be the root of the
> problem, though I haven't tracked down exactly why; provided the font and
> the character codes in the text or CSS match, it ought to work. Still, it
> would be better practice to use standard Unicode values.

Github's new icons (https://github.com/blog/1106-say-hello-to-octicons) use the same technique, but they seem to be working fine on Fennec (attachment 623310 [details]).

(In reply to Jonathan Kew (:jfkthame) from comment #7)
> I'd guess it is unlikely to be widespread, as the use of PUA codepoints to
> access the glyphs in "symbol" fonts is an archaic Windows-ism. I doubt such
> fonts are widely used as webfonts.

Symbol fonts seem to be a rising trend in the webdev world.

Comment 9

[Jonathan Kew [:jfkthame]]

Hmm. Interesting... so in that case we need to figure out why one example works, but the other doesn't.

Comment 10

[Jonathan Kew [:jfkthame]]

I wonder whether this might be related to bug 754243. There's a possible patch and a tryserver build there, if someone would like to try it and see if there's any improvement.

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kew (:jfkthame) from comment #10)
> I wonder whether this might be related to bug 754243.

It's not, after all. Investigating an alternative possibility....

Comment 12

[Jonathan Kew [:jfkthame]]

It turns out the problem is that Freetype doesn't find a usable family name in the font, and the lack of a family name in the FT_Face record causes us to bail out of instantiating the FT2FontEntry because we want to use it to create a name for our font entry.

I guess the creators of this font decided to omit almost all the normal name table entries as a crude form of "protection", to make it harder to install and use the font as a standalone font file.

Comment 13

[Jonathan Kew [:jfkthame]]

Attachment: patch, provide a dummy string if the FT_Face has no family name

This works around the problem by providing a dummy name string "[Unknown]" instead of bailing out if there's no family name in the font. We can do this because the name of the FT2FontEntry is not essential as an identifier (we find the entry from its family record plus style descriptors).

With this patch, the example DVR controller displays as expected, with all the key symbols present.

(FWIW, I think it's bad practice for font developers to try and "sabotage" fonts like this. In this particular instance we can work around the issue, but that may not always be the case.)

Comment 14

[John Daggett (:jtd)]

> fontName.AppendLiteral("[Unknown]");

Given that FT2FontEntry::CreateFontEntry is used both for platform fonts and downloadable fonts, this doesn't seem like such a hot idea to use the same name for all these fonts.  We already have a util function for creating names on the fly:

http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxFontUtils.cpp#910

Shouldn't OTS be creating a proper name table if only an empty table exists?  That seems like the better solution here.

Comment 15

[Jonathan Kew [:jfkthame]]

(In reply to John Daggett (:jtd) from comment #14)
> > fontName.AppendLiteral("[Unknown]");
> 
> Given that FT2FontEntry::CreateFontEntry is used both for platform fonts and
> downloadable fonts, this doesn't seem like such a hot idea to use the same
> name for all these fonts.

A platform font with an empty family name wouldn't ever be used, as there'd be no way to identify it. The "unknown" name only gets used for the anomalous case of a downloaded font whose family name is empty - not a common scenario.

>  We already have a util function for creating
> names on the fly:
> 
> http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxFontUtils.cpp#910

Yeah, we could synthesize unique names but what's the point? They aren't used for anything here, and don't really help when poking around in the debugger. If anything, I'd suggest to "borrow" the CSS font-family name if the font doesn't have a real family name of its own.

> Shouldn't OTS be creating a proper name table if only an empty table exists?
> That seems like the better solution here.

There is a well-formed name table with several strings in it - it's just that the family name (among others) is an empty (zero-length) string, which Freetype treats as though it were absent (face->family_name is a null pointer, not a pointer to an empty string).

Comment 16

[Jonathan Kew [:jfkthame]]

Attachment: patch v2, use the proxy's name for the FT2 entry when instantiating a downloaded font

This version uses the name from the proxy font entry as the name of the new FT2 font entry for downloadable fonts; for installed fonts, the entry's name is still created from the face's family and style names, as previously.

Comment 17

[John Daggett (:jtd)]

Comment on attachment 626598 [details] [diff] [review]
patch v2, use the proxy's name for the FT2 entry when instantiating a downloaded font

> +        NS_WARNING("installed font has no family name!");
> +        fontName.AppendLiteral("[Unnamed family]");

This is exactly what I want to avoid, I think we should reject 
installed fonts with no name, there's no reason to load them at all.
For downloadable fonts, using the font entry name is fine.

Comment 18

[Jonathan Kew [:jfkthame]]

Attachment: patch v3, use the proxy's name for the FT2 entry when instantiating a downloaded font

Fine, we can just return null there.

Comment 19

[John Daggett (:jtd)]

Comment on attachment 626717 [details] [diff] [review]
patch v3, use the proxy's name for the FT2 entry when instantiating a downloaded font

Part of me also wants to ban any font with the name "awesome" in it...

Comment 20

[Jonathan Kew [:jfkthame]]

That would be an interesting new interpretation of the "awesome bar".

Comment 21

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8d1b746c137b

Comment 22

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8d1b746c137b