I hope it does much more. LaTeX is very powerful when it comes to the package ecosystem, but it is a horrible language to program in. The scripting language of typst seems pretty decent, with all modern features (namespaces, closures, etc). It just needs multiple dispatch
Perhaps more like JuliaSim of typesetting: Typst: Pricing.
EDIT: indeed, as pointed out in the comments, there is an open-source typst CLI. Sorry for the ignorance. I have finally learnt that typst is not just the web app.
@zdenek_hurak: I think you are confusing the language and the compiler (FOSS) with the web-based collaborative app (not unlike Overleaf vs LaTeX).
I see. Only now have I finally read about the typst CLI. Thanks for this correction. Indeed, I thought that it only exists as a web app.
Yes, though in this case, it’s the same people - my understanding is that the paid version of the typst web app is to support the development of the oss project (I don’t actually know the relationship between overleaf and latex). So here, I think maybe the typst web app and typst is most analogous to JuliaHub / Julia.
But yes, the typst compiler is open source/free, and I believe they’ve said that the web app will remain freemium
Just doing some cursory looking around and found TypstJlyfish.jl and the jlyfish Typst package.
Jlyfish is a package for Julia and Typst that allows you to integrate Julia computations in your Typst document.
Perhaps “the power of TeX”?
TeX is the rock solid underpinnings, the typesetting language itself. LaTeX is a set of macros that make interfacing with TeX a bit easier, but still awkward as all get out.
I’ve been using typst very extensively for the better part of a year now. As nice as it is, for me the real killer feature is the ergonomics of writing math, which I find vastly better than any other method. This mostly comes down to the particular markdown language they use for math which goes to great lengths to eliminate “line noise” (occasionally at the cost of reasonable syntax) but the ease of scripting also makes generating text drastically easier than it is in latex. (It is also a surprisingly good scripting language, my only gripe is that I find data structures a bit on the complicated side and it would benefit from better pattern matching tools.)
By the way, as soon as they officially release the HTML target, I will be dead set on making it possible to do Julia package docs mostly in typst, so you can be sure I’ll be working on that if nobody beats me to it.
Have you tried LyX (www.lyx.org)? It generates LaTeX under the hood (and gives access to all of LaTeX if you want it), its equation editor is a pleasure to use (you can type LaTeX syntax or select from menus, and you see the results as you type), and it lets you skip all of the fussing with syntax and compilation errors for most editing. I like its “WYSIWYM” philosophy of focusing on content rather than on structure — you don’t need to continually compile things just to make the text readable while you edit it, so the performance issue of LaTeX goes away.
The only reason I don’t use LyX for everything is that it doesn’t offer the “google docs” live collaboration experience of Overleaf, which is nice for collaborative papers.
One of the main features of typst is incremental compilation, so it is extremely fast. As far as I know this is what the GUI app is doing while you type, or you can do this via the command line via typst watch
. My current setup does this with nvim
whenever the file is saved, but at some point I may set it up to watch the buffer (I actually don’t really care about seeing changes as I type, but error messages in the PDF itself is something that I would like which typst does not currently offer).
A quick and crude test indicates that Typstry.jl + Literate.jl works a little but has some issues.
IJulia.jl works on Typstry.Typst
and Typstry.TypstText
and will support Typstry.TypstString
once this new version is merged. Literate.jl seems to pre-render TypstString
s correctly, but the image breaks on re-evaluation.
makedocs
on the generated markdown file attempts and fails to run a regex on the TypstString
, and I’m not sure what would fix this. It can however render Typst
and TypstText
though.
Other than the issues above, is there anything else you’d want to do with Typstry.jl + Literate.jl?
By the way, as soon as they officially release the HTML target, I will be dead set on making it possible to do Julia package docs mostly in typst, so you can be sure I’ll be working on that if nobody beats me to it.
This would be awesome! Would this look like completely replacing Markdown files and docstrings with Typst files and snippets? Would it plugin to Documenter.jl or be a standalone package?
note
If anyone is using Typstry.jl 's Julia-value to Typst-code formatting feature, please submit requests for types and packages! Other feedback and requests welcome too
This would be awesome! Would this look like completely replacing Markdown files and docstrings with Typst files and snippets? Would it plugin to Documenter.jl or be a standalone package?
My first attempt would be merely replacing the HTML generation step in documenter with typst, using whatever functions it already uses to pull out the docstrings and generate typst source code for it. So yeah, no markdown. Obviously I haven’t actually done this so we’ll see.
My big question about typst is: does it have decent package management?
One of the biggest shocks I had when setting up TeXLive locally was that standard practice is to install most, if not all packages simultaneously, which takes up a huge amount of space. Starting with a minimal install is an arduous process and results in some really unexpected behavior (like a lack of Unicode support in pdflatex).
(I’d like to believe that I’ve done TeXLive minimal installs completely wrong and missed something important rather than it being the painful process that it was)
My first attempt would be merely replacing the HTML generation step in documenter with typst, using whatever functions it already uses to pull out the docstrings and generate typst source code for it. So yeah, no markdown. Obviously I haven’t actually done this so we’ll see.
TypstJlyfish.jl seems to basically implement Documenter.jl 's @example
, and @eval
in this context, so it could be a good place to build upon or reference to implement the other syntax.
My big question about typst is: does it have decent package management?
Yeah, it’s encoded in the document, and seems to automagically download when needed. You can see it in the first two lines of the example I posted above:
#import "@preview/pinit:0.2.2": *
#import "@preview/fletcher:0.5.1"
Con#pin(1)#h(4em)#pin(2)nect
#pinit-fletcher-edge(
fletcher, 1, end: 2, (1, 0), [bend], bend: -20deg, "<->",
decorations: fletcher.cetz.decorations.wave.with(amplitude: .1),
)
You can create a new file with that content, typst compile that_file.typ
and it will render correctly. Nothing else required.
The @preview
thing seems to direct to the typst “universe” which is their package repository, but you can also provide github repos or local directories
One of the main features of typst is incremental compilation, so it is extremely fast. As far as I know this is what the GUI app is doing while you type, or you can do this via the command line via
typst watch
.
The whole point is that I don’t want to worry about the precise appearance while I type. I don’t want to compile/render at all while I’m typing, no matter how fast it is. I want to worry about the content — for this, things need to be readable (equations must render, headings should appear in a big font with correct numbering, bold text should be bold, etc.), but they don’t need to appear exactly as they do in the final document. And I don’t want compilation errors to even be possible for the most part. Both of these are a big advantage of using a WYSIWYM GUI like LyX — which does not do full LaTeX compilation/rendering as you type — whereas the rendering backend is mostly orthogonal to this.
As far as I can tell, the main reason people care about fast compilation with LaTeX is that it is so unreadable in source form — without compiling/rendering, it is hard to tell whether you got an equation correct, or if you made a syntax typo. Otherwise, you only need to compile in the final “tweaking the appearance” stage, and that’s usually a small part of the writing process (especially for technical documents that mainly use pre-existing stylesheets).
(To be clear, I don’t want a WYSIWYG GUI like Word, even if Word didn’t suck. I don’t want to be worrying about formatting details while I’m trying to write.)
(It always shocks me how few LaTeX users have ever used LyX — which is free/open-source, cross-platform, and mature from many years of development. In my department (Math), most people have not even heard of it.)
To be clear, I think that there is no question whatsoever that arXiv should exclude Typst documents at present. My issue is with the reason given.
Why’s that ? Wouldn’t it be a good thing if arXiv accepted Typst ?
It seems clear to me that if journals (or preprint servers) do not accept Typst, no one will really use it.
It’s a long thread sorry if I missed the argument somewhere.
Why’s that ? Wouldn’t it be a good thing if arXiv accepted Typst ?
I don’t know if it would be a good thing - I mean, I think it would be great, but I can understand their perspective. If they open the door to one kind of thing, then they have to worry about people asking about all kinds of other things (eg manubot I mentioned before, PreTeXt that someone else mentioned, whatever else.
Hell, even just dealing with keeping the compile toolchain current / being able to match documents with the right version of the compiler (eg a bunch of breaking changes for typst were just released) would be a hassle from a maintenance perspective.
It seems clear to me that if journals (or preprint servers) do not accept Typst, no one will really use it.
If they accept PDFs, I don’t think it matters. Hell, most of the journals I submit to (and the preprint servers I use, bioRxiv and medRxiv) don’t even accept LaTex.
I agree, LyX is great. So is Bakoma. But no matter how good these are, they are not WYSIWYM. More like WYSIWIM (what you see is what I mean, where I is the compiler). What I (as the user) mean is often not what I see.
TeX (LaTeX) are complicated, full of little idiosyncrasies… It would be nice if the “programming” language underlying the typesetting system was a bit more user-friendly.
If they accept PDFs, I don’t think it matters.
True.
Hell, most of the journals I submit to (and the preprint servers I use, bioRxiv and medRxiv) don’t even accept LaTex.
For me it’s the opposite, most journals I know accept LaTeX. Although many journals let you submit a PDF initially, for publication they will ask for the sources.