You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#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:
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.
The text was updated successfully, but these errors were encountered:
#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.
The text was updated successfully, but these errors were encountered: