Naive glyphname => IR filename leads to glyphs overwritten on case insensitive filesystems

[anthrotype]

right now we use {glyph_name}.yml but that only works on case sensitive fs like Linux.

Initially I thought I'd use norad's user_name_to_file_name method (which uses UFO filenaming conventions) for this, but it actually complicates things because we need to know all glyph names upfront and it's order dependent (we can't call that on demand because its output depends on the order in which duplicate clashes are handled).

we could try see if we can use a scheme like Just proposed in unified-font-object/ufo-spec#164, which has an added bonus of being reversible

[anthrotype]

I just re-stumbled on this while running fontc on a Mac. It happens with any font that has both uppercase and lowercase glyphs e.g. "A" and "a" as in the following test file: Aa.glyphs.zip

running fontc -s Aa.glyphs the first time produces a correct font, but then modifying one of the two glyphs and running fontc -s Aa.glyphs a second time leads to invalid results where one of the two glyphs gets lost.
The build/glyph_ir and build/glyphs folder only contain respectively a.yml and a.glyf (the filename is always normalized as lowecase, but if you inspect the glyph name stored in the yaml file it can be either "a" or "A" depending on which one wins..)

This makes using the default --emit-ir=true very risky when running fontc on a non-Linux.

[anthrotype]

Maybe incremental build should be opt-in rather then opt out, and --emit-ir=false by default.

[justvanrossum]

I've previously suggested some ideas to enhance the UFO glyph name -> file name scheme, but today I would be inclined to just append a hash of the glyph name to the file name. A.<hash-of-A>.ext

Regardless of incremental build issues, this seems a problem worth fixing.

[rsheeter]

How are case insensitive filesystems still a thing! It's quite handy to have a human readable name when troubleshooting. Let's implement a scheme to make it work.

[anthrotype]

Thanks Just. I had linked to that other thread, contains useful hints but got sidetracked.

I would be inclined to just append a hash of the glyph name to the file name. A.<hash-of-A>.ext

but hash cannot be reverted, can it? Ideally we'd be able to go in either direction with only the glyph name or the filename available.

I still like the idea of keeping the conventional _ after a capital letter (used both in UFO glif filenames and fonttools table modules), it's readable and familiar, and it is reversible if the underscore itself is doubled up.
And for the reserved characters, I like the percent escaping that you proposed, which is similarly familiar with URLs.
For reserved filenames (e.g. CON on Windows) we could add a leading underscore at the beginning to differentiate; any leading underscores that don't match up with a preceding character can be stripped when going filename=>glyph name.

[rsheeter]

#487 and friends are resolved, afaics we're done here.