New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the auto glyph renaming feature. #523

Closed
ahyangyi opened this Issue Apr 8, 2013 · 8 comments

Comments

Projects
None yet
4 participants
@ahyangyi
Contributor

ahyangyi commented Apr 8, 2013

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.

@mskala

This comment has been minimized.

Member

mskala commented Apr 8, 2013

I'm not sure if this is really related to renaming, or selection - maybe selecting a glyph with a name like "foo12" also selects "foo123" - but either way, I agree, it's really annoying and shouldn't happen.

@mskala

This comment has been minimized.

Member

mskala commented Apr 8, 2013

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:

# create a font with three empty glyphs named foo, foo.a, foo.b
New();
SetCharCnt(0);
SetCharCnt(3);
Select(0);
SetGlyphName("foo");
Select(1);
SetGlyphName("foo.a");
Select(2);
SetGlyphName("foo.b");
# show the names of all glyphs before renaming
SelectAll();
foreach; Print(GlyphInfo("name")); endloop;
# select just the first, and verify that it is the only one selected
Select("foo");
foreach; Print(GlyphInfo("name")); endloop;
# rename it.  all three glyphs are renamed.
SetGlyphName("bar");
SelectAll();
foreach; Print(GlyphInfo("name")); endloop;
@mskala

This comment has been minimized.

Member

mskala commented Apr 8, 2013

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.

@JoesCat

This comment has been minimized.

Contributor

JoesCat commented Apr 8, 2013

Khaled has this solution. See if this meets what you are looking for. Please merge if you find it good.
#524

@JoesCat

This comment has been minimized.

Contributor

JoesCat commented Apr 12, 2013

Hi @ahyangyi,
@mskala created #532 which is now pulled into mainline code.
I think this solves your issue - if yes, we can then close this issue.

@ahyangyi ahyangyi closed this Jun 25, 2013

@davelab6

This comment has been minimized.

Member

davelab6 commented Jun 25, 2013

Thanks @ahyangyi

@davelab6

This comment has been minimized.

Member

davelab6 commented Jun 25, 2013

And thanks to @JoesCat and @mskala for resolving this issue!! :D

@ahyangyi

This comment has been minimized.

Contributor

ahyangyi commented Jun 25, 2013

Sorry. Should close it much earlier but forgot that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment