Diagram support

[0x7CFE]

Hello, first of all I'd like to say a big thank you to the whole team for creating such a good tool!

I'd like to know, are there any estimates, when inline diagrams would be supported?

I am writing a scientific paper with a lot of diagrams that I created using graphviz dot. I tried converting .dot files to SVG, but when inserted to the document, text labels become invisible, for some reason. Inserting them as PDF for now.

[laurmaedje]

Diagram support is still a bit away. For now SVGs are the best we have. If they contain text, you need to export the text as paths because text in SVG is also not yet supported (see also #371)

[pablodz]

I think that is better to use d2 https://d2lang.com/ generate svg and import it in typst

[giovanniberti]

There's also mermaid.js with its CLI if you wanto to generate diagrams from code

[0x7CFE]

@giovanniberti, mermaid is fine for simpler diagrams, but for complex graphs with custom edge and node settings it can be problematic.

[alixander]

hey, i'm the creator of D2. If there's anything we can do on our side to make integration possible, please let me know.

[jasonjckn]

+1 vote for d2, and not mermaid

mermaid is very limited.

[Enivex]

The focus should be on implementing native Typst visualization first. Support for various external formats sounds like a translation job for a future package, not a part of typst itself.

[0x7CFE]

The focus should be on implementing native Typst visualization first.

Whilst native solution would probably be the best, adapting existing tools seem to be an easier task with predictable result, IMO. Especially given that the surface area is quite small. Just an extension of a figure will do the trick: text in, SVG out.

[patrick-kidger]

FWIW if it helps anyone here, I'm using inline Python code to generate images dynamically: c.f. this comment and typst_pyimage.

[maninalift]

It appears that D2 is fairly limited. It seems to be focused on creating box-and-connector type diagrams.

I imagine that Typst will be aiming for a generic drawing system more akin to TikZ.

Something that I value about TikZ in particular is the ability to integrate it into the layout of the page including the text and equations on the page. More specifically, I can set anchors within the text, then have, for example arrows connecting those anchors across the page.

FWIW the haskell "diagrams" package is absurdly elegant but perhaps less relevant as a source of inspiration

[OpenFoam-User]

+1 vote for d2, and not mermaid

I have asked here, and according to D2 creator, complex diagrams (e.g. in the context of academia) are beyond the scope of D2.

I suggest using Penrose instead. Take a look here:

• Project: https://github.com/penrose/penrose
• Gallery: https://penrose.cs.cmu.edu/examples

[a7g4]

I have asked here, and according to D2 creator, complex diagrams (e.g. in the context of academia) are beyond the scope of D2.

I think that's a misrepresentation of what @alixander said:

Thanks for the reply. These tools are at different levels of abstraction. The fundamental difference is that their syntax is telling you how to draw it (segment from this coordinate to this coordinate), whereas D2's syntax is describing the model. The types of diagrams one makes with each tool is almost entirely mutually exclusive. It's out of scope for this tool/language.

I think that higher level abstraction fits nicely with how Typst abstracts away directly laying out text. D2 is the same in that it abstracts away directly laying out diagram elements. I think there are some cool possibilities that could be unlocked if Typst could influence or constrain the rendered diagram based on the page's/document's layout constraints

FWIW - D2 (generating an SVG) & Typst fit my use case where in the past I would have used Tikz & Latex. Obviously that doesn't solve every use case though.

[OpenFoam-User]

@a7g4

Your reply is completely misleading and I do not see what value it tries to add here. The author summarized it in clear language by saying:

It's out of scope for this tool/language.

Take a look at Penrose. It has very advanced features similar to tikz et al.

[tuta-amb]

+1 for penrose, i've used it in the past and it's very extensible. d2 while is on a higher level, doesn't many diagram use cases.

[davidleejy]

+1 for Penrose.

Screenshot of: https://penrose.cs.cmu.edu/try/?examples=set-theory-domain/tree-venn

[davidleejy]

Another possibility is Excalidraw as shown in this screen capture. It's nothing sophisticated but it's convenient and simple, fitting some use-cases.

https://github.com/typst/typst/assets/1690072/84d23db4-9512-4bff-a468-02a799dcd845

Both Excalidraw and Typst are being used directly in Visual Studio Code in this screen capture.

[davidleejy]

Another method to draw diagrams in Typst is via "svgbob" type of methods.

As at writing this comment, the svgbob direction appears potentially promising, but possesses drawbacks. The key idea of svgbob is for ascii diagrams (diagrams that are drawn with unicode characters) to be rendered into the svg format which are embeddable in Typst, and subseqeuently rendered in the output file (e.g., pdf).

Relevant links:

1. Samples of what svgbob can do are shown in an online editor that can convert ascii into svg in real-time so that you can get your hands dirty: https://ivanceras.github.io/svgbob-editor/

2. A Typst package that converts svgbob-compliant ascii into svg: https://typst.app/universe/package/bob-draw

(Current) Drawbacks:

1. No method (that I know of) to convert an image (say, a sketch) to svgbob-compliant ascii (which can, in turn, be input into an svgbob renderer)

2. No method (that I know of) to convert ascii to svgbob-compliant ascii. (which can, in turn, be input into an svgbob renderer)

3. It appears that some graphics (vectors?) in the svgbob standard are hard-coded, e.g., there really are only a handful of circles of different sizes available in svgbob.

4. The svgbob specifications appear to be quite strict at the moment – one can't just draw ascii diagrams, of say, circles, in most ascii applications like Monodraw or ASCIIflow, and expect svgbob renderers to render them as circles.

An ascii diagram of a circle drawn using the letter x:

           xxxxxx          
       xxxx     xxxx       
      xx           xxx     
     xx              xx    
     x                x    
     x                x    
     x               xx    
     x               x     
      x             xx     
      xxxxx      xxxx      
          xxx xxxx         

This will NOT render into a circle via svgbob renderers because it is not a circle under svgbob specifications. 😄 

Note that the drawbacks I've listed here are current as of writing this comment, and may well be overcome in the future. Overall, I think the svgbob direction is kinda neat.😎

[airstrike]

Given the discussion over various other libraries, I just wanted to mention Kroki which offers "one API to rule them all"

https://kroki.io/

[maninalift]

There are a few things being suggested here. Any of them can be used to generate images that can be imported into a Typst. I could also imagine

However, when it comes to properly integrating a language for drawing into the Typst typesetting system, I think that the following features would be desirable

• integration with Typst scripting, so that Typst variables and state can be used in generating diagrams
• integration with typesetting allowing typeset elements to be included in
• integration with typesetting, allowing diagrams to anchor to points in the page layout (e.g. adding arrow between specific paragraphs)
• be precise and general purpose, providing lower level primitives like polygons and lines that allow the user to express any kind of diagram in any style
• yet still allow convenient abstractions (e.g. allow writing functions to draw bar charts from data)

While many of the above diagramming suggestions are well worth learning from, I can't imagine that integrating them directly could ever provide all of these features in a satisfactory way.

I imagine that, similar to TiKZ in TeX, it makes to build a diagramming library in the Typst scripting library on top of some lower level drawing primitives.

This seems like the kind of project that some dedicated and talented individual is going to have to eat sleep and breathe for some months to bring to life.

[knuesel]

I think that's what CeTZ is aiming for (and it's already quite usable).

[laurmaedje]

We're amazed by the growth of Typst Universe and, based on the number of packages there that add support for various kinds of diagrams, we don't have plans anymore to ship a built-in diagramming solution. (Better drawing primitives are a different story!)