Why not typst? See also Home · Typstry.jl
(Sorry, I’ll see myself out )
Why not typst? See also Home · Typstry.jl
(Sorry, I’ll see myself out )
Because LaTeX is the de-facto standard for scientific articles at this point, so I need the tooling for that, and not something else. Also, I don’t consider myself old yet, but I am old enough to have seen about 3–4 intended replacements to LaTeX fizzle out quietly. With all its quirks, it is still a great system.
The purpose of this exercise is to add some formatting code to LaTeXTabulars.jl, which I am dusting off a bit as it is getting long in the tooth. Exporting tables helps prevent copy-paste errors and keeps the body of the paper up to date.
Oh I know, I was being intentionally cheeky . You’re certainly correct. That said…
I think this is less likely in this case. Could be wrong, but I think typst is like the Julia of typesetting. Not saying it will ever match LaTeX’s dominance (despite being unambiguously superior already), but I also think it has staying power.
That looks really useful, though I wonder if you’ve looked at PrettyTables.jl - with the new re-write, it might be able to handle everything you need.
Then again, PrettyTables does a lot and there’s certainly something to be said for a small, focused package that just does one thing well
I am definitely keeping an eye on it, but in the medium run I will stick to LaTeX for production. With coauthors etc, you cannot just change the tooling on a whim.
Also, projects like this are a great showcase for Rust.
The point is not to handle everything, but to minimize the time I spend on formatting tables.
AFAIK Typst has a much narrower scope than (La)TeX, it doesn’t aim to support describing vector graphics as an integral part of the document. That is, one can include an SVG into a Typst document, for example, but one can’t, for example, specify within the document that an arrow should point from a certain word to another. Typst’s drawing primitives are simply not low-level enough.
We’re surely taking this off topic (sorry @Tamas_Papp - and mods, feel free to split all of my stuff into a separate thread), but sure you can…
Or my favorite:
#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),
)
I only found out about it here, 45 minutes ago. After browsing docs, blogs, etc. I agree. The only reasonable objection I’ve seen to Typst is that collaborators, journals, etc. only accept LaTeX (or Word); this is clearly important, and a valid reason to avoid Typst at present. I found many other arguments against using Typst rather than LaTeX, but they are all quite poor. Some are based on lack of very basic knowledge about Typst. Some on lack of basic knowledge about programming languages and their implementation. Some on emotional attachment to TeX/LaTeX.
Some arguments are very closely analogous to those you hear about Julia. “Why don’t you just contribute to making Python better/faster?” Or “Ok, you convinced me, it has to be a new language. But why can’t you make it compatible with Python” (no definition of “compatible” is given)
A reddit user said they inquired at arXiv about accepting Typst docs. This was the (alleged) response
Can you explain why typst invented yet another markup language for science papers rather than adopting PreTeXt (pretextbook.org)?
I can’t imagine that level of ignorance and hubris can persist much longer.
The Typst repo already has 34K stars. It seems to be developing and growing rapidly. However, it appears that 90% is written by a single dev. For a project this size, even OSS, that’s a bit skewed.
I am guessing that, continuing with the Python/Julia analogy, Typst has a faster route to adoption. Part of Python’s competitive strength is incumbency. But the historical TTFX problem, and continuing requirement for the user to face at least some compilation is a huge disadvantage for Julia. The typical end user doesn’t understand (or maybe care) how much pain and effort the dev bears; only that the program and packages start as quickly as possible. At this point, a slightly more sophisticated user might choose Julia over Python because the compilation and loading story is so much better than it was (and, importantly, is improving). In this respect, the appeal of Julia vis a vis Python is broadening. But the market is moved by the (numerically overwhelming) least sophisticated.
Typst does not appear to have these disadvantages. Installation, loading, compilation all appear to be superior to TeX. This makes me think its adoption might be more rapid than many are predicting.
ArXiv doesn’t even support modern TeX engines. Neither do journals, though, AFAIK.
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.
(Again, with apologies for sending this thread off the rails - I would split the topic if I had those permissions / knew how).
In my field (biology), no one uses LaTeX and journals basically only accept docx, so this doesn’t really matter. Actually, the collaborators piece cuts towards typst, since their markup language and web-editor is a much lighter lift than getting collaborators to contribute on Overleaf or god forbid, on a git repo.
In practice - I’m mostly reduced to having collaborators comment on a doc or pdf, and then I make the changes myself. And I find this much less painful with typst than I did with latex.
Thank you @stevengj !
I didn’t mean to imply that collaborators and journals only accepting LaTeX or Word is a universal objection, only that it is a valid reason for some academic subcultures. If the culture or rules allow submitting or working with a pdf, then the path to Typst is smoother.
In fact, arXiv accepts pdf-only submissions as long as they are not generated from TeX/LaTeX. This might provide an end run around the restriction. I wonder if it’s possible to embed the Typst source in the PDF (I think the IPE drawing program does something like this. You can round trip perfectly between XML source and PDF)
I’ve seen people argue forcefully for adopting git as a universal tool for collaborating on scientific documents. Obviously, this will never happen. But some people seem to think it’s a reasonable goal.
I looked into this effort a few years ago, and it seemed like a great idea, though wasn’t complete enough for me at the time. Something like that with lots of gentle on-ramps for contributors is definitely going to be necessary to get anywhere close.
I agree with you that it will never happen - git merge conflicts are too steep a price to pay - but I think typst’s collaborative editor + git as backup / explicit versioning might be a pretty good middle ground.
Oh, I should also link this long (and ongoing) thread on Zulip that started last year: https://julialang.zulipchat.com/#narrow/channel/225582-random/topic/typst.20.28modern.20latex.20alternative.29
Is anyone using typst to write scientific documents? What’s the experience? Is there any tooling?
I heard about typst right now in this thread, so I’m curious and ignorant.
I wrote my most recent manuscript in typst, and it was glorious. Line numbers were the last thing I needed, and they came with the most recent release.
I’m in a field (biology) where journals mostly expect word documents though, so my workflow is typst → PDF → adobe acrobat conversion to docx. This was pretty seemless though, much nicer than my previous workflow
Thanks for bringing this up. Consider by interest piqued!
I didn’t actually answer this part. There’s the web-app, which allows simultaneous editing by collaborators (but requires an account), but the compiler is all open source, and there’s a language server and plugins for vs code and nvim at least - I would expect for other text editors as well.
Maybe just some good ole “Baader Meinhof phenomenon”, but I also only learned about Typst last week or so and am trying it out by writing my students physics exams in it. So far it’s basically “just” a really streamlined LaTeX, which is nice! As someone who usually only needs the basics like math, figures, itemized & numbered lists, etc., it results in something basically indistinguishable from what LaTeX would produce (including an open source version of the iconic Computer Modern font), in a much more straightforward fashion.
Agreed, but even in a different sense! I’d go with the analogy that as “Julia offers the power of C with the ease of Python”, Typst offers the power of LaTeX with the ease of Markdown.
I’m also curious to see how this integrates into literate programming like with Literate.jl, as to me they seem pretty complimentary.
P.S. There’s also the Tinymist with its VSCode/VSCodium extension that makes local writing “just work”.
This is precisely my meaning . With a little bit of “the thing I want may not exist yet, but I’m actually empowered to make it myself”.
For sure! One thing missing at the moment is the ability to output html direct from typst
, but this is in the works! I know it’s what @ExpandingMan is most excited about