ateliertriay/bricolage

Differing named instances share the same name IDs

Closed this issue · 10 comments

jfkthame commented

Examining the fvar table in a TTX dump, there appear to be a lot of named-instance records, with multiple instances referencing the same PostScript names. This can cause confusion for code that's trying to manage font styles and variation settings.

First, let's see what the defined axes are:

    <!-- Optical size -->
    <Axis>
      <AxisTag>opsz</AxisTag>
      <Flags>0x0</Flags>
      <MinValue>12.0</MinValue>
      <DefaultValue>96.0</DefaultValue>
      <MaxValue>96.0</MaxValue>
      <AxisNameID>256</AxisNameID>
    </Axis>

    <!-- Weight -->
    <Axis>
      <AxisTag>wght</AxisTag>
      <Flags>0x0</Flags>
      <MinValue>200.0</MinValue>
      <DefaultValue>800.0</DefaultValue>
      <MaxValue>800.0</MaxValue>
      <AxisNameID>257</AxisNameID>
    </Axis>

    <!-- Width -->
    <Axis>
      <AxisTag>wdth</AxisTag>
      <Flags>0x0</Flags>
      <MinValue>75.0</MinValue>
      <DefaultValue>75.0</DefaultValue>
      <MaxValue>100.0</MaxValue>
      <AxisNameID>258</AxisNameID>
    </Axis>

OK, so the default for opsz is 96.0. Now let's look at some named-instance records. In particular, I'm picking out the records that have postscriptNameID="6":

    <!-- ExtraBold -->
    <!-- PostScript: BricolageGrotesque-ExtraBold -->
    <NamedInstance flags="0x0" postscriptNameID="6" subfamilyNameID="17">
      <coord axis="opsz" value="14.0"/>
      <coord axis="wght" value="800.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

    <!-- ExtraBold -->
    <!-- PostScript: BricolageGrotesque-ExtraBold -->
    <NamedInstance flags="0x0" postscriptNameID="6" subfamilyNameID="17">
      <coord axis="opsz" value="12.0"/>
      <coord axis="wght" value="800.0"/>
      <coord axis="wdth" value="75.0"/>
    </NamedInstance>

    <!-- ExtraBold -->
    <!-- PostScript: BricolageGrotesque-ExtraBold -->
    <NamedInstance flags="0x0" postscriptNameID="6" subfamilyNameID="17">
      <coord axis="opsz" value="12.0"/>
      <coord axis="wght" value="800.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

    <!-- ExtraBold -->
    <!-- PostScript: BricolageGrotesque-ExtraBold -->
    <NamedInstance flags="0x0" postscriptNameID="6" subfamilyNameID="17">
      <coord axis="opsz" value="96.0"/>
      <coord axis="wght" value="800.0"/>
      <coord axis="wdth" value="75.0"/>
    </NamedInstance>

    <!-- ExtraBold -->
    <!-- PostScript: BricolageGrotesque-ExtraBold -->
    <NamedInstance flags="0x0" postscriptNameID="6" subfamilyNameID="17">
      <coord axis="opsz" value="96.0"/>
      <coord axis="wght" value="800.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

This concerns me, because it means that there are 5 "named instances" of the font that all reference the same PostScript name, yet have different variation-axis settings. Given that on macOS, the PostScript name is used as a key font identifier, this is a recipe for confusion.

In addition, it is a clear violation of the OpenType spec. The spec for the fvar table says:

The postScriptNameID field provides a name ID that can be used to obtain strings from the 'name' table that can be treated as equivalent to name ID 6 (PostScript name) strings for the given instance. Values of 6 and 0xFFFF can be used; otherwise, values must be greater than 255 and less than 32768. If the value is 0xFFFF, then the value is ignored, and no PostScript name equivalent is provided for the instance. The value 6 should only be used if the named instance corresponds to the font’s default instance. (my emphasis)

All 5 of the instance records excerpted above point to postscriptNameID 6, "BricolageGrotesque-ExtraBold". But only one of them (the 4th out of the 5) corresponds to the font's default instance.

There are similar issues with the other named instance records: multiple conflicting instances references the same name, whereas the fvar spec tells us:

All of the instance records in a font should have distinct coordinates and distinct subfamilyNameID and postScriptName ID values.

So each of the distinct instances needs to have its own distinct subfamilyNameID; they cannot be shared. (And unlike the PostScript name, there isn't an option to just omit them.)

m4rc1e commented

I don't get this for the variable font in this repo, https://github.com/ateliertriay/bricolage/blob/main/fonts/variable/BricolageGrotesque%5Bopsz%2Cwdth%2Cwght%5D.ttf

Here's the ttx fvar dump

<?xml version="1.0" encoding="UTF-8"?>
<ttFont sfntVersion="\x00\x01\x00\x00" ttLibVersion="4.39">

  <fvar>

    <!-- Optical size -->
    <Axis>
      <AxisTag>opsz</AxisTag>
      <Flags>0x0</Flags>
      <MinValue>12.0</MinValue>
      <DefaultValue>96.0</DefaultValue>
      <MaxValue>96.0</MaxValue>
      <AxisNameID>256</AxisNameID>
    </Axis>

    <!-- Weight -->
    <Axis>
      <AxisTag>wght</AxisTag>
      <Flags>0x0</Flags>
      <MinValue>200.0</MinValue>
      <DefaultValue>800.0</DefaultValue>
      <MaxValue>800.0</MaxValue>
      <AxisNameID>257</AxisNameID>
    </Axis>

    <!-- Width -->
    <Axis>
      <AxisTag>wdth</AxisTag>
      <Flags>0x0</Flags>
      <MinValue>75.0</MinValue>
      <DefaultValue>100.0</DefaultValue>
      <MaxValue>100.0</MaxValue>
      <AxisNameID>258</AxisNameID>
    </Axis>

    <!-- ExtraLight -->
    <NamedInstance flags="0x0" subfamilyNameID="259">
      <coord axis="opsz" value="14.0"/>
      <coord axis="wght" value="200.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

    <!-- Light -->
    <NamedInstance flags="0x0" subfamilyNameID="260">
      <coord axis="opsz" value="14.0"/>
      <coord axis="wght" value="300.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

    <!-- Regular -->
    <NamedInstance flags="0x0" subfamilyNameID="261">
      <coord axis="opsz" value="14.0"/>
      <coord axis="wght" value="400.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

    <!-- Medium -->
    <NamedInstance flags="0x0" subfamilyNameID="262">
      <coord axis="opsz" value="14.0"/>
      <coord axis="wght" value="500.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

    <!-- SemiBold -->
    <NamedInstance flags="0x0" subfamilyNameID="263">
      <coord axis="opsz" value="14.0"/>
      <coord axis="wght" value="600.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

    <!-- Bold -->
    <NamedInstance flags="0x0" subfamilyNameID="264">
      <coord axis="opsz" value="14.0"/>
      <coord axis="wght" value="700.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>

    <!-- ExtraBold -->
    <NamedInstance flags="0x0" subfamilyNameID="265">
      <coord axis="opsz" value="14.0"/>
      <coord axis="wght" value="800.0"/>
      <coord axis="wdth" value="100.0"/>
    </NamedInstance>
  </fvar>

</ttFont>

Same for the family in Google Fonts.

jfkthame commented

Huh, interesting. I downloaded the font resource (in woff2 format) that was linked from https://ateliertriay.github.io/bricolage/. Maybe that was a different version?

edit: that was https://ateliertriay.github.io/bricolage/fonts/BricolageGrotesqueVF.woff2, to be exact.

kenmcd commented

If you use the links on that page it will lead to the current fonts.
It appears you downloaded the font file in use on that web page - which is older, and the instances are a mess. The VF in the file name means it was probably created by the font developer (for the demo page).
Use the correct download links and it should be fine.

  • 👍1
m4rc1e commented

Thanks both. It appears the fonts on the github.io site appear borked

@MathieuLoutre update the fonts on the site to use the latest fonts in https://github.com/ateliertriay/bricolage/tree/main/fonts/webfonts

@jfkthame I thought your alias seemed familiar ;-). Glad to see you're still at Mozilla.

jfkthame commented

:-) Yeah, I noticed this while looking into an issue with variation-font rendering in Firefox, and that github.io page was the testcase given. So (naturally) I grabbed the font resource being used there in order to investigate.

(There's still a Firefox issue to be solved; unfortunately just correcting the font doesn't fix things.)

MathieuLoutre commented

The VF in the file name means it was probably created by the font developer (for the demo page).

That's correct, the file is generated by Glyphs so I'm surprised it's a mess since they're usually pretty good. However, I've now updated the font file to match the one in the repo so hopefully that bit is sorted. Let me know if not!

jfkthame commented

Looks better, thanks!

jfkthame commented

I guess the other thing to consider would be reporting an issue to Glyphs, if it potentially generates bad 'fvar' tables with conflicting instances. Might be worth checking if you can reproduce that behavior, and if so, report it to Glyphs/Georg?

  • 👍1
MathieuLoutre commented

@m4rc1e @emmamarichal this was Georg had to say about the glyphs file and why it didn't generate the correct fvar table. Something to keep in mind for future releases maybe? https://forum.glyphsapp.com/t/variable-font-export-generates-bad-fvar-table-with-conflicting-instances/27469/4

Here, as quote:

You have instances with the same name, that are split in different families for static fonts. To make this work in variable fonts, you need to add “Variable Style Names” for the instances. And those need to be unique.

jfkthame commented

That sounds like it makes sense; though I'd perhaps argue that Glyph should have warned, when asked to generate the variable font, that these names were lacking.