FontForge should respect contents.plist Glyphname Filename mapping
Closed this issue · 2 comments
In getting clean diffs in-between FontForge and RoboFab (RoboFont, Fontlab etcetera) based commits, FontForge has already implemented a similar pretty printing for the GLIF files (issue #5)
The remaining problem is that FontForge doesn’t keep track of the glyphname glyphfile relation as stored in glyphs/contents.plist , so that when you save the UFO file (which is generating the UFO over the old one), FontForge chooses filenames based on the glyph names and a predetermined algorithm, disregarding the existing filenames.
The algorithm being used by FontForge is the default one described in the UFO2 specs
http://unifiedfontobject.org/versions/ufo2/glyphs.html
The spec also states ‘There is no one standard glyph name to file name conversion’ and indeed the algorithm being used in the RoboFab Fontlab UFO export method is a different one.
It is called glyphNameToShortFileName
http://code.robofab.com/browser/trunk/Lib/robofab/objects/objectsFL.py#L950
The source is here:
http://code.robofab.com/browser/trunk/Lib/robofab/tools/glyphNameSchemes.py
So if a UFO is generated from Fontlab (like the initial Open Baskerville sources), and then modified in FontForge, FontForge will ignore the contents.plist and because of the differing glyph to filename conversions resave the glyphs under different filenames then in the original UFO.
In the meantime, here’s a Python implementation of the naming scheme which I think FontForge is using by default now:
def simplefilename(glyphname):
prefix = '_' if glyphname[0] == '.' else ''
parts = glyphname.split('.')
parts[0] = '_'.join([i + '_' if i[0].isupper() else i for i in parts[0].split('_')])
return prefix + '.'.join(parts) + '.glif'It looks like a lot of this got fixed in FontForge 20120731
The files keep the same know, there’s just some curve="true" being added all over the place:
https://github.com/klepas/open-baskerville/commit/2280bfcc2121fcc69510679ea6a69a9819d55510.diff