Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove the auto glyph renaming feature. #523
There is such a feature: when you rename a glyph "f" to "f.ss01" with scripting (I'm not sure about renaming in the UI, but I guess it's the same), Fontforge will automtically rename glyphs like "f_i" to "f.ss01_i" and "f.smcp" to "f.ss01.smcp".
I think this feature is harmful for scripting. The first problem is who writes scripts cannot anticipate such side-effect: why renaming one glyph would imply change to any other glyph at all? The second problem is, when you are doing something by renaming glyphs (I, for example, need to rename (x,x.oldstyle) to (x.lnum,x)), this feature makes your life very hard.
Therefore, I propose permantly removing this feature, at least for scripting. After all, if someone does want to rename all glyphs beginning with something, he can write a simple one-line script to do that.
Because this isn't documented, and someone who wanted to do it on purpose would have a hard time knowing whether it will or won't happen, I think "feature" is too charitable a description. This is a bug. Renaming glyphs sometimes causes other glyphs to change their names unexpectedly. Here is code to reproduce it:
I took a look at the code and unfortunately, this isn't going to be easy to fix. It appears that it was implemented on purpose in an effort to keep contextual lookups and so on consistent with each other. If a glyph named "foo" has its name changed to "bar", that doesn't just change some kind of name field for that glyph. What it actually does is a text search and replace operation of "foo" to "bar" in a bunch of fields throughout the font database. There also seems to be some kind of strange recursion going on - once it determines that for instance there is a glyph named "foo_wibble" which it will change to "bar_wibble" because "foo" is changing to "bar", it recursively looks for other glyphs with names like "foo_wibble_yoib" to change to "bar_wibble_yoib." (Why that's not subsumed by the parent transformation isn't clear, but may have to do with tokenizing in the search.)
It's probably not a good idea to make it really just change the name even though that is the obvious thing to do. The problem is that then we'd end up with all the substitution and kerning tables still referring to the old name of the glyph. The tables refer to glyphs by name rather than by direct reference. So traipsing through the tables, as the current code does, to find and change all the references to the glyph being renamed, is probably a necessary evil. But fixing it to only rename the one glyph means that then all the code that currently parses text strings to look for the glyph name to change, will have to be carefully rewritten to only detect references to that one glyph instead of "any glyph whose name contains the glyph name being changed." This means digging deeper than I would like to into code that really shouldn't exist at all.
If two glyphs share exactly the same name, it already is, but will continue to be very difficult to rename only one of them, because the code doesn't do "rename glyph 123 to 'bar'" but "rename the glyph(s) currently named 'foo' to 'bar'." Duplicate names may be forbidden anyway; I'm not sure. It doesn't appear possible to rename glyphs by index instead of by name when we're going through the substitution tables, because the substitution tables only store names and have no way to distinguish between different glyphs with the same name.