Closed Bug 737315 Opened 10 years ago Closed 10 years ago

Fennec not properly showing font awesome

Categories

(Core :: Graphics: Text, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla15

People

(Reporter: jrconlin, Assigned: jfkthame)

Details

Attachments

(4 files, 2 obsolete files)

Attached image 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.
This looks fine to me using a current nightly and a phone. The screnshot provided looks like the Android stock browser.
OS: Windows 7 → Android
Hardware: x86_64 → ARM
(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.
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";
  }
(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.
Is this a widespread issue? I havn't seen this anywhere else
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.
Attached image 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.
Hmm. Interesting... so in that case we need to figure out why one example works, but the other doesn't.
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.
(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....
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.
Version: Firefox 11 → Trunk
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.)
Assignee: nobody → jfkthame
Attachment #626003 - Flags: review?(jdaggett)
> 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.
(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).
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.
Attachment #626003 - Attachment is obsolete: true
Attachment #626003 - Flags: review?(jdaggett)
Attachment #626598 - Flags: review?(jdaggett)
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.
Attachment #626598 - Flags: review?(jdaggett) → review-
Fine, we can just return null there.
Attachment #626598 - Attachment is obsolete: true
Attachment #626717 - Flags: review?(jdaggett)
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...
Attachment #626717 - Flags: review?(jdaggett) → review+
That would be an interesting new interpretation of the "awesome bar".
https://hg.mozilla.org/integration/mozilla-inbound/rev/8d1b746c137b
Component: General → Graphics: Text
Product: Fennec Native → Core
QA Contact: general → graphics-text
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/8d1b746c137b
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.