Add glyph-level genericGlyphChange (same as UI "Change Glyph ...")#4133
Add glyph-level genericGlyphChange (same as UI "Change Glyph ...")#4133ctrlcctrlv merged 1 commit intofontforge:masterfrom
Conversation
|
It worries me vis à vis #4078 to add more code that doesn't seem to have been tested on multilayer fonts. Did you do tests on the font in that PR? |
|
I did not test on those fonts. However, the pattern of the code follows the usual pattern of applying to the currently selected layer, which is how almost all of the glyph-level methods work (when they affect contours). |
|
I notice the use of |
|
I can, but if you scan up the old code you'll see that's part of the current font-level call as well -- it just wound up being moved in the process of isolating the parameter parsing. |
|
They both work. You have to set Of course, the way Change Glyph works makes good results unlikely because the output depends on the relation of the contour shape to the font metrics, which is likely to be different for different layers in a multi-layer font. |
|
Thanks, sorry to bother you. Hopefully you understand the reasons behind my concern :-) |
|
Given that the methods depend on the layer value it's a reasonable test to run. |
The oft-requested (but already possible) "Change Glyph" Python API, but on the glyph object to avoid having to use the selection interface. Uses the same parameter parsing logic as the old command, moved to a separate function
The main annoyance with the API compared with the UI is the lack of a default
vMap. The dialog VMap is based on the BlueValues (when those are present). However, thefont.privateobject has these available in a tuple, so if that's what the user wants they're not too hard to build.Closes #2925