Tutorial: Big Ben

[srush]

Kind of an extended tutorial demo to replicate a diagram of the Big Ben clockface. Would love thoughts or comments for simplifying further.

https://srush.github.io/pydiagrams/examples/bigben/

Here's what it really looks like:

This is not ready to check in yet, as there are some major breaking changes. These include:

• Switching everything user facing to degrees from radians.
• Changing the way the show_* functions work.
• Monkey patching geometry so it works in the OO style.
• Fixing some bugs with arcs and circles.
• Making line_width not scale in SVG (vector-effect style)

Sorry these probably should be different PRs, but most of them came up in the process of making the demo.

[danoneata]

This is beautiful! Looking forward to taking a closer look at the example!

[danoneata]

I've noticed in the Big Ben tutorial that the under_arc curve is chopped off when rendered. On closer inspection, it seems that there is a slight issue with the envelope. An arc can, in principle, be specified by negative angles:

 arc(radius=1, angle0=-50, angle1=50)

but in the wrapped function the direction d takes only positive angles; so if a direction's angle is in the [310, ..., 360] range then the if condition enters through the second branch ("point outside of arc"). For the above example, the envelope looks like this (see the upper half of the envelope, which corresponds to the [-50, ..., 0] range):

[srush]

Okay, think this roughly works now, however I realize there are some big questions that I may have broken.

• I made line-thickness scale invariant for SVG. As a user, I think you really need this for scaling compositionality to work. But it is counterintuitive that you can't really scale your diagrams after making them. Other backends probably need this as well. Maybe it should be optional?

• There are some inconsistencies with angles. I can't decide if they should go clockwise or counterclockwise, i.e. this seems bad
  

[srush]

Oh, as always the Diagrams manual answers my questions.

• Line width-scaling should be in output normalized units by default https://diagrams.github.io/doc/manual.html#measurement-units with optional local units.

• Counter clockwise is correct. I should override or hide the .angle property from users.

[danoneata]

I've made a small change to the computation of the arc's envelope. I hope I didn't break anything and it works fine now—is this the behaviour you would expect?

arc(radius=1, angle0=-45, angle1=90)

arc(radius=1, angle0=-45, angle1=360)

There are some inconsistencies with angles. I can't decide if they should go clockwise or counterclockwise, i.e. this seems bad

Yes, I have to fix this for arcs as well: currently, negative angles are in the top half and the arc is drawn clockwise...

If we go with the counterclockwise convention, maybe we should have unit_y = Vec2(0, -1), such that, unit_x.rotate(90) == unit_y?

Edit: I think that swapping the angles and negating them draws the arc with the same convention as rotate (counterclockwise and starting from the right). I don't know if this breaks anything else.

diff --git a/chalk/shape.py b/chalk/shape.py
index 62bfb30..6dbc980 100644
--- a/chalk/shape.py
+++ b/chalk/shape.py
@@ -255,6 +255,7 @@ class Arc(Shape):
     angle1: float

     def __post_init__(self) -> None:
+        self.angle0, self.angle1 = -self.angle1, -self.angle0
         surface = cairo.SVGSurface("undefined.svg", 1280, 200)
         self.ctx = cairo.Context(surface)

[danoneata]

I've tried to make the "decal" corners appear a bit tighter by fixing the envelope for arcs and some additional tweaking:

And here is how it looks in the final rendering:

[srush]

Thanks. this is great, that was bugging me. (I am pushing a couple other tweaks I made as well, realize the colors are off in your version).

Another related thing is that it would be nice if Path and maybe Trail could have arcs in it. Wanted to have the hands use an arc_between, but couldn't fill.

[danoneata]

Another related thing is that it would be nice if Path and maybe Trail could have arcs in it. Wanted to have the hands use an arc_between, but couldn't fill.

Yes, that's a good point! I've added an issue as a reminder. It might be also a good opportunity to allow for more flexible curves, such as Bézier curves or splines (as you suggested in #35).

[srush]

Gonna merge this in. Seems like it now fixes more than it breaks. Made issues for the remaining problems.