Angled handle snapping threshold

G2.4.2 [1060] OS X 10.10.5, UPM 2000, Grid Step 1 Subdivision 1.
Given a smooth node with angled handles which vary greatly in length, is there a threshold (in degrees) under which the longer of the two handles will NOT snap to another point on the grid in an attempt to become more congruent with the shorter handle angle in cases where changing to a straight (corner) node is not an option?

You mean a blue on-curve? Which cases are these?

I assume you are aware that there is no technical difference between green and blue nodes in the exported files.

You mean the longer should not snap to the big change in the angle do to the rounding of the shorter? That is an interesting problem.

When I have two adjacent on-curve green nodes and want to make one of them blue by removing a handle.

I should not have written that in my question; it only serves to divert attention away from the core question.

Yes I am. I also understand that Glyphs is making the angles congruent at some point because it is an on-curve green, which it interprets as required to be smooth regardless of the results. That is why I am wondering about a threshold.

Yes. In this particular case the problem is most evident while doing a connecting script with small rounded corners on the connecting strokes.

Why cannot you keep it blue then? That’s what I do in cases like this.

A number of times I have changed it to blue and at some point Glyphs changes it back. Not always though, and I haven’t tried to figure out in what circumstances it happens, but I intend to.

I’ve been trying to overcome the issue by ensuring the angles are as close to congruent as possible using your plugin (Show Coordinates of Selected Node), aiming for less than .5 degree difference.

One thing I wish your plugin didn’t do is show the length of the handles; the length numbers frequently interfere with the degree numbers.

[edit] I resolved the plugin problem of overlaying numbers by changing the color in the python code for the lengths to ‘clearColor’.

what happens if you move the short handle with the option key pressed?

Using the Option key works just fine on either handle or the on-curve node – I use it frequently. The problem usually becomes obvious when I do something to the entire outline such as removing overlap or moving the entire outline a unit or more. Sometimes it would happen if I did a copy-and-paste of an entire outline, but I’ve learned to avoid that one by making sure potential problem nodes are changed to blue before the action.

I’ve been thinking about this a lot today, and I think the issues I’m having are solely because of the nature of the design – the small round cornered connecting strokes. They are necessary because of the overall design though so it’s just something I have to deal with.

At this point I think using Rainer’s plugin as I mentioned above will be a big help in getting through this project because I can get a better match on the angles – .5 degree or less. The small amount of displacement then, if any, would not be noticeable in use.

Did you try to use corner components for those small corners?

No, because they are so variable; otherwise I would have. This is a somewhat casual/informal script.

[edit] Actually, I could have used them for the ends of the connector strokes; just didn’t occur to me to do it.

An edit or batch-edit can trigger it. One way to find out what happened is to keep a copy in the background with only blue nodes. Automatable.

I did have a copy of the entire font in the background for reference and backup.

Tests I did yesterday show there is a tolerance of a few tenths of a degree where Glyphs will not attempt any change to the angle of the longer handle. Not sure of the exact number although it is likely <1. It might be useful to restrict Glyphs when the difference is >1 too, perhaps as a user setting.