After interpolation or extrapolation points can behave a little strange (see image) and you have to ”touch” them in order to make the path and contour “alright” again. Is there a quick way to do this on ALL glyphs instead of browsing through them manually?
The only proper way is to properly set up the masters. Read the section about ”Avoiding Kinks“ https://www.glyphsapp.com/tutorials/multiple-masters-part-2-keeping-your-outlines-compatible
I’ve found Remix Harmoniser to be a quick start.
Yes, but this was extrapolated, and after that it was slanted.
Thanks, I try Harmoniser and see what happens.
The RMX Harmonizer can also be used only to dekink. Note that this can be used as a custom parameter on export. The little gear menu allows you to copy the filter string, then simply paste it into the instance’s custom parameters.
Tim, that sounds interesting! Sorry, but what’s a filter string and how exactly do one copy this in the instance’s custom parameter? 
Thanks!
To copy the filter string, use the gear menu:
Then paste it in the Font Info using Cmd+V (you need to click into the Custom Parameter area first):
2 Likes
Thank you! Will give this a try!
@TimAhrens, is it possible to apply the RMX dekink filter to a specific glyph as a custom parameter?
Try to add ;include: A, B, at the end of the filter code
1 Like
I exported an instance with a custom Parameter with RMXHarmonizer;dekink, and I noticed it move the actual node, instead of just the handle/s. Is this intended?
The algorithm for dekinking is rather complex. The intention is to retain the original shape (i.e. the shape with kink) as closely as possible while removing the kink. Then, you have to make a distinction between smooth nodes that connect two curve elements, and those that connect a straight segment and a curve.
Generally, both the node and the BCP(s) are move a bit (in opposite directions) so as to minimize the overall deviation from the original. In the case of staight-curve connections, the node is only moved if there is a significant kink (otherwise, only the BCP). In that case, the node is moved along the bisector (of the two directions) onto the new tangent. If we only moved the BCPs, i.e. prioritize the interpolated direction of the straight then we can get weird results. Since the connection from the “far” node to the BCP is longer (the sum of the straight and the handle), its direction tends to be closer to what the designer intended.
Oh, and while we are doing all this we are usually rounding the co-ordinates, trying to find integer coordinates that, again, resemble the original/intended shapes as closely as possible.
Phew. Hope this makes sense, or at least demonstrates that the current behaviour is the result of a lot of hard work and thinking, trying to get the best possible result an automatism can achieve. Moving the nodes is not an unintentional slip but part of the dekinking-fitting-rounding mechanism.
If you experience significant kinks in the interpolations I would recommend to tweak the masters a little, adjust nodes and/or BCPs a little so as to make the length relationships more similar.
3 Likes
Thank you Tim: Your logic is perfect, and I understand why a node may have to move.
Let me just make the distinction: I’m only talking about a straight-curve connection here.
In the picture attached you can see the outline with the kink on the background layer, and the RMX dekinked outline on the foreground. On the dekinked outline the node was moved 1 unit to the right, while the BCP stayed at the same place. My ideal would be to move the BCP 1 unit to the left, and leave the node at the same position.
To explain it:
-
It’s a minor kink. My master outlines were made to avoid kinks: I made the line/handle promotions the same in all masters (or very close), but still of course there are minor kinks due to coordinate roundings. This is one of them.
-
The straight line is a lot longer than the handle (about 4 times longer) so I would imagine the angle of the line would have priority.
it’s possible that the RMX is already doing the right thing and this is just an unfortunate rounding case. Anyway I think that the version 1.0 beta 26 (I had it running before) was doing what I wanted in this case, it moved the BCP only.
Many thanks!
Rui, it is possible that the shift of the node is related to the rounding of the co-ordinates, which is performed along with the rounding. If you could send me the .glyphs file (the multiple-masters source, maybe only the glyph in question) then I can have a closer look to understand what is going on.
Tim,
I emailed you the a Glyphs file with only the interpolated w.
I think that if you are measuring the angle from the far point to the BCP, it’s natural that the node moves, in this case. Because the handle is so short in relation to the line, if in the interpolation the BCP gets rounded to the left or to the right (and not the node) that actually is a great change of the angle, a change that will force the node to move.