Like many others in the community, I believe the lack of publisher support is the main barrier preventing Typst from wider adoption in academia. The ecosystem has already matured a lot: templates for IEEE, Elsevier, Springer, and many others now reaching near-perfect fidelity. Yet, without official publisher acceptance, many academics hesitate to make the switch.
This raises the big question: How and when should we start advocating for Typst with publishers?
Some points for discussion:
Who should take the lead? Should lobbying be coordinated by Typst maintainers, or is it something the community can take part in collectively?
Should lobbying wait until the Typst spec is considered more stable? While future changes are planned (e.g. types), they don’t seem likely to break existing templates, and publishers could always require a fixed compiler version if needed.
Should we approach publishers one by one, or aim for coordinated outreach across multiple venues at once?
Are there already initiatives or internal policies about these matters that we should be aware of?
We only get one chance at a first impression, so what approaches would be most effective in convincing publishers to accept Typst submissions?
As a starting point, I am considering contacting Dagstuhl (the publisher of LIPIcs) to ask whether they would be open to supporting Typst submissions with the para-lipics template that I developed with @Gucio. I am wondering if telling them that the Typst creators are German like them may be a good selling point
Fun fact, I am currently preparing a conference submission written entirely with Typst/para-lipics. I can send the Typst-generated PDF to the submission platform (HotCRP, Easychair…), but upon acceptance, the publisher will ask for LaTeX sources and I will have to convert my Typst code (sadly ).
My personal opinion is that typst is still too young to be adopted by publishers, and a community lead effort to get it adopted would likely do more harm than good. Don’t get me wrong, I love typst, but it’s just not there yet.
Ultimately, the only reason why a publisher would want to start accepting typst submissions is if a substantial enough portion of authors want to submit typst sources. A bunch of people telling a publisher that they think the publisher should start accepting typst sources but then never contributing to their journal is not productive.
I am not saying that there should not be any effort to try to get typst adopted more widely. If you are publishing research to journals and would rather do it in typst than TeX then you can and probably should email the publisher and let them know this. But do not be surprised if you are told to wait until there are more authors that would also want to submit with typst.
Understand that supporting a new submission format requires engineering, QA, and ongoing maintenance on the publisher’s side. For example, here is why arXiv requires TeX sources. You can see that they don’t just want the source because they like staring at code, and that supporting typst submissions would also mean building tooling for all the reasons listed above.
Further, there is the problem of long-term stability. Typst is still getting updates and has not even had a 1.0 release yet, so a publisher committing to supporting typst would also be committing to supporting all future versions of typst, and maintaining backwards compatibility. Packages and their updates would also have to be maintained, and since these are generated by users, they would probably need to be audited.
Even though the majority of publishers support LaTeX, many publishers are using an old version of TeX Live. For example, Nature uses TeX Live 2017 for their submission systems. (See LaTeX author support | Publish your research | Springer Nature, FAQ 1, eJP section). I’m afraid that the authors in 2033 won’t be happy to write Typst manuscripts compatible to Typst 0.13.1.
By the way, for the publishers to use Typst, we need a distribution like TeX Live. Having to connect to the Internet to download packages and compile can be a big security concern for them to adopt Typst.
I mean, sounds like cargo fetch. Probably not hard to add this in Typst. But you have to probably make it fetch every single package, at least of the last version. That’s a lotta fetchin’. I guess same with Tex Live.
Typst already supports offline mode: basically just git clone https://github.com/typst/packages and copy packages/preview to ~/.local/share/typst/packages. This makes all versions of all packages available without further Internet access. And you can also copy that directory with a USB stick or whatever to air-gapped computers that never have network access.
tbf that’s not quite right. The typst/packages repo contains files that are excluded through typst.toml (e.g. manuals that are shown on Universe, but not part of installed packages). It shouldn’t usually make a difference, but you don’t get exactly the same result as actually installing/caching all packages normally – which might be a concern especially for organizations that have these kinds of requirements.
Running packages/bundler at main · typst/packages · GitHub may or may not be the piece that gives you the packages exactly as they’re supposed to be shipped – I haven’t checked but it seems like that might be the tool.
That’s true. It didn’t seem to me like something that would matter in practice, but thinking more about it I can see cases where it would, e.g. when someone uses these local packages while authoring a document/package, they might use files that are actually not there in a normal environment. But that’s not a problem if you’re only using this setup to build existing files.
I guess observable differences will be more likely once Typst adds a non-hacky way to test for a file’s existence. But even then, having to apply the exclude directives manually is a rather minor hurdle.
Of course it would be nice to have an official way to get a perfect mirror, but something that currently works in practice for 100% of packages is already not too bad
This is also a super easy thing to do with just a small POSIX shell script. Delete everything that is excluded in-place, or copy everything that is not excluded to a target dir.
I don’t entirely agree with this. I think the main reason why academic don’t adopt Typst for publications is simply that they don’t want to, and don’t have time to. To begin with, not everyone uses LaTeX, most of them rely on Word.
People tend to stick to the one thing they start with, without necessarily wanting to switch to another tool. “Don’t break what works” after all… There is a significant cost to switching from one tool to another, and people simply don’t have the time to do so. The fact that publishers don’t publicly[1] accept Typst source files is just the final nail in the coffin.
One reason why people use Overleaf so much is that it is a complete suite that provides all features needed for writing a paper: bibliography, templates, and collaboration features. Additionally, they provide a very thorough “How-to” section on their documentation. Related: How about a task force to generate a better documentation? - #4 by owiecc
I do agree that Typst should be more stable, probably people won’t even take a look if there is no major release yet.
).