fontParts
fontParts copied to clipboard
robotools
Feature request: setStartPoint(pointOrPointIndex) – setStartSegment() is nonintuitive and not always helpful
FontMake Version 3.1.0 added a compatibility checker that suddenly blocked compatibility in several of my variable font projects, which led me to find that my start points weren’t as consistent as I had previously believed. It turns out that some of my start points were oncurves while others were offcurves, even though RoboFont only started highlighting this in Version 4.2.
I has hoped to find a quick way to fix this in a script, ideally with FontParts. However, FontParts only offers setStartSegment, which will set a contour’s start in a pattern of offcurve offcurve oncurve.
Visual example (Click to expand)
The existing setStartSegment behavior maaaybe makes sense if we are thinking about a first segment, if we consider a segment as beginning immediately after an oncurve point, and concluding with an oncurve ... though I do have to contort my thinking a bit to get there.
To me, a "start segment" would naturally start with an oncurve point as 0, and then any offcurves would increment from there, i.e. oncurve offcurve offcurve. This is reinforced by the natural method of drawing with any pen tool: you start a contour by clicking to make the first oncurve points, and each subsequent click completes a segment and begins a new one. (You could argue that the act of completing a segment is more important than the act of starting a segment, and there is probably a lot of background thinking in this realm that I don’t fully appreciate.)
That said, I propose one of two potential changes:
setStartSegmentcould use an oncurve as its start, though this may break old scripts or break segment logic that I’m unaware of- A
setStartPointmethod could be added. This would reflect the UI option in RoboFont and Glyphs, and it is the first thing I searched for when looking to solve my problem. This solution would be my preference, for what it’s worth.
More background
A RoboFont forum post – scroll to the end for a solution from Frederik.
A ScaleFast GH issue – here, Just asserts that interpolation systems shouldn’t be expected to make outlines compatible if some begin with oncurves while others begin with offcurves.
The logic of setStartSegment is that the segments.points are the first points in the contour, so for a curve segment that means off off on. Changing this is a big change that idd could break some logics in existing scripts.
A setStartPoint(pointOrPointIndex) could be a good option: from a UFO viewpoint a closed contour can start anywhere...
Historically there was never a setStartPoint(pointOrPointIndex) (robofabwise)
"start segment" would naturally start with an oncurve point as 0
I object: its postscript notation: a curve segment exists out of off off on and contains no points of the next segment.
Ah, that makes sense that it is tied to postscript notation. If I get a time machine, maybe I’ll go back and try to change that. 😄
A
setStartPoint(pointOrPointIndex)could be a good option: from a UFO viewpoint a closed contour can start anywhere...
Sounds good to me! Thanks for adding your insight here.
Just a +1 on this, as I also hit this problem today. Agree that setStartPoint(pointOrPointIndex) makes a lot of sense, as it would echo the “Set Start Point” RF menu option...
I permanently run into this. Although I understand the why, I would argue that it is completely unintuitive.
This is the script I use to fix (but sometimes I forget running it, which then again reminds me of this issue): https://gist.github.com/frankrolf/e75980e3895df26615cc8ed1e60f9c5b
same as above: changing contour.setStartSegment is a bad thing:
adding contour.setStartPoint where a script can set any point as starting point is fine by me, as contour.setStartPoint does not exists yet. I think it is good to have both options.
It’s a good thing this has been brought up again, because it gave me an opportunity to improve my script 😅