Calling BezPath::close_path infallibly adds a PathEl::ClosePath, leading to buggy behavior

[ctrlcctrlv]

kurbo/src/bezpath.rs

Lines 211 to 214 in b9247ed

	/// Push a "close path" element onto the path.
	pub fn close_path(&mut self) {
	self.push(PathEl::ClosePath);
	}

My conversion code is aware of the shortcoming and patches Kurbo's output:

https://github.com/MFEK/glifparser.rlib/blob/ee7f0e8786cac7328f27064a5575aeb1a6175006/src/outline/kurbo.rs#L176

I also test for it:

https://github.com/MFEK/glifparser.rlib/blob/ee7f0e8786cac7328f27064a5575aeb1a6175006/tests/kurbo_conv.rs#L12-L13

[cmyr]

To clarify, the problem as I understand it is that you can have ClosePath elements without a matching MoveTo(?)

This is similar to #212: we do not ensure that paths the user constructs are well formed. I think there are merits to the simplicity of the current API, but this is something that could also be addressed by some kind of builder type that imposed additional constraints.

[derekdreery]

I could imagine some cfg[debug_assertions] code that emitted a compiler_warning if it found malformed paths.

[ctrlcctrlv]

Some of my own algorithms rely on infallibly closing, but since I handle #211 by basically doing a double-split, first on Close, and then on MoveTo, if I do not patch your output I end up with empty vectors containing nothing.

I must do it this way because MFEK's tools, including core library glifparser.rlib must receive all contours as Vec<Point>. An outline is then Vec<Vec<Point>>.

So first I take out the closed contours, where we see a MoveTo up to a Close but not including a MoveTo. Then the open ones are handled.