Statics with download of Recursive from Google Fonts work poorly on Windows, macOS, Adobe apps, and probably more #2616
Comments
|
It may be helpful to show specific TTX diffs of fonts. Not all the styles are the same, but some are. So, using fdiff, here are the most important diffs between the official statics & the Google Fonts generated statics, comparing
I have reduced the diff to focus on the only the tables which I believe are likely to cause problems for users, and placed these into detail dropdowns to hopefully keep this issue readable. This excludes hinting, which the official statics have but the generated statics lack. It is a lot of data which makes it sensible to exclude in webfonts and from this diff, but that shouldn’t really matter to desktop font users. OS/2 table
|
|
Hi Stephen, thanks for this extensive study! I don't give my teams fonts from https://fonts.google.com/, I take them directly here, and with good reason I think.
The presence of a STAT table also poses problems for MS Office for Mac. https://github.com/clauseggers/Playfair-Display/issues/24, for example. |
|
Thanks for the detailed report. I believe it is possible for the static
fonts instantiated from the variable font to work as well as the
thoughtfully-produced static fonts available from upstream, and these diffs
will be helpful at determining how fontTools can be used to achieve this.
|
arrowtype
changed the title
|
To explain the differences highlithed above by @thundernixon between the official static fonts & the Google Fonts generated static fonts, one needs to understand how each set is generated by fontmake. The static fonts are interpolated at the source UFO level: i.e. instance UFOs are first generated from the master UFOs + .designspace (by fontmake.instantiator). Then, instance-specific metadata like the ones defined in Glyphs.app custom parameters (e.g., panose, unicode ranges, OS/2 useTypoMetrics, etc.) are applied to each instance UFOs, and finally the UFOs are converted to TTF, with their own distinct OS/2, name, head, etc. tables. The Google Fonts generated static fonts as included in the downloadable .zip files are instantiated from the variable font built from the same set of master UFOs and .designspace used earlier to generate the static fonts. In the VF build process we first generate a set of master TTFs (one per master UFO) with interpolatable outlines (i.e. no overlaps removed), then use fontTools.varLib with these master TTFs and the same .designspace source to compute the deltas and store them in the variation tables. The new VF starts out as a copy of the default or neutral master TTF plus the the new variation tables added to it. Now, among the tables that don't change in a VF and are simply copied from the default master are OS/2, head and name table. Finally, when the GF instances are generated from a VF (using fontTools.varLib.instancer module), the deltas from each variation tables are computed and applied to the default tables, and the variation tables removed; however, all the non-variable metadata stay as it was in the VF, i.e. same as was the default master TTF. With that background, I'll now try to comment on each tables' diffs individually. I already touched upon a current limitation in our tooling that explain the differences in the name table. OS / 2
Again if we want the VF and thus the instances generated from it to be flagged as WWS, we need to make sure the default master from which the VF is generated to be flagged as such. I suspect that in Recursive only the invidual instances have the corresponding custom parameter for WWS in the .glyphs source. We should try to copy that parameter to the font panel so that it affects all the masters/instances. Note that even if inside Glyhps.app a custom parameter appears as greyed out (to indicate that it is unsupported for the current font/master/instance panel), fontmake (via glyphsLib) will happily apply it nonetheless. head
this is computed automatically, you can ignore
the bit 1 (the second starting from the right) is always recomputed by fonttools. It should be correct in the generated instance. STATThe fontTools instancer keeps the VF's STAT table DesignAxes, and prunes AxisValues that are out of range and keep only those that are at the same position as the instance. Initially the instancer (formerly known as mutator) was dropping the STAT table as a whole for full static instances, but we changed it to keep the original STAT design axes as the table is supposed to be a superset of fvar and describes relations between members of a family, variable and not, see fonttools/fonttools#2049 (comment) |
|
A user wrote in,
I guess this is related to this issue. |
|
Related issues: |
|
@RosaWagner I've send you some private fonts to preview how the GF API engineering team are planning to resolve this, please take a look and post any suggestions about how they should be different, and I will do the same :) |
|
I’ve noticed that Inter statics in the Salma ZIPs are missing Italic fonts, even though the variable font includes both wght & slnt axes. This is probably due to Inter lacking a proper STAT table.
Current STAT table of Inter (lacks entries for weight locations and for Roman/Italic locations: <STAT>
<Version value="0x00010001"/>
<DesignAxisRecordSize value="8"/>
<!-- DesignAxisCount=2 -->
<DesignAxisRecord>
<Axis index="0">
<AxisTag value="wght"/>
<AxisNameID value="270"/> <!-- Weight -->
<AxisOrdering value="0"/>
</Axis>
<Axis index="1">
<AxisTag value="slnt"/>
<AxisNameID value="271"/> <!-- Slant -->
<AxisOrdering value="1"/>
</Axis>
</DesignAxisRecord>
<!-- AxisValueCount=0 -->
<ElidedFallbackNameID value="2"/> <!-- Regular -->
</STAT> |
|
Just took a look at Salma's output. The font nametable's LGTM. They use the typo family name and typo subfamilyname correctly. My only criticism is the filenames. They currently include the axis tags e.g @RosaWagner also pointed out that nameID 25 may be redundant. I'm wondering if this update can handle multilingual nameRecords? |
In this case, if the same style name is used in 3 axes, and only 2 are used, which 2 are used will be ambiguous, and the 3 different pairs will all look the same.
Yes, that isn't needed in statics.
These should be stripped or handled the same way. We haven't got fontbakery checks for those, so if they are included, its by the grace of the upstream, and so probably dropping them and filing a tech debt issue to go back in and fix them all up across the library would be good. |
|
This should now be fixed, please comment if not |
Hi @davelab6 I downloaded Inter on https://fonts.google.com/specimen/Inter today and I tested it in Microsoft Word 365 for Mac, version 16.46 (February 2021 update). First test: The fonts have The fonts have a dummy In a comment above, @anthrotype wrote:
Yep. Still forgotten. Second test, with Third test, with Like I said in my August 2020 comment, the mere presence of a I should point out that before each of my tests with a new version of the fonts, I emptied the contents of the following folders:
|
|
@davelab6 please reopen this (I somehow can't) I don't think panose is relevant here, but incorrect fsSelection and incomplete STAT definitely are. We need to investigate whether our internal tools are doing the right thing. |
|
@anthrotype could you by any chance upload the corrected Inter font files here till the issue is fixed upstream? |
|
Nevermind, found the correct files in the Inter project repo! |
|
Nobody is assigned to this? |
|
I just ran into this bug again today when I installed the Space Grotesk static files from the zip archive downloaded from https://fonts.google.com/specimen/Space+Grotesk. Because Space Grotesk doesn't have a SemiBold instance defined in the variable font (issue #3411), and the tool that generates the static files still generates a file every 100 weight units, while leaving a minimal MS Office for Mac reads this, and concludes that Space Grotesk Semibold is "Space Grotesk Regular", which means that we end up with two "Space Grotesk Regular" (the real one and the SemiBold). |
The static fonts for Recursive that are available via the "Download Family" function of the Recursive specimen on Google Fonts have several issues that make them very unuseful in most contexts.
This is a particular problem because many designers would be likely to use static fonts to design a website or app before then using Google Fonts to provide the fonts on the web. And, many popular design tools currently work best with static fonts – exporting variable fonts to PDFs is flaky, and variable fonts aren’t yet supported at all in Figma.
Until this can be resolved, I propose that we replace the current, auto-generated fonts with the statics available from the official Recursive releases. I know this approach may not work for every family, but the Recursive statics have been specifically engineered by Ben Kiel, a type engineer with years of experience, so it would be worth making an exception to use the higher-quality fonts until the auto-generated instances can perform as well.
Issues include
Filenames
Filenames are confusing. They should do something to include the instance names, such as
RecursiveMonoCslSt-BlkItalic.otf(an abbreviated form used in the Recursive releases – possibly, it would be even better with less abbreviation). Instead, the downloads from Google Fonts specify the weight first, then axis values, which are hard to understand without a fairly deep knowledge of the font, such asRecursive-Black-CASL=0-CRSV=1-MONO=0-slnt=0.ttf.Font style sorting & availability
General disruption of design intent
Incorrect & Limited styles
Solutions
fvartable.I know it takes a lot to make a service as complex as Google Fonts, and I know things like this are inevitable. But, I’m hoping it can be resolved relatively quickly, as the main solution is pretty simple. Let me know if you need any further info. Thanks!
The text was updated successfully, but these errors were encountered: