The description in the manual suggests that checking the ‘keep glyph names from imported files’ option prevents glyphs from imposing its own naming scheme, but this doesn’t seem to function as advertised. There’s two main cases where I’ve found this to be failing.
First, glyphs which are assigned PUA values seem to be renamed to uniXXXX format in many cases.
Second, glyphs which are double-encoded in the original font can have their names changed in very weird ways. For example, a recently opened and re-exported font contained a character named ‘Delta’ mapped to both 0394 and 2206 which was outputted with the name uni0394 mapped to 0394. The same font contained a character named ‘quoteleft’ mapped to both 02BB and 2018. In the exported font this retained the ‘quoteleft’ name but assigned only to 02BB (which is just plain wrong).
I understand that glyph doesn’t support assigning multiple code points to a single glyph, but there really should be a way to ensure that existing double-encodings are retained to prevent such mangling. Often there was a good reason why the original font contained double-encoded characters, and such encodings are perfectly consistent with the opentype spec.
It would be nice if the preferences included an option to ‘leave all glyph names and unicode code points alone’.
You are right. While it’s generally a bad idea that PUA Glyphs have a non-uniXXXX name, an alternative name should be retained if set.
Not so sure what should be done with double encodings though. Glyphs does not support them for good reasons, so I deem it more likely that we adapt the handbook rather than introduce double encodings. The question is, what should be done when opened in Glyphs? Duplicate the glyph for each codepoint, and mark them somehow?
Remember that the primary purpose of the software is not to ensure round-tripping for existing compiled fonts, but to make new ones. I agree as much of the contained information as possible should be retained, but there will be inherent limits occasionally.
I have a look at the renaming of the Delta. But the double encoding is not limited by the ability to store it or assign it in the UI but by makeOTF (the library from Adobe that Glyphs used to compile the .otf) not allowing it. I need to completely rewrite the compiler part to make it work. That is on my list for a while now.
We never advertised that Glyphs can open any OpenType font and directly compile it without changes. So after opening it, it is easy to fix those problems.
But I’m very thankful for reports like this to improve the parts that introduced problems.
While many people I’m sure use glyphs for making new fonts, I suspect that I’m not alone in using them primarily for modifying existing fonts to meet specific purposes (e.g. internationalization, adding optically correct super/subscript characters where needed, and so forth).
It’s also worth noting that the various different font editors available today each have there own strong points and weaknesses, and I suspect that there are those who would prefer to do some aspects of development using one applications and other aspects in another. For this reason I think it’s very important to avoid making changes to underlying font data except where absolutely necessary. I originally started looking at glyphs because it had the ability to fill in custom names for ssXX features whereas FontLab does not. Having looked at glyphs (still halfway through my trial period) I’ve found that many of the drawing tools in Glyphs look extremely promising, but that I prefer dealing with feature creation in FontLab. I’d like to be able to move back and forth between the two, but that currently doesn’t seem possible because Glyphs is retaining far less information than I believe it ought to.
With respect to double encoding, I think you’ll find opinions are divided on whether there is a good reason to exclude them. For TrueType fonts, there is really no reason at all. For CFF fonts there are arguments to be made but they primarily revolve around legacy issues involving a hacked approach to unicode support in CFF fonts and some limitations of acrobat distiller, all issues which are becoming increasingly less relevant over time. I think the decision here is one that should be left to the individual designer rather than imposed by the software.
I hope this post and my previous ones aren’t coming across as overly harsh since that isn’t my intention at all – I think glyphs is a very good program, but one with the potential to be a much better program. And I still have two weeks left on my trial to decide whether its strengths are sufficient to justify $400 CAD which I find myself going back and forth on.
Generally moving data back and forth between any two apps will always problematic (with the possible exception of simple plain text), because each software has other limits. If I were in your place, I would therefore look into the options and settle for one where you do the production, and if necessary keep the other around for opening/conversion purposes.
If you work only with compiled fonts, i.e. changing as little as possible without modifying anything else, OTMaster and ttx/fonttools are additional options you may want to look into.