[WIP] Rewrite of Path to use Segments

[srush]

Add a new segment type to path that allows for elliptical arcs and straight line segments.

Currently this just does Path, but maybe should do trail as well (or we should just have trail? segments assume that it is connected, but located).

Experiment with:

• Rewriting arc, circle, rectangle, etc using path
• Verified that these look the same in different backend. (this was much harder than I was expecting due to the fact that svg uses a non standard arc representation )
• Add some more protocols for using transforms and traces.
• Rounded rect now in standard form.

Questions:

• Should these renderers be part of the backend now?
• Can we eliminate Shape class entirely?

[danoneata]

Thanks Sasha! Great effort, as always! I'll take a look in the following days!

[srush]

This got a bit more ambitious. Tried to mimic the visitor pattern for shapes as well and move that to the backend. Also realized we weren't importing the types from the planar library, so I had to fix a bunch of typing issues to get it to type check. blech.

• Add types to the Planar library (need to reinstall)
• Move all "Shapes" to a shapes/ directory.
• ShapeVisitor for rendering shapes
• "Typeclasses" for enveloped, traceable, shape,
• Main core library is now totally independent of rendering. Only handles composition, and position.

[danoneata]

I've started going through the code and I like the changes: it definitely improves the structure of the codebase! I still need to try some more examples, but a potential current issue is that the rendering of the path.py (the bottom shape) example looks different as an PNG compared to its SVG or PDF rendering. Also the PDF rendering produces some small imperfections; for example, the origin has a tiny extrusion and in the last example from path.py the stroke line is not perfectly closed:

[srush]

Okay, think I got these. The issue seems to be that Tikz is extremely sensitive to boundary points. The recommendation is to close on line segments if possible.

https://tex.stackexchange.com/questions/350015/how-can-i-close-a-path-made-of-arcs

For circles I made it 2 arcs that match at exactly the right angle.

Here is the cairo fixed rect.

Unrelatedly. Should we make the cairo backend scale by default to a much higher DPI? at the current default it is very hard to see.

[danoneata]

Okay, think I got these. The issue seems to be that Tikz is extremely sensitive to boundary points. The recommendation is to close on line segments if possible.

Great!

Here is the cairo fixed rect.

Nice! 👍

Unrelatedly. Should we make the cairo backend scale by default to a much higher DPI? at the current default it is very hard to see.

Yes, I'm happy to output larger diagrams for cairo by default (the current height of 128 indeed results in tiny images). I guess that is what you mean by "higher DPI", right?

[srush]

I guess that is what you mean by "higher DPI", right?

I guess the problem is that height also controls line thickness now. It would be nice if that was the same for the same size with PNG / SVG. Maybe PNG could have a seperate scale parameter that defaults to 3 or something. Not sure if this function helps.

[danoneata]

I guess the problem is that height also controls line thickness now.

Hmm... does it? Isn't the line width normalized by the output size by default?

I've tried the set_device_scale function, but it doesn't seem to be doing what we were expecting... Maybe we can delve deeper into this issue in a separate PR?

[srush]

Think we are converged here. Going to merge this in and add issues for:

• Arc arguments
• Rounded rect implementation and example (arrows to corners)
• Changes to PNG.
• Trail / Path. Perhaps most of the logics should be moved to Trail and path should just be a trail and a starting point.

[danoneata]

Think we are converged here.

Agreed! 🙂 Thanks for the PR!