Regular polygons

[Enivex]

Description

At the moment, visualize has polygon, but the only regular polygon that is easy to create is a square.

https://typst.app/docs/reference/visualize/polygon/
https://typst.app/docs/reference/visualize/square/

It would be helpful to have a function (or some easier way to get them from the existing one) to obtain regular n-gons.

Use Case

I'd wager that a good chunk of those looking to draw polygons are actually looking to draw regular polygons (equilateral triangles, regular hexagons etc). Currently this requires some math, and is therefore inconvenient. Here's a proof of concept illustrating this.

#let regular-polygon(n) = {
  let vertices(n) = for k in range(n) {
    (((1+calc.cos(2*calc.pi/n*k))*1cm,(1+calc.sin(2*calc.pi/n*k))*1cm),)
  }
  polygon(fill: blue.lighten(80%),
  stroke: blue,..vertices(n))
}
#for k in range(3,30) {box()[#regular-polygon(k)]}

(Obviously a proper implementation would need to be more customizable than this.)

[drupol]

I'm using this:

#let n-gon(radius: 10, sides: 6) = polygon(
  fill: blue.lighten(80%),
  stroke: blue,
  ..range(sides).map(
    i => (radius * calc.cos(i * (360/sides) * 1deg) *1cm, radius * calc.sin(i * (360/sides) * 1deg)*1cm)
  )
)

#n-gon(radius:5, sides:6)

[PgBiel]

This could benefit from #843 with some syntax like #polygon.regular(length, sides) or similar.

[arj0019]

I think this could be achieved with an implementation of PolygonElem that defines regular that takes arguments radius and sides and returns a PolygonElem with the verticies defined accordingly.

I would like to implement this functionality, but I am not sure how to integrate with the compiler. I need to study the architecture. I think that the changes to PolygonElem are probably straightforward.

[PgBiel]

I think this could be achieved with an implementation of PolygonElem that defines regular that takes arguments radius and sides and returns a PolygonElem with the verticies defined accordingly.

I would like to implement this functionality, but I am not sure how to integrate with the compiler. I need to study the architecture. I think that the changes to PolygonElem are probably straightforward.

As a starting point, you can implement a regular function in polygon.rs, with the #[func] macro - just ensure it has the correct arguments with the expected types (e.g. radius: Length<Rel> or similar; sides: u64 or similar). In your regular function, implement your logic as needed.

To call the original PolygonElem, you should be able to do something like PolygonElem::new(...params...).

Then you can use function scopes to add the regular function as a function under the original PolygonElem, by adding, under the #[element(...)] call, the following:

#[scope(
  scope.define("regular", regular);  // name of your regular function there
  scope
)]
struct PolygonElem {
   // ...

That's a rough sketch of what you will have to do, basically. Feel free to @ us at Discord as well if you need more help too!

[arj0019]

@PgBiel Thanks for the help. I will attempt to implement the functionality tonight.

[arj0019]

I am trying to learn about the Vec<Axes<Rel<Length>>> type, and how to generate one, but cargo doc is not working for me; there is no documentation in typst\target.

PS C:\Users\johnsoar\Documents\Personal\typst> cargo doc --open
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
error: no crates with documentation

[arj0019]

cargo doc --all generates the documentation, but the info is here: Axes, Rel, Length

[arj0019]

@PgBiel Looks like the scope.define is a bit more complicated. It does not like my function with more than zero inputs.

PS C:\Users\johnsoar\Documents\Personal\typst> cargo check
    Checking typst-library v0.3.0 (C:\Users\johnsoar\Documents\Personal\typst\library)
error[E0593]: function is expected to take 0 arguments, but it takes 4 arguments
   --> library\src\visualize\polygon.rs:23:27
    |
23  |   scope.define("regular", regular);
    |         ------            ^^^^^^^ expected function that takes 0 arguments
    |         |
    |         required by a bound introduced by this call
...
105 | fn regular(radius: Rel<Length>, verticies: u64, fill: Option<Paint>, stroke: Smart<Option<PartialStroke>>) -> PolygonElem {
    | ------------------------------------------------------------------------------------------------------------------------- takes 4 arguments
    |
    = note: required for `typst::eval::Value` to implement `From<fn(typst::geom::Rel<typst::geom::Length>, u64, Option<typst::geom::Paint>, typst::geom::Smart<Option<typst::geom::PartialStroke>>) -> polygon::PolygonElem {regular}>`
    = note: required for `fn(typst::geom::Rel<typst::geom::Length>, u64, Option<typst::geom::Paint>, typst::geom::Smart<Option<typst::geom::PartialStroke>>) -> polygon::PolygonElem {regular}` to implement `Into<typst::eval::Value>`
note: required by a bound in `typst::eval::Scope::define`
   --> C:\Users\johnsoar\Documents\Personal\typst\src\eval\scope.rs:98:70
    |
98  |     pub fn define(&mut self, name: impl Into<EcoString>, value: impl Into<Value>) {
    |                                                                      ^^^^^^^^^^^ required by this bound in `typst::eval::Scope::define

[arj0019]

The solution is to implement the #[Func] macro

[arj0019]

I am at a point where I can generate shapes with polygon.regular. I need input from others on the details of the functionality.

• Where do you want the origin of the polygon to be placed (ex. relative length of box, center of box, bottom left of box)?
• What units do you want to use for the radius (ex. pt, cm, any AbsUnit)?
• Are you ok with defaulting to first point above the origin (ex. triangle points upwards)?
• Do you want the ability to rotate the polygon?

[Kreijstal]

shouldn't this be implemented on typst-canvas?

[Enivex]

* Where do you want the origin of the polygon to be placed (ex. relative length of box, center of box, bottom left of box)?

What's the origin of the other shapes? The behavior should likely be consistent with that.

* What units do you want to use for the radius (ex. pt, cm, any AbsUnit)?

The radius should be a length, just like for a circle https://typst.app/docs/reference/visualize/circle/

* Are you ok with defaulting to first point above the origin (ex. triangle points upwards)?

I imagine the most natural thing would be to either have a vortex directly above the center, or having a horizontal edge at the bottom. The latter choice would make the case of 4 vertices consistent with https://typst.app/docs/reference/visualize/square/

* Do you want the ability to rotate the polygon?

There is no rotation angle for ellipse or square. I think the idea is that one should compose with https://typst.app/docs/reference/layout/rotate/ instead. (Though it does not affect layout right now).