Work around layer name issue on case-insensitive file systems #129
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
justvanrossum
force-pushed
the
fudge-layernames
branch
from
618399f to
818361c
Compare
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.
The rcjk format does not play well with case-insensitive file systems: layer names become folder names, and to read layer names we read folder names. Since layer names are global per font, case differences in layer names can cause ambiguities. For example, if a layer "s2" exists, a folder named "s2" will be written. If "S2" (cap S!) also exists, its data will be happily written to the "s2" folder on a case-insensitive file system. When reading back the project, we find "s2", but not "S2".
This PR below tries to detect that situation and work around it. This works as long as the layer names within a single glyph are not ambiguous: "S1" and "s1" should not co-exist in the same glyph.
The problem can also happen when checking out an .rcjk git project on a case-insensitive file system: "S2" and "s2" may both exist in the repo, but on a macOS/Windows checkout only one of them will be seen.