Copy anchors proportionally option

[tiroj]

I have been very grateful for the existence of the Copy Anchors tool. Looking at a project today, it struck me that it would be useful to have an option in this tool—or maybe a separate script?—to copy and paste anchor locations proportional to the advance width. In some Indic scripts, there are a lot of marks that are optically positioned relative to the bases following rules that take into account the shape of the base glyph; this typically means that when these bases exist in different weights, widths, etc. or even in different typefaces, the anchors for these marks tend to be in similar positions relative to the advance widths of the bases. It would be helpful to be able to copy anchors from one master and paste them in another master with their positions adjusted proportionally to the advance widths of the target master.

[kateliev]

@tiroj great idea! It is now done, just pushed. This adds a new radio group that lets you select between absolute and relative positioning of the anchor.

The relative horizontal positioning is done as proportion of the glyphs advance at the layer of interest. The vertical location is still fixed (absolute). In my opinion it would be a nice to have that relative as well, but the question remains relative compared to which dimension - contour's bounding box (top) or one of the font metrics (x-height or caps height). I am very much open to suggestions - let me know if that sounds reasonable to you and which dimension do you see fit for the job.

Also you could use the tool to propagate the anchors from one layer to another within the same font by just selecting the desired layer pairs in the combo boxes. For now this works only in one by one mode - let me know if this feels bit awkward to use - could think of some UI fix.

[tiroj]

I had not considered vertical positioning. I think being able to specify a metrics height or possibly an explicit unit height would be useful. I can imagine, e.g. using this to copy cap height anchors to smallcap height anchors, although that would imply something like a copy from-and-to selection within a layer.

[kateliev]

@tiroj will think of some solution, but until then please let me know if the current script working for you.

[tiroj]

I’ve not had an opportunity to test it yet, but will try tomorrow.

[tiroj]

I am trying to test the new relative anchor positioning copy option within a single VFC file, to copy from one master to another, but I am running into a problem with the master layers not being correctly listed, even though I have clicked the button to update the list. The actual master layers in this source file are Light and Bold, but this is what I get:

[tiroj]

If I select the ‘Regular’ master from the Source Layer list, and then click the Copy Anchors button, FL8 crashes.

[kateliev]

@tiroj very strange, will investigate...

[kateliev]

@tiroj regretfully cannot confirm any of the above problems. Works as expected on both Mac ans Win - tested various scenarios - no problems whatsoever. Please let me know if you resolved the situation in any way. Also could you try another typeface after restarting FL just to confirm that the script is the one that is crashing the app.

[tiroj]

Still having the same problem, with a different font, after restarting FL8. As you see: the script dialogue is only reporting the presence of one ‘Regular’ master in both the Source and Destination Layer, not the two masters that are actually present in the font:

This time, FL did not crash when I clicked the Copy Anchors button, but the anchor of the Regular master was copied onto the Regular master, resulting in a .bak copy of the anchor. It was not copied to the Bold master.

I tried again with Regular master selected in the Source Layer and All Masters in the Destination Layer, and this crashed FontLab.

[As a general comment, I had a lot of trouble getting TypeRig to work in FL8: it seemed much more complicated than the FL7 install, and for a long time I was getting error messages any time I tried to activate the TR UI panel. I finally got that working—although I can’t remember exactly how—and the path seems to be to where I have the TR repo synced via git.]

[kateliev]

Hmm that is really strange. Still cannot confirm. Did some tests and really believed that the problem should be at my side, but... the script is really robust and simple - very little could go wrong. Could you please share what version of FL8 are you using. If i have that build in backup would love to try that. Also if you feel like we need to dig deeper you could send me a copy of the font (or subset) and an NDA to vassil(at)kateliev(dot)com

Just a note about working in All Layers mode - it will only copy anchors from font A to B if both fonts have the same layer (by name)

[tiroj]

I am using FontLab version 8.0.1.8249, which I believe is the most recent, with Python 3.10.1.

As a test, I used the default ‘All masters’ setting in both the Source and Destination Layer, with Relative positioning set, expecting that I would get a .bak duplicate anchor in both masters but that the new anchor in the Bold master might be set to a proportional location relative to the advance width based on that in the Regular master. But instead I just got the .bak duplicate in the Regular master. It is as if the script is only ever able to see the Regular master (even if that master doesn’t actually exist, as in the original test font).

[kateliev]

Well I am currently running 8.0.2.8407 WIN from two weeks ago using Python 3.10.6. Will downgrade to your version and test again. If that is not the issue, then i am really puzzled...

[kateliev]

Hmm... nope it is not Fontlab... I am running out of ideas. Can you confirm that the script was working before. Judging by your comments i believe it did! Perhaps it is some TR version mismatch core to GUI although it makes little sense as the anchor part of the core lib has not changed at least by an year.

Also one more question - are these anchors using FL recipes?

[tiroj]

Hmm. I don’t remember whether I ever ran the previous version of the script in FL8. I definitely used it in FL7.

I just tried running some of the other TR tools scripts, and see the same problem with Layer identification—only ‘Regular’ shows up—in the Copy Layers 1.7 script. Also, trying to use that script to copy layers to a new FL font crashes the program.

So then I tried Rename Anchors 1.2, which exhibited the same problem with Layer identification, trying to run the script with these settings failed:

But at least the program did not crash and this time I got an error message:

Traceback (most recent call last):
  File "<string>", line 73, in <lambda>
  File "<string>", line 144, in action_rename_anchors
TypeError: '>' not supported between instances of 'set' and 'int'

I am wondering if the problem could be somewhere deeper in my TR installation? As I mentioned, I had trouble getting the TR panel to work at all in FL8, and the installation process did not see straightforward: I basically tried all the install options until one of them seemed to work. But perhaps it is messed up and some needed components are missing?

---

The anchors are not using FL recipes.

[kateliev]

Ok, let's start from the beginning. Please download this tool. Drag (or open) it to FL as if it were a font file (same as the installer).

Download link: diag.vfpy

Save the core component version log (*.json) and post it here. If you are concerned about your privacy please send it to [email protected]

[tiroj]

I get an error message when I drag the diag.vfpy file into FL8 (Mac):

  File "/Users/tiro_j/Downloads/diag.vfpy", line 72
    
                                       ^
SyntaxError: invalid character '·' (U+00B7)

[kateliev]

Hmm this is strange, working as expected on my Mac:

Did you download the above link as RAW as there is(was) nothing on line 72.

My point - yes i know it breaks, just found out while testing on Mac :) But it does not fail upon load/open but rather while running the component tests. This happens because there is a widgets.py component module that is having a unicode character ° on one of its transformations controls that was introduced a month ago and the file lacked the proper encoding header... in conjunction to that my diag.vfpy tool was not loading the files in UTF8 but in ASCII thus failing to read the above mentioned component. But all of that was a bug you should have encountered later - I am glad that it is now fixed along with the widgets.py.

In short please try again, with the updated diagnostics tool and this time try with File>Open not dragging to see if that helps...

[kateliev]

PS the new diag tool version should be 1.3

[tiroj]

Diagnostic tool working now. Will email .json

[kateliev]

Ok, from what i saw in that .json:

• you have installed TR as i always recommend - Git synched with a link to the FL - this is the best option;
• you have all the latest components and i do not see why shouldn't you, having in mind the above statement;

So you did good installing TR and i see no reason for it to not work as expected! Which leaves me even more puzzled what could be wrong with the script.

[kateliev]

@tiroj just pushed some updates to Copy Anchors tool. Now it has buttons for refreshing the current open fonts list.

I did some testing, opening or closing fonts while the script is running without proper font list refresh could have been one of the main reasons for the app crashes you experienced. The missing layers are still puzzling, but perhaps updating the fonts and all other associated data in memory could force that to work as well.

Also added some special functions that refresh the fonts globally because FL uses some heavy optimizations - huge font files are only partially unpacked upon load. Thus one might find nodes and whole layers reported as missing to Python api. I have no idea how big the file you are trying to modify is. On 10k+ glyph file i currently work on there are definitely problems with these optimizations! Just a tip Hitting "Font> Update glyphs" helps a lot before global font operations!

[tiroj]

I pulled the script update. Restarted FL8. Opened a VFC source. Ran script. Noted you tip and selected all glyphs and hit Update Glyphs from the Font menu (never done that before; no idea what it does). Then hit the << button next to Source Layer to see whether the layers were being correctly enumerated. FL8 immediately crashed.

Tried again, this time hitting Update Glyphs before running the script. This time FL8 did not crash when I hit the << button to refresh the Source Layer list, but the result was still that only the Regular master is listed. Set options to copy from Regular to All Masters, with position set to Relative. Clicking ‘Copy Anchors’ then crashed FL8.

[kateliev]

Well i am really running out of ideas. Just to satisfy my curiosity, i've just sent you an email containing download links to the latest FL build i have. Please try that when you have the time and see if the scripts work there. Thanks!

[kateliev]

@tiroj any luck with the latest FL builds and the script?

[tiroj]

Sorry, I have not had opportunity for further testing. I am on a push for a website launch this week.

[tiroj]

Good news: TypeRig scripts are no longer crashing FontLab now that I am running FL 8.2.0.8620 on Mac OS Ventura 13.4. Hurrah!

I have successfully used the Copy Anchors 2.0 tool to copy anchors from one font to another, and from one layer of one font to another, using both Absolute and Relative positioning.

I occasionally get flakey behaviour, e.g. the script reporting that the source glyph is not found, even though it is selected, but it works if I restart FontLab and run the script again.

I did get this error message when (accidentally) running the script with the All Glyphs setting instead of Selected (rnning the script just on the /lambda glyph worked fine):

Traceback (most recent call last):
  File "/Users/tiro_j/Tresorit/Fontlab/Scripts/TypeRig/Scripts/TypeRig Tools/TR-CopyAnchors.py", line 57, in <lambda>
    self.btn_copy_anchors.clicked.connect(lambda: self.action_copy_anchors())
                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/tiro_j/Tresorit/Fontlab/Scripts/TypeRig/Scripts/TypeRig Tools/TR-CopyAnchors.py", line 305, in action_copy_anchors
    location_prop = tmp_anchor.point.x()/src_glyph.getAdvance(layer_source)
                    ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ZeroDivisionError: float division by zero

It is unnerving that when I run the script of Selected glyphs, all the glyphs in the font get the grey overline in the Font window indicating that they are modified, even though it seems only the Selected glyphs have actually been modified.

[tiroj]

FL8 is no longer crashing when I try to run this script, but it does become unstable afterwards. If I close the VFC tab of the source anchors after copying them with the script, FL8 crashes.

[kateliev]

Good news: TypeRig scripts are no longer crashing FontLab now that I am running FL 8.2.0.8620 on Mac OS Ventura 13.4. Hurrah!

Very glad to hear that :)

I occasionally get flakey behaviour, e.g. the script reporting that the source glyph is not found, even though it is selected, but it works if I restart FontLab and run the script again.

It very much depend of the situation. Because you jumped a few versions of FL some app behaviors might seem strange to you. At some point FL switched from "full file loading" to "lazy file loading" thus on file open sometimes not the "whole" font is actually "loaded". For example if you open the app and load a fresh font and try to run a script on it the script might report some glyphs missing or incompatible layers. To fix that it is advisable to run Font > Update Glyphs before running scripts that do font wide changes on freshly opened files. This is the case especially with large fonts... but will rarely happen with small ones ... It all depends on the project. For instance I am currently working on a 13K glyphs font with 17 masters - this happens to me all the time :)

I did get this error message when (accidentally) running the script with the All Glyphs setting instead of Selected (rnning the script just on the /lambda glyph worked fine):

No, unfortunately this has nothing to do with the /lambda glyph, Long story short in programing lambda is just the term of unnamed function. The actual error is division by zero, will modify the script to not halt on such errors...

It is unnerving that when I run the script of Selected glyphs, all the glyphs in the font get the grey overline in the Font window indicating that they are modified, even though it seems only the Selected glyphs have actually been modified.

This is possibly doe to the script updating the font as a whole instead of doing it glyph by glyph. This is mainly to speed up the process, will check it out and modify it if needed...

FL8 is no longer crashing when I try to run this script, but it does become unstable afterwards. If I close the VFC tab of the source anchors after copying them with the script, FL8 crashes.

Sounds bizarre. Will investigate, but sounds more like a FL thing than a Python/TR related problem.

[kateliev]

@tiroj the tool has now been updated to reflect the following:

• Per glyph update mode: This allows only modified glyphs (not the whole font) to be actually updated in "Selected glyphs" mode as requested above;

• ZeroDivisionError fix: It seems that the error you were getting is due to some layer having zero advance width. It is entirely possible for one to have such glyphs/layers, but presents an unfortunate mathematical complication while trying to get the anchor position in relation of layer advance width :) It is now fixed so that the script will fallback to absolute positioning for such cases and also report the issue. PS it also might be due to "lazy" loaded font as described above...

Please try the fixes and let me know what you think.