[cubic-glyf] drawPoints and all-offcurve

[behdad]

Currently Glyph.drawPoints with a cubic all-offcurve contour generates something like this:

            ("beginPath", (), {}), 
            ("addPoint", ((103, 181), None, False, None), {}), 
            ("addPoint", ((125, 158), None, False, None), {}), 
            ("addPoint", ((125, 104), None, False, None), {}), 
            ("addPoint", ((103, 82), None, False, None), {}), 
            ("addPoint", ((48, 82), None, False, None), {}), 
            ("addPoint", ((26, 104), None, False, None), {}), 
            ("addPoint", ((26, 158), None, False, None), {}), 
            ("addPoint", ((48, 181), None, False, None), {}), 
            ("endPath", (), {}), 

which nowhere says cubic!

How should we resolve this?!

[behdad]

Should we add a curve point with None coordinates?

[anthrotype]

Should we add a curve point with None coordinates?

hm yeah, that would match the treatment of oncurve-less quadratic closed contour in the segment pen protocol (pen.qCurveTo((0,1), (2,3), (4,5), ..., None)).
But it would also break existing code that expects to be able to unpack the first argument as a (x, y) tuple.
I guess it's acceptable given that the existence of cubic contours with implied on-curves is a novelty. The UFO GLIF spec still only mentions that "curve" type segment can only be preceded by max 2 offcurves (unlike qcurve which has no such limit).
I wonder if, for consistency, we should also emit qcurve point with a None coordinates when a glyf contour only comprises quadratic offcurves? Maybe not, given the much higher risk of breaking existing tools.

An alternative solution might be to define an new explicit point type that describes a cubic offcurve point as opposed to the currently undefined "offcurve" type (which is actually a None value, given that an offcurve has no segmentType of its own, but it is supposedly qualified by an oncurve that comes after it... but some contours may have no on-curves hence our problem!)

[justvanrossum]

An alternative solution might be to define an new explicit point type that describes a cubic offcurve point

Not bad. Another idea would be to add a kw arg to beginPath() that specifies the curve type for oncurve-less contours.

[anthrotype]

add a kw arg to beginPath() that specifies the curve type for oncurve-less contours

actually I think I like this option better. We only need to disambigate the curve type when there are no oncurves in a contour. The default can stay quadratic for backward compatibility.
Only problem with this approach is that one can't unconditionally beginPath and emit each point before knowing in advance whether the contour in question contains any oncurves at all, as that will be known only after reading all the points. Maybe that's ok. endPath could also have kwargs... 🤔