SOLVED Why are some start points becoming "2"? How might I fix it efficiently?
The above is a simplified UFO with one glyph.
If you prefer just the .glif XML:
<?xml version="1.0" encoding="UTF-8"?> <glyph name="o" format="2"> <unicode hex="006F"/> <advance width="1262"/> <outline> <contour> <point x="308.7858439201" y="1102"/> <point x="93" y="883"/> <point x="93" y="536" type="curve" smooth="yes"/> <point x="93" y="189"/> <point x="308.7858439201" y="-28"/> <point x="631" y="-28" type="curve" smooth="yes"/> <point x="953.2141560799" y="-28"/> <point x="1169" y="189"/> <point x="1169" y="536" type="curve" smooth="yes"/> <point x="1169" y="883"/> <point x="953.2141560799" y="1102"/> <point x="631" y="1102" type="curve" smooth="yes"/> </contour> <contour> <point x="789" y="841"/> <point x="868" y="731"/> <point x="868" y="536" type="curve" smooth="yes"/> <point x="868" y="341"/> <point x="786" y="233"/> <point x="631" y="233" type="curve" smooth="yes"/> <point x="476" y="233"/> <point x="395" y="341"/> <point x="395" y="536" type="curve" smooth="yes"/> <point x="395" y="731"/> <point x="473" y="841"/> <point x="631" y="841" type="curve" smooth="yes"/> </contour> </outline> <anchor name="top" x="630" y="1072"/> <anchor name="ogonek" x="810" y="0"/> <anchor name="bottom" x="631" y="-28"/> <guideline x="631" y="102" angle="90" color="0.999,0.001,0.001,0.39962" identifier="wGX5S9dabk"/> </glyph>
In the above GLIF code, both contour is messed up, but each contour should begin with one of the
<point x="93" y="536" type="curve" smooth="yes"/> <point x="93" y="189"/> <point x="308.7858439201" y="-28"/>
the short answer: this is clarified in the upcoming release
(this link will be gone in a few days, since the release is close)
The start point and the symbol to indicate the direction are not the same. In a UFO a contour can start with an off curve or an on curve and still represent the same visual contour:
# 3 times the same contour off off curve line line off curve line line off curve line line off off
The first on curve is not always the starting point. This was never a problem since fontMath does calculations nicely between different point structures. Other tools aren't so nice and choke.
RoboFont 4.2 has two symbols: one for the starting point and one for the direction (the direction is always highlighted on a on curve point)
hope this make sense!
Excellent; thanks for the helpful explanation, Frederik! That’s a really nice documentation page.
Do you know if there’s a fairly direct way to set the oncurve as the start point, in a Python script?
I am still interested if there is a programmatic way to set a specific oncurve start point, as asked above.
However, I may be facing this problem because FontMake added a new compatibility checker in v3.1.0, and this checker may be overly strict.
ArrowType last edited by ArrowType
If anyone (including my future self) comes along looking for a semi-manual solution, here’s a better one that what I listed above.
- Open all the fonts you wish to check.
- Run the following Python in the Scripting Window:
for f in AllFonts(): print(f.info.styleName) glyphsToCheck =  for g in f: for contour in g: pointCount = 0 for segment in contour: for point in segment: if pointCount == 0 and pointCount+1 != point.index: if g.name not in glyphsToCheck: glyphsToCheck.append(g.name) pointCount += 1 print(" ".join(glyphsToCheck),"\n")
This will print out a list to the console, like this:
Text Ultra Italic eight registered Text 200 Italic thorn b a.italic question six d nine oe a p o copyright ringcomb g q Text Hairline Italic nine.dnom a.italic OE.RECT O.sups degree O d five.dnom five.onum S five three.dnom s zero.dnom question o.sups partialdiff S.sups copyright thorn infinity dollar.open eth six eight zero q b eight.dnom Ohorn.RECT g C OE p six.hiviz s.sups ampersand Omega five.tnum section six.dnom_hiviz dollar registered O.RECT zero.onum o six.dnom
Then, you can "create a new set from glyphs names"
Copy and paste in the glyph names, then label it with a name like "temp" or "corrections":
This then makes it relatively fast to go through all the affect glyphs, using a shortcut to set the start point, then the shortcut to move to the next glyph in the font view
Once you finish, you can then delete the set.
I’m guessing there is a faster way to fix this, and it would probably be worth finding if you had many sources to fix... but for a small number of fonts, this is pretty quick.
setting the starting point with fontParts results in
off off curvestart structure
# assume a glyph with 2 ovals g = CurrentGlyph() # setting the start segment for the first oval # the result will be a off curve as first point g.setStartSegment(1) # setting the start point on the oncurve # get the contour object contour = g # create an empty list for all the point data points =  hasOncurve = False # start looping over all the points in the contour for point in list(contour.points): if point.type != "offcurve": hasOncurve = True # store the point data points.append(( (point.x, point.y), point.type, point.smooth, point.name, point.identifier )) # remove the point from the contour contour.removePoint(point) if hasOncurve: # start a while loop and check the first point type # only start the loop when there are on curve points while points == "offcurve": # pop the first point point = points.pop(0) # and add it to the end points.append(point) # add all newly arranged points into the contour for position, type, smooth, name, identifier in points: contour.appendPoint( position, type=type, smooth=smooth, name=name, identifier=identifier )
There is a complete api to set and edit and manipulate smart sets!!
- you can set a query direclty in font window, handy for fast searches and temp sets:
from mojo.UI import CurrentFontWindow w = CurrentFontWindow() # set a list as a query directly in the font collection w.setGlyphNamesAsSet(["A", "B", "C"])
frankrolf last edited by
Here is a script which you could potentially wrap into an observer: https://github.com/roboDocs/ScaleFast/issues/5#issue-499348737
I’ve made an issue in the FontParts repo to request a simpler way to set start points:
ArrowType last edited by ArrowType
For some reason, Frederik’s script wasn’t quite solving this ... It worked on one contour, but messed another one up newly.
In the above example, the start point was an oncurve, and this script moved it one up, to the following offcurve. Running the script again moves it to the next offcurve after an oncurve, so running it many times makes the start point rotate around the contour. It did seem to work as desired on the other contour of this glyph, though.
Luckily, Frank’s script worked perfectly, for a full UFO! So, for now I will just accept that I have a solution, and will try to properly understand that after some immediate tasks. I just wanted to update this post in case that helps others.
the example script shows two different approaches: one is the fontParts
setStartSegmenton the first contour and an other approach on a second contour
You will need to combine and rearrange into a working script.
dberlow last edited by
@frederik I think a good question here is why cubic to quadratic conversion moves the start point from an on-curve where it starts in the cubic, to the preceding off curve point where it sometimes ends in the quadratic. We can only hope that symbols for where the contour starts and what direction it’s going, never become two places, after 40 years of being one.
With UFO the starting point (first point in the contour list of points) is not always a on curve point. As a UFO just makes a loop.
The symbol for direction of a contour looks very strange when its attached on a off curve point. So yes after 40 years being one, you'll have two now!
This change in the recently in RF4.2. And is important to visualise the data correctly.
The conversion between quad/cubic should maintain the startpoint if it was an on curve. (an issue to fix is being made)