1761686 - Tofu instead of GitHub icon in hotdogfinba11.github.io/portfolio

Status: RESOLVED INVALID

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

Description

[Emilio Cobos Álvarez [:emilio]]

It's using "Font Awesome 5 Brands" as a font family, but somehow Chromium finds the Glyph and we don't.

WebKit gets another result as well, so this might be a font issue or so.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Attachment: Firefox / WebKit / Chromium

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: (woff file for use in testcase)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (reduced using testcase-reducer add-on)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (further reduced)

Comment 5

[Daniel Holbert [:dholbert]]

Doesn't seem to be a regression, FWIW; I see the same rendering (tofu) in a few old Nightlies that I tested (2021-08-03, 2020-08-03, 2018-08-03, 2015-08-03). Tested using the attached testcase 2.

Comment 6

[Daniel Holbert [:dholbert]]

Alternate/also-interesting STR:
(1) Upload the attached woff2 font (first attachment here) at https://www.tmroyal.com/woff-viewer/
(2) Click "search by unicode name"
(3) Type "f0" into the search box
(4) scroll to the bottom of the list.

ACTUAL RESULTS:
The last 2 glyphs shown are tofu, and so is another one a little ways back (skipping over 3 rendering-just-fine glyphs)

EXPECTED RESULTS:
Those 3 tofu glyphs should maybe be the github logo; at least, that's how they render in Chrome.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: screenshot of comment 6 STR ( woff-viewer ) in Nightly (top) vs Chrome (bottom)

Comment 8

[Jonathan Kew [:jfkthame]]

This is a font error. The cmap in the font resource actually maps only three PUA characters to glyphs:

  <cmap>
    <tableVersion version="0"/>
    <cmap_format_4 platformID="0" platEncID="3" language="0">
      <map code="0xf099" name="twitter"/><!-- ???? -->
      <map code="0xf16d" name="instagram"/><!-- ???? -->
      <map code="0xf2c6" name="telegram"/><!-- ???? -->
    </cmap_format_4>
    <cmap_format_0 platformID="1" platEncID="0" language="0">
    </cmap_format_0>
    <cmap_format_4 platformID="3" platEncID="1" language="0">
      <map code="0xf099" name="twitter"/><!-- ???? -->
      <map code="0xf16d" name="instagram"/><!-- ???? -->
      <map code="0xf2c6" name="telegram"/><!-- ???? -->
    </cmap_format_4>
  </cmap>

Those are the three that show up in Firefox.

So where's that github logo coming from? Well, like any OpenType font, in addition to the three "real" glyphs, it contains a .notdef glyph (with glyph ID 0), as required by the spec:

  <GlyphOrder>
    <!-- The 'id' attribute is only for humans; it is ignored when parsed. -->
    <GlyphID id="0" name=".notdef"/>
    <GlyphID id="1" name="instagram"/>
    <GlyphID id="2" name="telegram"/>
    <GlyphID id="3" name="twitter"/>
  </GlyphOrder>

It turns out the .notdef glyph in this font is actually the github logo! Now, .notdef is what you get for characters that are not supported by the font -- unless the application does something else such as font fallback (which we would do if it wasn't a PUA codepoint, where fallback is inherently meaningless) or implements an alternative rendering of unsupported characters (in our case, as synthetic "hexbox" glyphs).

In Chrome, they don't implement hexboxes, they just blast the text through the requested font, and so any PUA character (except the three that are explicitly mapped) will end up rendering the font's .notdef glyph. You can see this in Chrome with https://www.tmroyal.com/woff-viewer/ if you view this font and "Filter By Unicode Range", and choose the "Private Use Area" range: it'll be filled with github icons.

My guess is this is a result of a font-subsetting process gone bad, or maybe an attempt to be a little too clever about minimizing the font.

Comment 9

[Daniel Holbert [:dholbert]]

So it sounds like the web content (or rather, the font?) is relying on Chrome's particular choice of "character-not-found" fallback behavior, essentially (and getting broken output in Firefox and Safari as a result).

jfkthame, should we close this as INVALID?

Also, would you be willing to report this to FontAwesome (maybe at https://github.com/FortAwesome/Font-Awesome/issues ), to let them know they're doing something iffy by including a .notdef glyph and expecting it to be renderable? I could do so but you can probably express the issue & answer any followup questions better than I could. :)

It looks like this exact WOFF file exists in their up-to-date public github repo, links below:

current tip:
https://github.com/FortAwesome/font-awesome-sass/blob/master/assets/fonts/font-awesome/fa-brands-400.woff2
perma-link:
https://github.com/FortAwesome/font-awesome-sass/blob/da54d68de6492cf173c616a1b3cb2ae660f03c91/assets/fonts/font-awesome/fa-brands-400.woff2

(this^ has the same md5sum as the version hosted on the affected site which I attached here as an attachment, so presumably it's the same file and causes the same interop issue if someone tries to use its .notdef github glyph)

There may not be much we can do about folks who have already downloaded & are using that woff file on their sites, but perhaps it'd be worth getting it fixed upstream to avoid this issue spreading.

Comment 10

[Jonathan Kew [:jfkthame]]

I don't think this is a FontAwesome error. The file at https://github.com/FortAwesome/font-awesome-sass/blob/master/assets/fonts/font-awesome/fa-brands-400.woff2 is 103K, as opposed to the 1.3K file here, and loading it into https://www.tmroyal.com/woff-viewer/ with the Private Use Area view shows that it has lots of other brand icons scattered throughout the PUA. And undefined codepoints show a "proper" .notdef glyph, rather than the github icon, which is available only at U+F09B.

So the problem isn't with the resource provided by FontAwesome, but with the subset used by this page.

I think this individual page author decided to subset the font resource to minimize its size, and got it wrong. It looks like he may be contactable via Twitter or Telegram, so maybe someone could reach out to him to point out this issue. (I'd drop him an email but I don't see such old-fashioned contact info...)

Comment 11

[Emilio Cobos Álvarez [:emilio]]

https://github.com/HotDogfinba11/portfolio/issues/2

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew (:jfkthame) from comment #10)

I don't think this is a FontAwesome error. The file at https://github.com/FortAwesome/font-awesome-sass/blob/master/assets/fonts/font-awesome/fa-brands-400.woff2 is 103K, as opposed to the 1.3K file here

oops, you're right -- sorry! In comment 9, it looks like I inadvertently md5sum'd two different copies of this bug's attached font. Glad you caught that before diving into an upstream bug report. :)