user agent behaviour with regards glif naming and contents.plist
Schrijver
I’m looking at glif filenames in the context of versioning fonts (in this case Open Baskerville). The UFO specification allows you to use any algorithm you want to for coming up with glif filenames, and I’m trying to figure out how this works in practice.
Are you restricted within a font to use one algorithm?
Or can you use multiple algorithms within a font?
This could potentially happen if multiple people contribute to a font using different programs.
Uptil now collaborators on OpenBaskerville have used Fontlab with the Robofab scripts, but ideally we’d also have FontForge contributors. By default, RoboFab’s Fontlab export scripts use the glyphNameToShortFileName algorithm from RoboFab. FontForge uses an implementation of another algorithm, that is described in the UFO 2 specification and implemented in RoboFab as glyphNameToFileName.
Presently FontForge doesn’t really save UFO’s, it ‘generates’ them, so you can open up a UFO, change it, and then regenerate it. In doing so it doesn’t really pay attention to contents.plist, instead it will regenerate all glyphs with using the glyphNameToFileName algorithm. This means in our case, that the glyphs get new filenames.
http://schr.fr/tlkng/ufo-roundtrip.html
This seems wrong to me—I would suppose the user agent needs to respect the mapping for those glyphs already present in contents.plist when saving the filenames?
I can ask the FontForge developers to change it such.
But if FontForge would respect contents.plist but also retain its own naming algorithm, we will end up with a font that uses two filenaming conventions: one for the original glyphs (as codified in contents.plist), and another for the new glyphs added using FontForge.
Would this be ok? It seems the logical conclusion of the spec, but at the same time it might cause clashes?
thanks,
Eric
Erik van Blokland
On 9 mei 2011, at 21:55, Schrijver wrote:
> Are you restricted within a font to use one algorithm?
> Or can you use multiple algorithms within a font?
> This could potentially happen if multiple people contribute to a font using different programs.
Admittedly, it isn't pretty to have collected several namingschemes over the years. But we came by them honestly, we wanted to have meaningful, human readable names. We underestimated the number of edge cases and we had to extend the algorithm a couple of times to prevent collisions. Mea culpa.
For existing glyphs, contents.plist connects the glyphs to the glifs, in *both* ways. GlifLib, that comes with RoboFab, keeps track of the original glif filename: when it writes a glyph back to the font, it uses the _original_ glif name, even when it is different from the default available naming scheme (in the app).
For new glyphs scheduled to be saved into an existing UFO, the app should use its namingscheme of choice, test whether the glifname it generates is already present, deal with it and finally add the new name pair to the contents.plist.
Apart from the occasional orphaned glif, there shouldn't be a problem.
> But if FontForge would respect contents.plist but also retain its own naming algorithm, we will end up with a font that uses two filenaming conventions: one for the original glyphs (as codified in contents.plist), and another for the new glyphs added using FontForge.
That's not a problem as long as FF respects the existing name mapping, and checks for collisions in new names. Different apps (even with a different default naming scheme) have respect the glyphname / glifname relationship as defined in contents.plist and remember which glifname a glyph was read from. It seems FontForge could perhaps use a little encouragement in that area? Robofab's glifLib does it the right way.
What happens for instance if FontForge exports a single glyph to a ufo? (or can it do that?)
Cheers,
Erik