PgBiel

> There are a few stupid track_callers in the code base for some reason. We only need it if the handler panics, not if it returns a string. Ohhh alright,...

> one thing I'm overall also not sure about is fields vs methods. I feel like most of these should be methods. the thing I can see being fields the...

Alright, so, updated the branch to latest `main` (adding fields for the stroke things). I'm still planning to add a bit more stuff (and also moving several fields to methods)...

Regarding colors, I made the following changes: added the `kind` field to tell different color types apart (rgba vs cmyk vs luma) and the `values` field to return the color's...

> One big question I have: Didn't we want to make most of these methods? Yes! Slowly working on that, haha (sorry, forgot to mention this explicitly in my update)....

Alright! Today's update: - Rebased to latest `main` (after all the wonderful bugfixes); - Changed `precision:` to `digits:` in `.cm()`, `.mm()`, `.inches()` for consistency with `calc.round()` - Note that I...

Thanks for the valuable input!! Will work on your suggestions later today. 👍

> @PgBiel do you have plans to continue this? This PR's implementation will likely become a little outdated when you implement the types rework, but I can definitely finish this...

> I don't think we need to block this on the types rework. The only thing I'm wondering is whether we had ultimate consensus on what things are fields and...

Also, should we keep the `.cm()`, `.rad()` etc. conversion methods (since you can just divide by `1cm`, `1rad` etc.)? Though at least those would be documented, so it would be...