MS Office for Mac as a STAT-related bug catcher

[thlinard]

Office for Mac 2019 & 365 has VF support (only for named instances) since version 16.46 (February 2021 update). According to my tests (dummy fonts with fake nameID), the implementation is a mix between the fvar and STAT tables: the named instances are the fvar.NamedInstance but their names are not extracted from their subfamilyNameID, but are built from the ValueNameID attached to the STAT.AxisValue.

Prolepsis: I know, that doesn't sound like a valid interpretation of the standard. But with MS Office for Mac, we have one of the earliest implementations of using the STAT table, and that reveal a lot of bugs.

Some had already been reported in issue #2391, others are new, as for Literata and Roboto: divergence between STAT.AxisValue and fvar.NamedInstance (in both cases, there is a SemiBold in fvar but not in STAT). For the Noto*, I selected just one example.

Archivo Narrow

Fraunces

League Gothic

Noto * (example with Noto Sans Armenian)

Edit:
Corrected:

Changa (PR #3873)
Crimson Pro (PR #3632)
Dosis (PR #3668)
EB Garamond (PR #3633)
El Messiri (PR #3669)
Epilogue (PR #3634)
Exo (PR #3635)
Exo 2 (PR #3636)
Faustina (PR #3806)
Fira Code (PR #3786)
Inconsolata (PR #3760)
Inter (PR #3781)
Josefin Sans (PR #3664)
Jost (PR #3638)
Jura (PR #3639)
Lemonada (PR #3640)
Literata (PR #3805)
Lora (PR #3641)
Manrope (PR #3642)
Manuale (PR #3643)
Markazi Text (PR #3644)
Mohave (PR #3645)
Mulish (PR #3762)
Orbitron (PR #3670)
Playfair Display (PR #3649)
Public Sans (PR #3650)
Quicksand (PR #3410)
Roboto (PR #3791)
Rosario (PR #3651)
Ruda (PR #3652)
Saira (PR #3746)
Signika (PR #3783, #3782)
Work Sans (PR #3586)

[RosaWagner]

For the optical size fallbacks, I guess we can't expect another behaviour for now (cf. googlefonts/gf-docs#83).

Bodoni Moda, Fraunces, Literata, Truculenta are fine.
Roboto, Commissioner and Saira look fine too.
Archivo Narrow is low priority cause we just released Archivo (not narrow) with a width axis.

The problematic ones are:

• whenitalic is repeated
• when all styles are regular
• when italic doesn't appear

All of this can be solved by building the font just by using gftools builder.

Steps

1. Make a list of VF with a STAT issue by running fontbakery on the fonts catalog.
2. Assign the fonts to the original onboarder if still under contract
3. Rebuild the font with builder
4. Package

[thlinard]

For the optical size fallbacks, I guess we can't expect another behaviour for now (cf. googlefonts/gf-docs#83).

Bodoni Moda
Truculenta

I just find it weird to include the name of the optical size in the style, since it's always the same, but OK.

Fraunces

9 pt SuperSoft Thin Italic, whereas it's the only style which has "SuperSoft"?

Literata

Bold twice (this is because there is a SemiBold entry in fvar and not in STAT).

Roboto

Medium twice (this is because there is a SemiBold entry in fvar and not in STAT).

Commissioner

The Italic and Regular are inversed (but I agree that it could rather come from a bug in MS Office).

Saira

Instances in fvar have the name (ID) of a regular width instance, although they have a value of 100 on the wdth axis, but MS Office finds they should be called, according to STAT, " SemiCondensed ". There is a problem between the two tables: either you had to create named instances for all widths, or you had to restrict to a regular width. But having instances only for the SemiCondensed is very weird.

Archivo Narrow is low priority cause we just released Archivo (not narrow) with a width axis.

The problem is that there is no named instance for the width axis in Archivo, so in software that only manages named instances, Archivo cannot replace Archivo Narrow.

[m4rc1e]

Prolepsis: I know, that doesn't sound like a valid interpretation of the standard. But with MS Office for Mac, we have one of the earliest implementations of using the STAT table, and that reveal a lot of bugs.

I'm truly getting fed up of playing whack-a-mole here. We cannot move forward by changing our implementation when the software implementations may be broken (I accept that our older VFs are actually broken). I will chat to MS to understand their naming heuristic for MS Office and see what's the situation.

[m4rc1e]

Looking at your lists, the modern VFs mainly LGTM so we may not have an issue. It would be fairly trivial to fix the older families since our STAT table generation is automated. However, it will take time since we have to coordinate this work with the upstream repos.

[thlinard]

You are proud to show me how, following the dictates of your reason, you arrived at me, and yet you have shown me you arrived here by following a false reasoning. (Umberto Eco, The Name of the Rose)

Hi @m4rc1e

Yes, indeed the MS Office for Mac implementation is illogical. If you could find the right person at Microsoft to bring them to their senses, that would be great. And yet MS Office for Mac really does find bugs (even if it was up to specification it wouldn't find very different bugs), and it behaves well with well-made fonts.

For the problematic fonts, most of them are the earliest VFs released by Google, true. But some are recent: Roboto for example (because a SemiBold entry in fvar and not in STAT).

[thlinard]

For Saira, this relevant part of the specs applies:

We only allow weight and italic particles. If a font contains additional axes, they must not be mentioned in the instance names and the coordinates for each instance must be set to reasonable default e.g if your font contains a wdth axis, you don't want every instance's wdth coordinate value to be set to Condensed (75) you would set it to Normal (100).

https://github.com/googlefonts/gf-docs/tree/main/Spec#fvar-instances

[thlinard]

For the optical size fallbacks, I guess we can't expect another behaviour for now (cf. googlefonts/gf-docs#83).
Bodoni Moda
Truculenta

I just find it weird to include the name of the optical size in the style, since it's always the same, but OK.

Well, after comparison:

Elided default opsz value:

• Newsreader
• Texturina

Non-elided default opsz value:

• Bodoni Moda
• Fraunces
• Imbue
• Literata
• Truculenta

[aaronbell]

Alright, so before diving into this I thought it good to conduct a full survey of the main branch and look at all of the variable fonts, reviewing each one in Mac Word as that seems to be the best environment for finding inconsistencies / bugs due to its unusual implementation :).

Of the 179 font families (this counting each Noto Sans / Noto Serif separately) I found:

Evaluation result	Number of fonts
STAT table displays OK	58
Defaults to weight other than "Regular" or other oddities	19
Fonts displaying a problem in font drop down	102

Next step will be figuring out the best way to update all of these. :)

[thlinard]

Hi @aaronbell

It's great news to see you take on this task!

If I may suggest, the current version of tools like gftools builder or gftools fix-vf-meta are perfectly capable of fixing most of the bugs listed, except maybe for one kind of them: it isn't sure that the instances between the fvar table and the STAT table will be identical, as we can see with very recent creations (Mulish version 3.602, Literata, Roboto…).

According to OT specs: "In a variable font, every element of typographic subfamily names for all of the named instances defined in the 'fvar' table should be reflected in an axis value table" and in the particular implementation of MS Office for Mac, it's essential: it isn't only a display bug, it prevents the selection of the chosen weight. Maybe there should be a FontBakery check for this (a broader check than fonttools/fontbakery#3090)?

Also, if at the same time you could implement the requirements of fonttools/fontbakery#3335, it would correct some cases listed in issue #3411 and it would be great!

[thlinard]

Btw, to quote @moyogo (hi Denis!), about the Noto fonts:

We can fix the STAT tables.
#3365 (comment)

[thlinard]

Another very recent example (yesterday) of a PR where instances of STAT and fvar don't match: #3559

[davelab6]

@aaronbell and all, please could you update us all here on the status of the work on this? :)

[aaronbell]

Hi all, things have been progressing :)

I've submitted PRs covering 40 font families with known STAT-table related issues. And already, 6 have been merged in.

Please see https://docs.google.com/spreadsheets/d/1ymMU2yrWfItwr7Z5tyPPbx4XqUqF3aMTrf8KJoqVFrU/edit?usp=sharing for the full list of fonts being updated, as well as their current status.

[aaronbell]

I believe that all fonts that needed correction have been corrected, and PRs opened for each. Given that, I'm going to go ahead and close this issue :)

[thlinard]

Hi @aaronbell

Can you reopen the issue? Correct me if I'm wrong but:

1. No PR for Archivo Narrow: maybe it should be delisted or fixed?
2. No PR for Fraunces (Please correct SOFT value for Thin Italic instance undercasetype/Fraunces#259: the Thin Italic fvar instance has <coord axis="SOFT" value="100.0"/> while all other instances, Italic or Regular, have <coord axis="SOFT" value="0.0"/>).
3. No PR for Noto * (Noto Sans, Noto Sans Display, Noto Sans Mono, Noto Sans Balinese, Noto Serif, etc., etc.: https://fonts.google.com/?query=Noto&vfonly=true).

Isn't the general principle not to close an issue until the fix is released, rather than just at the PR stage?

[aaronbell]

Actually, I'm going to close this as a dupe against #2391 so that there's only one issue tracking these. Let's continue discussion over there. 😄