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

should "space" be moved to gid1 in the glyph order, and if so how? #1045

Open
anthrotype opened this issue Nov 7, 2024 · 0 comments
Open

Comments

@anthrotype
Copy link
Member

#1038 (released with glyphsLib 6.9.3) moved the .notdef and space glyphs as the first two glyphs even when an explicit glyphOrder custom parameter was present; an additional (hidden) custom parameter would be needed to disable any such reordering.
This was apparently done to match Glyphs.app, although I haven't been able to consistently reproduce this behavior.
Therefore I decided to revert it with #1044 at least until we understand this better, and to avoid sudden changes to fonts that were perfectly working with previous glyphsLib 6.9.2. The glyph order affects all glyph-related tables and may impact hinting and other workflows that are tied to the glyph indices.

Everyone agrees .notdef must be first for the first glyph by definition can't be cmapped (gid0 means no unicode). But space as the second gid1 is not as universal requirement and was only added because of a bug or rather implementation detail in an older verisons of Windows related to color fonts with COLRv0 table:

MicrosoftDocs/typography-issues#346
googlefonts/gftools#609
googlefonts/ufo2ft#880

I am of the opinion that there should be no reordering if an explicit glyphOrder custom parameter is defined in the source.
ufo2ft only places the space after .notdef if an explicit public.glyphOrder is absent: googlefonts/ufo2ft#881

However, if Glyphs.app does override the user provided glyphOrder, then glyphsLib should probably try to mimic that, but we need to understand exactly how this works first.

glyphsLib always sets a public.glyphOrder in the exported master UFOs; when no glyphOrder custom parameter is present, I believe it uses the ordering of the glyphs in the source file (which in turn comes from Glyphs.app itself if I am not mistaken).

We could also leave things as is and do nothing.

Maybe ufo2ft could warn when building COLRv0 font if the second glyph has any contours so the font developer can decide for themselves.

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

1 participant