1943858 - Warning about a broken font that doesn't seem to be broken

Status: RESOLVED INVALID

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

Description

[Yves Goergen [:ygoe]]

Attachment: muli.woff2

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

I use the attached font on my website. It has worked fine in the past but when I checked back now, there's a warning in the browser console for each style of the font.

Actual results:

downloadable font: glyf: empty gid 122 used as component in glyph 258 (font-family: "Muli" style:normal weight:400 stretch:100 src index:0) source: .../fonts/muli.woff2

Expected results:

I don't know what that means but the font is fine. All characters can be seen properly. So I suspect the warning is wrong. I tried to inspect the font with FontForge but can't make sense of the numbers mentioned in the message. Glyph 122 is z and glyph 258 is Ă. Nothing empty here. FontForge also can't see any problems like this in its pre-save verification.

There's a separate warning for each style which now adds 10 warnings in the console that I have to ignore when looking for my own log output and warnings I need to care about. That's very annoying.

There is no warning at all in Chrome so that's the better development option for now. ☹️

The font can be downloaded here: https://www.fontsquirrel.com/fonts/muli

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to Yves Goergen [:ygoe] from comment #0)

downloadable font: glyf: empty gid 122 used as component in glyph 258 (font-family: "Muli" style:normal weight:400 stretch:100 src index:0) source: .../fonts/muli.woff2

Expected results:

I don't know what that means but the font is fine. All characters can be seen properly. So I suspect the warning is wrong. I tried to inspect the font with FontForge but can't make sense of the numbers mentioned in the message. Glyph 122 is z and glyph 258 is Ă. Nothing empty here. FontForge also can't see any problems like this in its pre-save verification.

No, character 122 is z, but glyph 122 is "periodcentered", and glyph 258 is "Ldot" or Ŀ (not Ă). And if we check the definition of "Ldot", we find that it is indeed defined using "periodcentered" as a component:

    <TTGlyph name="Ldot" xMin="202" yMin="0" xMax="1070" yMax="1456">
      <component glyphName="periodcentered" x="301" y="126" flags="0x1004"/>
      <component glyphName="L" x="0" y="0" flags="0x1004"/>
      <instructions>
        <assembly>
          PUSHB[ ]	/* 2 values pushed */
          0 1
          PUSHB[ ]	/* 1 value pushed */
          126
          PUSHB[ ]	/* 1 value pushed */
          48
          CALL[ ]	/* CallFunction */
        </assembly>
      </instructions>
    </TTGlyph>

and when we look at "periodcentered", it is indeed empty:

    <TTGlyph name="periodcentered"/><!-- contains no outline data -->

(glyph data from a TTX dump of the font).

And if you try to display the character Ŀ with that font, you'll see that it is indeed lacking its dot. (Similarly, the lowercase ŀ and the standalone · character won't render properly.)

So this does indicate a fault in the font (even though it may not be affecting the particular characters you're using).

As for why we issue the warning, see bug 1923596: such glyphs may not just look wrong but fail to render entirely on at least some versions of Windows.

In summary: the warning is correct, and reflects a real flaw in the font.

Comment 3

[Yves Goergen [:ygoe]]

Oh, thanks, so I cannot inspect those errors without more special tools it seems. FontForge is the only thing I can operate halfway but I'm not a font technology expert.

Also, the original .ttf file I downloaded was fine, the dot was there in all places. So it's FontSquirrel's webfont converter that introduced the error. I could see the problem when opening the .woff2 file in FontForge. But FF can write .woff2 files directly, so I converted each file manually and now all warnings are gone in Firefox. Luckily, the font still looks the same, so I don't need any of FontSquirrel's converter features.

Comment 4

[Jonathan Kew [:jfkthame]]

So it's FontSquirrel's webfont converter that introduced the error.

That's interesting -- you might want to consider reporting the issue to them. I'd guess FS may be doing some sort of "subsetting" of the font to eliminate "unneeded" glyphs, but is getting the interdependencies wrong.

Anyhow, glad to know you're able to avoid the problem now.

Comment 5

[Yves Goergen [:ygoe]]

I've already sent them a message about it and linked to this bug for more details.

I disabled all subsetting in their converter so that shouldn't be an issue.