Closed thlinard closed 2 years ago
For the optical size fallbacks, I guess we can't expect another behaviour for now (cf. https://github.com/googlefonts/gf-docs/issues/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:
italic
is repeatedregular
italic
doesn't appearAll of this can be solved by building the font just by using gftools builder
.
Steps
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.
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.
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.
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
).
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
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:
Non-elided default opsz value:
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. :)
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 https://github.com/googlefonts/fontbakery/issues/3090)?
Also, if at the same time you could implement the requirements of https://github.com/googlefonts/fontbakery/issues/3335, it would correct some cases listed in issue #3411 and it would be great!
Btw, to quote @moyogo (hi Denis!), about the Noto fonts:
We can fix the STAT tables. https://github.com/google/fonts/issues/3365#issuecomment-832121351
Another very recent example (yesterday) of a PR where instances of STAT
and fvar
don't match: #3559
@aaronbell and all, please could you update us all here on the status of the work on this? :)
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.
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 :)
Hi @aaronbell
Can you reopen the issue? Correct me if I'm wrong but:
fvar
instance has <coord axis="SOFT" value="100.0"/>
while all other instances, Italic or Regular, have <coord axis="SOFT" value="0.0"/>
).Isn't the general principle not to close an issue until the fix is released, rather than just at the PR stage?
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. 😄
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 thefvar
andSTAT
tables: the named instances are thefvar.NamedInstance
but their names are not extracted from theirsubfamilyNameID
, but are built from theValueNameID
attached to theSTAT.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
andfvar.NamedInstance
(in both cases, there is a SemiBold infvar
but not inSTAT
). 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)