As a long-time LaTeX user, I was secretly pleased with myself, shelling out from Elixir to do elaborate typesetting and bringing it back. I am blown away by what the Typst project and ExTypst could do together.
I’m still exploring the setup, but I feel that this could also go back towards Elixir documentation (some kind of mix task), or enhancing some of the CMS (OrangeCMS, Phoenix Pages, Beacon, Nimble Publisher) to auto-generate PDF (would need some markdown → typst conversion).
If you’re exploring the space of integration with existing Elixir tooling, check out:
makeup, the Elixir syntax highlighter that ex_doc uses. It has clear instructions for creating a custom library for highlighting new syntax, so you might make a makeup_typst highlighter library based on ex_typst to make typst snippets beautiful in, say, ex_typst’s own documentation.
The nimble_publisher static site generator’s instructions for custom parsers for SSG support. I think their file format does require supporting frontmatter before the file content in question.
Thanks for the library. I’m having trouble showing images in produced PDFs from either external paths (“https://…”) or internal paths. Do we need to have a way to set TYPST_ROOT? By default, when using the command line version, paths need to be either relative to the current file or relative to the compiled file. So I’m not sure how to reference an image using your library. Perhaps the example could be extended to show different ways to reference images.
So, answering my own question, you have to explicitly prefix your static images with, for example, priv/static/img/. And external images are explicitly not allowed by Tryst. For example, it will convert the double slashes in a URL to single slashes before reporting a file not found error; for example: http:/localhost:4000/.
As someone with a passing familiarity with Makeup, I believe this should be very easy. But I guess this would only make sense if you also implemented a typst backend for one of Elixir’s markdown implementations (which is probably a bit harder).
If I were to do it, I’d generate HTML from markdown and then use an HTML parsing library (floki, for example) to get an HTML parse tree and convert that into Typst.
I’m quite excited about being able to use Typst as a backend for an Elixir plotting library. Tpst has all the low level goodness you need to properly render, size and rearrange arbitrary blobs of content (with support for rich text and math) according to the measured sizes.
I’m currently writing the Typst “backend”, and Typst is actually very easy to write and quite powerful.
Would it be possible to support SVG and bitmap (PNG?) output too? If one wants to generate individual figures with Typst (as opposed to complete documents), those formats are useful when publishing on the web or working with certain publishers.
I am wondering: in the example in the repo, what if we fetch data from a database and an employee decided to put typst markup into their name - would we need something like Phoenix.HTML.Safe for ex_typst?
A brief look at the code does not seem like there’s any escaping done currently.
Indeed, currently escaping is not implemented into ex_typst. I’ll see about implementing it in the future, as it’s something I don’t want to rush and end up with a poor implementation. But in the mean time pull requests for it would also be very welcome
According to the Typst docs and my experiments, a “naked string” cam be used in all the same places as content, and results in the literal contents of the string being inserted in the document. Effectively, naked strings escape the content.
@viniciusmuller would you be interested in adding some functionality to generate some kind of Typst AST (or at least an approximation of it) and some functions that could serialize that AST into typst code and convert Elixir values into said AST?
Yes, that would be really nice. That was the initial idea, I ended up just implementing compiling from raw strings because at time typst’s syntax seemed very flexible and I wouldn’t be able to model all of it into the library. But I think it would be ok to start adding this support gradually, as it makes the library much easier to use.