I found a way to speed up the brute force approach though. If you can use external Python modules: from scipy import spatial tree = spatial.KDTree(t_list) # t_list is a list of pre-calculated point coordinate tuples on the cubic curve distance, index = tree.query(pt) # pt is the given point coordinate tuple t_for_pt = float(index) / (len(tree.data) - 1) t_list must be constructed in a way that the first entry is for t = 0 and the last entry for t = 1. It doesn't matter how many points for increments of t you calculate, as long as the index in t_list is proportional to t. Smaller increments of t increase the precision of the result, but the list takes longer to build.

mmm, not directly from the robofab objects but you could use the naked object g = CurrentGlyph() # remove the first segment from the first contour g[0].naked().removeSegment(0, preserveCurve=True) good luck!

Perfect, it works. Thanks!

hi I was wondering if there is a way to join two (open) contours with a script. E.g. join last point of contour A with first point of contour B. If I select these points in the glyph-view and click on "Close/Join Open Contours" this works. Is there also a scripting-based way to do that? thanks, jo

Thanks, that did it! :)

Thanks Jo, a drag is needed to prevent accidentally adding bcp's

Did some tests and this issue is already solved. It will be in the next update.

(oh a thread that slipped thought my fingers) this is indeed a bug, will be fixed in the next version thanks

the "Smooth point color" is the stroke color of a point when its smooth

The problem starts of course when there is more than one open contour… But basically I don't care when RF fucks it up in those cases (you do), if it already works with 1 hotkey and 1 open contour it would be an improvement already.

I agree with you guys. My way of drawing involve a lot of "add extreme points + cleanup" method, and it is… painful to work like this in RF. Just a suggestion: on removing a point, maybe the opposite handle should be kept as is, at least? If recalculation of curve is hard, I don't see a reason why both handlelength should be affected. Am I clear? (and yes, FLS' "optimize" algorithm performs well)

send it to me :) thanks

It true that scaling would result in floating coordinates. But I would rather see advantages in keeping the coordinates with floating numbers. If one has a set of transformations the result would be much better if floating numbers are used instead round the coordinates after each step. use glyph.round() Output will always round all coordinates.

Well, in this case I don't need it (thought shouldn't it work?) I didn't find glyph.removeCountour() in robofab's documentation :[ Thanks!

mm, you can make a subclass of the EditTool and overwrite the modifyDraggingPoint(point, delta) method to ignore 45° and only look for 0° and 90° angles. But not pref settings (yet, will think about it)

You rock!

the outline selection ability disappears when a big zoom-out view is active: you can still use the keyboard, but click-select and drag is not possible because outline view is simplified :(

great! thanks

command + c --> cutting segments out alt + del --> breaking contours on the selected points

This case is unfortunately a consequence from FLS. Superposed nodes: when deleting one of them, the remaining one should inherit the handle length. Instead, a new curve is calculated and differs greatly.