Cc @anthrotype @simoncozens

linesweeper inserts points for TT-style implied on-curve points

Skia does too, the TrueType style spline with implied oncurves only exists in font-land. Skia-pathops pen protocol adapter cleans them up afterwards

skia-pathops optionally keeps the starting points of contours

Similarly, that is also some extra code I added in the bindings, the underlying skia pathops module doesn't care about the starting points.

Ok, so if indeed the following features are not in scope for linesweeper:

• maintaining start points where possible
• keeping TT-implied-on-curve-points where possible

Then they could be a layer on top of linesweeper, or Fontra could deal with this itself (I'll check how skia-pathops does it).

I don't think they should be part of a binding per se, because Fontra would need this functionality whether it is using it via Python or via JS/TS/WASM.

Fontra could also deal with the desired winding direction.

What remains is the "sometimes outputs cubics when feeding it quadratics" issue: IMO that is a bug, but I'm not sure this is caused by linesweeper itself or by linesweeper-py.

Here's a reproducer for the cubic-for-quads problem:

import linesweeper
from kurbopy import Point
from fontTools.pens.recordingPen import RecordingPen


path = linesweeper.BezPath()
path.move_to(Point(0, 0))
path.quad_to(Point(0, 30), Point(15, 60))
path.quad_to(Point(30, 93), Point(90, 90))
path.line_to
path.close_path()

simplifiedPaths = linesweeper.simplify([path])

pen = RecordingPen()
for path in simplifiedPaths:
    path.draw(pen)

for command, args in pen.value:
    print(command, args)

This outputs:

moveTo ((0.0, 0.0),)
curveTo ((0.0, 20.0), (5.0, 40.0), (15.0, 60.0))
qCurveTo ((30.0, 93.0), (90.0, 90.0))
lineTo ((0.0, 0.0),)
closePath ()

The curveTo line is unexpected. (The behavior depends a bit on the actual coordinates: change the 93 to 90 and it outputs two cubics, despite the input being quadratic.)

I can't find the implementation of path.draw() in linesweeper-py, so perhaps this is indeed a pure linesweeper issue. Unless it's also out of scope to maintain the curve type.

@anthrotype, @simoncozens, can either of you advise me on the quadratics issue described above? My main questions at this point are:

• Is it linesweeper's goal to output quadratics when feeding quadratics?
• If it is, do you have an idea which (part) of linesweeper-py/linesweeper/kurbopy/kurbo could be responsible for the described problem? In other words, what would be a good place to open an issue?

It looks like linesweeper does raise the order (quad to cubic) while adding paths to its "arena", so I guess this is considered deliberate, rather than a bug.

@justvanrossum Could you summarize what issues remain? We could ask @jneem to take a look.

I'm not sure there are any real issues, except that I'm missing some functionality that seems to be outside the scope of linesweeper. What I need can be implemented on top of linesweeper, but if I could ask for a single feature it would be "output quadratic segments for quadratic input segments instead of raising the order".

but if I could ask for a single feature it would be "output quadratic segments for quadratic input segments instead of raising the order"

That's definitely in-scope (I'll open an issue for it), but I don't have an ETA

That's definitely in-scope (I'll open an issue for it), but I don't have an ETA

That's great! Thanks for the head-up.