Stemhist: Unhandled case for first and last points in outline

[typoman]

I'm running stemhist on a UFO file which produces an output when it encounters a composite and it stops.

Checking space.
Checking A.
Checking Agrave.
Checking Aacute.
Checking Acircumflex.
Checking Atilde.
Unhandled case for first and last points in outline '<contour>
<point x="211" y="774" />
<point smooth="yes" type="curve" x="254" y="774" />
<point x="305" y="774" />
<point x="346" y="819" />
<point type="curve" x="354" y="890" />
<point type="line" x="294" y="890" />
<point x="289" y="864" />
<point x="273" y="845" />
<point smooth="yes" type="curve" x="254" y="845" />
<point x="225" y="845" />
<point x="189" y="888" />
<point smooth="yes" type="curve" x="147" y="888" />
<point x="95" y="888" />
<point x="54" y="843" />
<point type="curve" x="46" y="772" />
<point type="line" x="106" y="772" />
<point x="111" y="798" />
<point x="127" y="817" />
<point smooth="yes" type="curve" x="146" y="817" />
<point x="175" y="817" />
</contour>
'.

I can't make out what this means: Unhandled case for first and last points in outline and also there is no infomation anywhere to describe it. The wierd thing is that there is no such point structure if I search it through all the ufo glyph files. Could you direct me on what this means and how can it be fixed?

[frankrolf]

This seems to come from https://github.com/adobe-type-tools/afdko/blob/1d4f78d459dbcfd57f03496cb9509c37d6e09372/python/afdko/ufotools.py – possibly you found a bug.

[frankrolf]

Hi Bahman, thank you for sending over the UFO file.
The glyph triggering the output above is tilde.uc, the point x="211" y="774" exists within it.
The interesting part – 211 774 is actually an offcurve point, but saved in the XML as the first point of the tilde-contour.
While the UFO spec does not explicitly forbid this, I have not seen the starting point of a contour be anything else but an oncurve point. I am fairly certain this is a requirement for a PostScript contour too – hence autohint, stemHist etc. failing.

A workaround:
reassign the start point to be the first oncurve point.

[frankrolf]

A note for ufotools – perhaps it would be smart to detect such cases and automatically shift all points of the affected contour by 1.

[typoman]

Thank you Frank for finding the issue. Maybe @schriftgestalt should see this issue, the UFO was exported from the Glyphs app.

[schriftgestalt]

I try to not mess with starting points. Otherwise people complain about unnecessary differences.

As long as it is in the spec I tend to keep it like that.

[frankrolf]

I don’t think you fully read through the issue here Georg. Glyphs apparently is able to set start points on offcurve points, which literally is “messing with starting points”

[schriftgestalt]

The start point happens to be like that. And Glyphs just kept it.

[frankrolf]

The UFO file itself is point structure-agnostic, meaning it is OK to start with an off-curve point.
Action item for UFOtools:

• detect nature of outline and warn rather than fail
• possibly shift point structure and inform user

[khaledhosny]

Can some one try this with psstemhist from psautohint?

[frankrolf]

psstemhist test\ BETA-Regular.ufo
ERROR: tet-hb: Check for duplicate subpath at 107 0.
ERROR: shin-hb: Check for duplicate subpath at 105 0.
ERROR: shinshindot-hb: Check for duplicate subpath at 105 0.
ERROR: shinsindot-hb: Check for duplicate subpath at 105 0.
ERROR: shindageshshindot-hb: Check for duplicate subpath at 105 0.
ERROR: shindageshsindot-hb: Check for duplicate subpath at 105 0.
ERROR: tetdagesh-hb: Check for duplicate subpath at 107 0.
ERROR: shindagesh-hb: Check for duplicate subpath at 105 0.

works

[miguelsousa]

@khaledhosny do you know if some sort of point reordering happens behind the scenes to get this to work in psstemhist?

[khaledhosny]

The code in question was replaced by a BezPen, and I vaguely remember FontTools pens taking care of re-ordering the points.

[miguelsousa]

I'll have a look. Thanks