Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jdpipe opened this issue Feb 5, 2022 · 6 comments
Open

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

jdpipe opened this issue Feb 5, 2022 · 6 comments

Comments

@jdpipe
Copy link

jdpipe commented Feb 5, 2022

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
Copy link

kenmcd commented Feb 5, 2022

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.

@mejiaj mejiaj added the invalid label Mar 7, 2022
@mejiaj mejiaj added this to Ready to Close in USWDS Roadmap Backlog Mar 7, 2022
@fwextensions
Copy link

@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
Copy link

kenmcd commented May 28, 2022

@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
Copy link

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
Copy link

kenmcd commented May 28, 2022

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.
google/fonts#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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

No branches or pull requests

4 participants