Rewriting entire UFO package versus SCM systems

Glyphs, when saving for the first time UFO package previously created in some other app, rewrites and recreates all the files in the package, including messing up with internal original filenames. This is bad. This has devastating impact on any kind of source code management systems, which are then totally screwed. And this makes impossible to work in such SCM environments by people with different tools, any of them being the Glyphs.

I'm curious what are the technical limitations causing such scenario, if any. This seems to be rather a design decision. Once saved by Glyphs, any other subsequent modification to a font now apply only to corresponding files in such UFO package. But more importantly, if Glyphs can successfully import and interpret such externally generated UFO package then there's no need to rewrite anything for the sake of it or for any individual conventions. That's not what UFO format was created for. Philosophy behind UFO is interoperability and flexibility; and font format constituted by package of XML files gives us the long-awaited ability for such great workflows and tools like SCM systems.

I can give more detailed description of the problem if necessary. And please correct me if I'm getting something wrong here.

Hi,

I never thought about the impacts of the possible change of file names will impact SCM.

I just had a look at the naming rules and it seems they were stated more precisely since I looked there last time or I misread them. I will change the algorithms to generate the filenames according to the rules in the ufo specs.

Does it matter if the file date is changed? It is difficult to check, if the glyphs have changes since the last change.

I updated my code to work as stated in the specs.

Please check this in the next version (will be 0.4.5).

It just came to my mind that there are probably some more problems the glyph names and some difference in syntax of the XML.

Glyph names are converted to be more designer friendly (e.g.: afii10017 > Acyrillic) This can be avoided be deselecting the option "Convert glyph names" in Preference > User settings. Than the language filter in the font view and lot of other things do not work.

The syntax of the XML might be possible to fix to some extend.

Can you send me some files to test, both the original and the "damaged" one from Glyphs? This would be very helpful.

I’m really interested in getting the .ufo workflow right.

Is it a necessity at all to touch the glyphs filenames? There's contents.plist for mapping any desired glyphs' names to their actual filenames. And this is UFO's built-in solution for such issues. It gives designer or developer a freedom with naming glyphs while keeping the filenames intact. Also, it saves developers problems with not so precise recommendations or conventions for filenames, such as you have faced here.



I think that most reliable way for language filtering would be glyphs' unicode points, not filenames. Although this rises a problem of alternative glyphs, which don't have unicode assigned by nature, but I don't think that filenames are the best solution. Perhaps this is the place to follow OpenType's convention of alternate signature being added as .suffix to the glyph name. Designers are used to that, this could be quite intuitive and, what's important, without any affect on filenames.

Regarding rewriting XML contents, I will make few more simplified tests and I'll send you some files later today to check out. Thanks for your interest, anyway. It's a good work you're doing here.

OK, I've done some tests and here's the thing. And it's quite trivial, though significant in its consequences. The problem of rewriting XML files lies in handling of line indentations. Original files have tab indents and Glyphs changes them all to double-space indents. However such whitespace changes can be ignored when applying to SCM history, it does not save you from status warnings of hundred/thousands files being all changed at every line from top to bottom. So you can't tell whether anything really has changed.

The problem affects only .glif files. All the .plist files have had tab indents also, but somehow they're preserved. But .plists are native to Cocoa app, so I suppose you get this behavior out of the box. Surprisingly, any type of indents are preserved in the features.fea file, even when they're different types of indentations from line to line.

By the way, I've spotted some problems with .fea file generated by Glyphs, but it's a different issue so I'll spare myself talking about it now. Once again, thanks a lot.

I did this at first and there are a lot more problems. There are a lot glyphs with no unicode I need to address. (most arabic marks, all number variants, ligatures ...) if it where only for the filter I could find a solution but for the coverage presets there is now way.

On solution could be to store the glyph name on loading the glif file and use this to write back the glif file. There may be some issues with classes, kerning and features but if you use glyphs only to edit the glyphs, it should work.

Or stick with the nice names and convert them only on export to final font. MakeOTF can do it for you nicely.