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

Remove unreachable "rvrn" glyphs from static outputs when these glyphs are needed in variable outputs? #1115

Open
arrowtype opened this issue Aug 8, 2024 · 2 comments

Comments

@arrowtype
Copy link

arrowtype commented Aug 8, 2024

I’m building static & variable fonts from UFOs + a designspace, then checking them with Fontbakery.

The variable font includes several glyphs like dollar.rvrn, which swap forms in certain areas of the designspace, using rules elements in the designspace and the rvrn feature in the variable fonts.

These glyphs are used by FontMake to build the correct form of such glyphs into static fonts, which is great. However, the alternate form of the glyph also makes it into static fonts, where they are not needed. Then, the Fontbakery check com.google.fonts/check/unreachable_glyphs warns about these alternate glyphs being "unreachable," as they cannot be accessed via Unicode values or OpenType features. The extra glyphs don’t cause any major problems, but I’d rather them not be there.

Is there some setting or flag I could add to a build to remove such glyphs from the static fonts only?

Thank you for any insights!

@anthrotype
Copy link
Member

yeah I see what you mean. I think fontmake is just playing safe here, it can't tell if those glyphs may or may not be referenced elsewhere. Removing unreferenced glyphs is the job of a subsetter (pyftsubset or hb-subset), how about you just run that as separate step after the compilation?

@arrowtype
Copy link
Author

Thanks for the quick and informative response!

Okay, I suppose that answer makes sense. It would be nice if it were as simple as adding a flag to a fontmake command, but it’s helpful to confirm that this is not currently the case.

Feel free to close this if you don’t intend to take further action. Thanks again!

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

No branches or pull requests

2 participants