"Thin" instance not selectable in macOS Pages

[thundernixon]

The problem

As originally described in the docs of this repo (Problem: in split VFs, it is impossible to select "Thin" in Apple Pages) and then re-flagged by @m4rc1e, it is impossible to select the "Thin" weight of Encode Sans in macOS Pages.

One issue that this helped me catch: the name IDs weren't quite as they should have been, in the Encode Sans variable fonts. These should follow this format:

name 1:  Encode Sans Thin # (default instance is "Thin"), so this should show up in apps that don't support VFs
name 2:  Regular
name 16: Encode Sans
name 17: Thin

This fix does allow the Thin style to be selected in MS Word:

• (Note, I still do need to adjust the Encode Sans build process to ensure that variable fonts are receiving the correct naming)

However, even after changing this and triple-checking that the STAT table is made to correctly link to all instance values and names, "Thin" remains unselectable in macOS Pages.

It's not just Encode Sans

@mjlagatutta has pointed out that Hepta Slab also has a similar issue: it's "Hairline" weight is also unselectable, and instead shows up as the Medium weight.

Deliberate testing with a test font

I wanted to reduce the number of variables and see whether a simpler font still demonstrated the issue. So, I made a quick test font and built it into a variable font with FontMake, from scratch and with no build process other than fontmake -o variable -g <file_path>.

The test fonts and other files are located at https://github.com/thundernixon/Encode-Sans/tree/master/docs/tests/macos-pages-vf-test-thin-2018-02-11.

However, when a font has both "Thin" at 100 and "Medium" at 500, Pages won't allow the user to access a thin.

The actual "Thin" for this font should be this weight:

I wanted to push on this a bit, to understand when, exactly, Pages would respect a Light style. Given that Hepta Slab fails, while things work for fonts like Comfortaa or Signika with "Light" styles at 300, my guesses were:

• It could be an issue of instance weight value – if the "weight" axis is lower than 300, it would fail.
• It could be an issue of font style naming – if the name isn't a recognized value like "Regular" or "Light", maybe it wouldn't work
• It could be a combination of the above two factors.
• It could be that fonts only fail when there is a Thin and a "Medium" instance.

Hypothesis: A "weight" axis is lower than 300 causes failure

❌Nope. ❌

It's not a weight value issue, based on tests of fonts with their minimum weights at 100, 200, and 300.

100–900 weight range:

200-900 weight range:

300–900 weight range (the Regular looks light, because the thin master is now set to 300, so 400 is very close to that):

Hypothesis: unsupported font style naming causing failure

❌Nope. ❌

It's not that using the name "Light" rather than "Thin" or "Hairline" makes things work, even if the lightest weight value is 300:

Hypothesis: A font having both "Thin" and "Medium" weight names causes failure

❌Nope. ❌

It also fails if there is no "Medium" font name, but now the Thin value calls the "Regular" instance instead:

---

With these tests failing, I'm not quite sure what to test next ... Could it be that Pages somehow measures the weight / density of fonts, and simply won't allow something that is too light?

• once we have identified the core issue (if possible), I will file this issue with Apple (unless there really is a problem we can find in the files we're building)

[thundernixon]

I've rebuilt my split VFs, and found an issue that seemed like it might be causing this ... but it isn't.

The issue:

Encode Sans has its lightest instance as "Thin," but FontMake is building the name table with:

    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Encode Sans Condensed Light
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>

However, even after TTXing the TTF, then manually changing the nameID 1 to Encode Sans Condensed Thin, then TTXing it back into a TTF and installing it ... it is still failing to show up in Pages.

[thundernixon]

I've just found that Thin can be selected if the variable font is generated directly from GlyphsApp. This has the caveat that the Thin instance incorrectly has the instance name "Regular" in this method, but it might help me to find what the issue is.

• when you have a working file and drill into the exact issue, send all test files to felipe for a fontbakery testing routing

[thundernixon]

GlyphsApp-generated variable font tests

TL;DR: so far, I haven't found exactly what is making the Glyphs-generated VF allow the "Thin" styled to be selected in Pages, but I have also found that if the style names are corrected in the Glyphs-generated VF, it once again introduces the broken behavior.

---

The GlyphsApp-generated variable font initially fixes part of this issue. The "Thin" style becomes selectable, but it has the style name "Regular."

This may point out what specific difference could be applied in a fontmake-generated VF to enable the Thin weight to be selected.

Differences between GlyphsApp-generated and FontMake-generated VF

GlyphsApp-generated VF

FontMake-generated VF

• Weight values in the STAT table
  • Glyphs VF: remain as 34–193, as they are in the source file
  • FontMake VF: values are 100–900
• Ital axis in STAT table
  • Glyphs VF: gets an ital axis, as well as a "Regular" block that points to this with a 0.0 value. This block also contains <Flags value="2"/>
  • FontMake VF: doesn't add an ital axis

Tests

TTX and change nameID 1 & 4 to "Encode Sans Condensed Thin"

Results:

• Pages shows the family as "Encode Sans Condensed Thin" in the font menu
• The font style menu still has two "Regular" entries, but now the one that used to link to Thin links to Medium

TTX and change nameID 1 & 4 to "Encode Sans Condensed Thin" give nameID 16 "Encode Sans Condensed" & 17 "Thin"

Results:

• Pages shows the family as "Encode Sans Condensed" in the font menu
• "Thin" is now selecting the Medium instance

This made me wonder if removing nameIDs 16 & 17 from the FontMake-generated VF would allow Thin to be selected in Pages. It doesn't.

Remove ital=0 block from STAT table

Results: No change – same as before, with two "Regular" styles, one linking to Thin instance

Background:

The Glyphs-generated VF has these pieces of seemingly-unnecessary code in the STAT table:

Within DesignAxisRecord:

    <Axis index="1">
        <AxisTag value="ital"/>
        <AxisNameID value="256"/>  <!-- Weight -->
        <AxisOrdering value="1"/>
      </Axis>

Within AxisValueArray:

    <AxisValue index="9" Format="1">
        <AxisIndex value="1"/>
        <Flags value="2"/>
        <ValueNameID value="2"/>  <!-- Regular -->
        <Value value="0.0"/>
      </AxisValue>

[thundernixon]

The fact that the Glyphs-generated VF worked (partly) when it had just the simple family name in nameIDs 1 and 4 made me wonder if simplifying Encode like this could make the Thin style accessible.

I changed nameID 1 to Encode Sans Condensed and 4 to Encode Sans Cond, but it still failing, linking the "Thin" name to the Medium instance.