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
For several years I have imported a subset of Latin glyphs from Source Sans (using the UFOs in the Instances folders) for use in other non-roman fonts. This year the import failed, my import script uses fonttools and fonttools threw an exception
File "/home/bobby/.local/lib/python3.10/site-packages/fontTools/ufoLib/glifLib.py", line 204, in __init__
raise GlifLibError(f"{CONTENTS_FILENAME} is missing.")
This code was added in 2020 to fix an issue, which explains why I was able to import glyphs in 2019.
On my system (Ubuntu 22.04) I see 3 folders in the font.ufo folders that contain 3 folders:
glyphs
glyphs.com.adobe.type.processedGlyphs
glyphs.com.adobe.type.processedglyphs
Note that the last two folder names differ only by case. The last two folders each has a .plist file, and many .glif files. No filename is in both folders. Indeed, one of the folders did not have at contents.plist (which is what CONTENTS_FILENAME refers to).
The string glyphs.com.adobe.type.processedglyphs (all lowercase) is in the UFO metadata, glyphs.com.adobe.type.processedGlyphs (one uppercase G) is in .gitignore. By moving all the files from glyphs.com.adobe.type.processedGlyphs to glyphs.com.adobe.type.processedglyphs and removing the now empty folder, the import ran without any issue. My work in 2019 was not affected by this issue, since I was taking the glyphs from the default layer.
I suspect that at some point files were added to git with the different case in the folder name. On Windows and I think macOS, those systems are generally case preserving but case insensitive, so only two folders (glyphs and glyphs.com.adobe.type.processedglyphs) would have been created by git, and this whole issue would not occur. But Ubuntu Linux generally has case sensitive filesystems, so the issue occurs.
The text was updated successfully, but these errors were encountered:
For several years I have imported a subset of Latin glyphs from Source Sans (using the UFOs in the Instances folders) for use in other non-roman fonts. This year the import failed, my import script uses fonttools and fonttools threw an exception
This code was added in 2020 to fix an issue, which explains why I was able to import glyphs in 2019.
On my system (Ubuntu 22.04) I see 3 folders in the
font.ufo
folders that contain 3 folders:Note that the last two folder names differ only by case. The last two folders each has a
.plist
file, and many.glif
files. No filename is in both folders. Indeed, one of the folders did not have atcontents.plist
(which is what CONTENTS_FILENAME refers to).The string
glyphs.com.adobe.type.processedglyphs
(all lowercase) is in the UFO metadata,glyphs.com.adobe.type.processedGlyphs
(one uppercase G) is in.gitignore
. By moving all the files fromglyphs.com.adobe.type.processedGlyphs
toglyphs.com.adobe.type.processedglyphs
and removing the now empty folder, the import ran without any issue. My work in 2019 was not affected by this issue, since I was taking the glyphs from the default layer.I suspect that at some point files were added to git with the different case in the folder name. On Windows and I think macOS, those systems are generally case preserving but case insensitive, so only two folders (
glyphs
andglyphs.com.adobe.type.processedglyphs
) would have been created by git, and this whole issue would not occur. But Ubuntu Linux generally has case sensitive filesystems, so the issue occurs.The text was updated successfully, but these errors were encountered: