don't reorder 'space', but simply warn when building COLRv0 if gid1 is not blank #886
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After reverting googlefonts/glyphsLib#1038, I also decided to revert #881 (at least the latter wasn't released yet).
It was a detail of DirectWrite COLRv0 implementation in Windows 10 that required that glyph at index 1 should be blank, but that's no longer the case for later Windows versions, and in fact the COLR OT spec also removed that.
MicrosoftDocs/typography-issues#346
There's no guarantee that a glyph named "space" is blank, and the reverted code was only checking glyph names.
There is no reason to put a glyph named "space" in second position in fonts that don't even contain COLRv0.
And one may well build a COLRv0 font that is not intended to work on older Windows and as such doesn't require the gid1 to be blank.
All in all, I think that it's sufficient to just issue a Windows-specific warning when the built font contains any COLRv0 color glyphs and the glyph at index 1 is not blank.
The font developer can then decide what is best, whether to ignore the warning or whether to add or select an empty glyph to be placed at index 1 by setting the appropriate
public.glyphOrderkey in the lib.plist.