Typst can now parse/display svg from string...

[Beiri22]

This might be an opportunity for drawing... see https://typst.app/docs/changelog/ and https://typst.app/docs/reference/visualize/image/#image-decode

What do you think?

[johannes-wolf]

Hi, I also thought about rendering by outputting SVG and would like to give it a try.

[johannes-wolf]

I am closing this, as we (@fenjalien and I) decided to not use an SVG backend (yet).

[fenjalien]

These are the rough points about it:

We basically don't get any benefit, what svg does provide we've already figured out in a way that works. So if we do spend the effort and time reworking we don't gain enough. There's also still talk of Typst getting improved drawing tools in the future which we may want to switch to. So in the end its too much of a risk of wasted effort.

• Theres no way to make the svg "efficient"
  • svgs and typst/cetz are different paradigms
  • styling and transformations would have to be set individually for each element, theres just no way to format it correctly in anticipation
• styling
  • we would have to convert typst stroke into css correctly (the dash part would be particularly difficult)
  • when gradients become a thing (soon?) or any other additional styling cetz won't automatically work with them. We would have to work out the conversion steps (also not tried out gradients).
• transformations are in 2d (3d doesn't work)
• content would have to be sandwiched between two svg elements
  • links/click through does still work (at least on firefox)
• theres no calculation benefit as we work out boundaries for each element anyway
  • I didn't get the svg to do the boundary automatically correctly but even then we won't know the actual size as the svg expands to fill allocated space.
  • we can't take into account the stroke of elements touching the boundary so the element gets clipped. currently this does not happen as visual elements don't have that hard boundary.

some of these are null points but would annoy me as we implement it