search

uswds / public-sans

A strong, neutral, principles-driven, open source typeface for text or display
https://public-sans.digital.gov/
Other
4.45k stars 102 forks source link

naming issue in public-sans variable-width font file #233

Open jdpipe opened 2 years ago

jdpipe commented 2 years ago

Hi there,

I wanted to pass on an issue that was originally reported over at font-config, but seems to finally be an issue with the Public Sans font itself, at least in part. See here:

Coincidentally, I have done some bulk-analysis of Google Fonts, and I can say that the Public Sans variable TTF file has "PublicSans-Thin" in its name table entry. That's why fontconfig and other programs are returning it. That should be considered a bug in the font itself, and likely originates in how they build the VF binary from the multiple-master sources. The static versions of the same font, notably, have correct name table data.\

More information: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/285#note_1245547

Cheers JP

kenmcd commented 2 years ago

When variable fonts are not supported in the application (such as LibreOffice) the correct thing to do (per the OpenType specs) is to display the default master. In Public Sans the default master is Thin. So that is what you see. Nothing wrong with the variable font.

LibreOffice users should use the static fonts.

fwextensions commented 2 years ago

@kenmcd does Chrome on Windows not support variable fonts? I'm trying to use Public Sans with the Fontsource npm package and Gatsby, and Chrome reports the rendered font as Public Sans Thin even when the text is bold:

image

This is the first time I'm trying to do much with custom web fonts, so I could be including it incorrectly. I'm using import "@fontsource/public-sans"; in the gatsby-browser.js file, which seems to be the recommended way.

In any case, it was surprising to see the Thin variant being reported in Chrome when the weight was 700, which is how I ended up down this rabbit hole.

kenmcd commented 2 years ago

@kenmcd does Chrome on Windows not support variable fonts?

Yes, Chrome on Windows does support variable fonts. You can test Public Sans Variable in any Chromium-based browser here: https://fonts.google.com/specimen/Public+Sans#type-tester

If I were you I would first use a very simple local test and get that working. Then try to use some more complicated system later.

fwextensions commented 2 years ago

Inspecting the rendered fonts on (most of) that Google Fonts page also shows Public Sans Thin. But I noticed that the table of glyphs at the bottom shows Public Sans. The difference seems to be that most of the text is styled with font-family: "Public Sans script=latin rev=1", but the latter uses "Public Sans script=all rev=1". (And on macOS Chrome, it's using "Public Sans script=all rev=2", while changing it to rev=1 defaults to Times.)

In the section showing the different weight samples ("Public Sans Medium", "Public Sans Bold", etc.), changing the script to all does show the rendered fonts as Public Sans, but causes the bolder samples to lose most of their weight. They become the same width as regular, but are slightly heavier.

From this comment:

When variable fonts are not supported in the application (such as LibreOffice) the correct thing to do (per the OpenType specs) is to display the default master. In Public Sans the default master is Thin.

I was expecting that an app that does support variable fonts would therefore show the "correct" font name when it's displaying the "regular" weight, presumably Public Sans. So either Chrome doesn't correctly support variable fonts, or the fonts applied to different scripts have different names, or... something else.

kenmcd commented 2 years ago

From this comment:

When variable fonts are not supported in the application (such as LibreOffice) the correct thing to do (per the OpenType specs) is to display the default master. In Public Sans the default master is Thin.

I was expecting that an app that does support variable fonts would therefore show the "correct" font name when it's displaying the "regular" weight, presumably Public Sans. So either Chrome doesn't correctly support variable fonts, or the fonts applied to different scripts have different names, or... something else.

That is a different situation with desktop fonts, in a desktop application. Which is what was discussed in the link in the first post above.

There may be an issue with the variable fonts used on the demo page. The current version there is v1.007. Public Sans is in the process of being updated on Google Fonts. https://github.com/google/fonts/pull/4656 That version has some changes and fixes in it. That version is not yet live on Google Fonts (should be in a few days).

To test you should get the most recent fonts, and again, test locally first. Get the most recent release, v2.001, here: https://github.com/uswds/public-sans/releases If that works then wait for the online fonts to update (which takes awhile).

If you cannot get local fonts to work, I do not know what you can do. I test online variable fonts on Vivaldi (chromium-based) all the time.

fwextensions commented 2 years ago

It looks like the local fonts included with the @fontsource npm package are v1.007, and were just downloaded from Google Fonts. That explains why I was seeing the same behavior on my site and GF.

Thanks for the detailed explanations! BTW, the v.2001 release .zip file includes __MACOSX and .DS_Store folders, in case that matters.