Discussion: Lobbying for Typst adoption by publishers

General
1

Hello everyone,

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:

  1. Who should take the lead? Should lobbying be coordinated by Typst maintainers, or is it something the community can take part in collectively?
  2. 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.
  3. Should we approach publishers one by one, or aim for coordinated outreach across multiple venues at once?
  4. Are there already initiatives or internal policies about these matters that we should be aware of?
  5. 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 :wink:

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 :cry:).

Looking forward to hearing your thoughts!

5 Likes
2

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.

9 Likes
3

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.

2 Likes
4

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.

5

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.

2 Likes
6

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.

2 Likes
7

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 :slight_smile:

8

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.

1 Like
9

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.

  1. some of them might accept a Typst source file if directly asked, up to the editor I guess ↩︎

7 Likes
10

I wonder if the main driver for Typst adoption necessarily is academia and publishing houses of science papers. Typst is a general reporting tool for all types of reports and adoption may come actually more from industries, who need to create PDF output on a large scale (from their tools).

3 Likes
11

In my field (machine learning), it’s common to only have to submit the PDF, without needing to submit the LaTeX source. Getting the organizers of such venues in board (with some officially supported Typst style files) night be a best first step.

That said, I agree with the other commenters that Typst is too unstable right now. I think that kills off any hope of adoption from those venues requiring the source.

12

I manage some journals in mathematics, but we are a tiny publisher. Microsoft word is almost unheard of in that field. arXiv has an escape valve in that they accept PDF, but most publishers can only do that if they charge a huge fee to publish. Springer and Elsevier can get away with it because they charge exorbitant fees to publish a paper. Smaller publishers like us (particularly diamond open access publishers) cannot eat the cost of doing manual conversions. Automatic tools like pandoc produce only approximations.

In our pipeline, we allow authors to upload their LaTeX source, and we compile it in the cloud using a standard texlive distribution. This can sometimes fail if an author is using a different distribution, but we just push back on the author to fix it and they are able to do so because everyone has a frame of reference for a standard distribution. Our workflow also does some automatic analysis to identify copy editing issues. In total we spend about 5-10 minutes per article. We would never accept just a PDF because the workflow is much more involved than just slapping a PDF on a website. Many people seem to not understand how important metadata is in the publishing landscape.

I recently looked again at the problem of accepting typst from authors, and we could probably make it work. One requirement would be that compilation should work offline, so we would have to install all typst packages in our docker environment. It’s unfortunate that the typst universe does not seem to have a distribution process. That was one of the things that Norbert Preining mentioned in his talk. Perhaps it’s just too early in typst history to start doing this.

8 Likes
13

Thanks for sharing your perspective, it’s very interesting.

A clone of the typst/packages repository could serve as distribution… Or is it a problem with the size on disk? The whole preview directory is 4.5GB but a Python script to remove all the “excluded” files (which are not distributed to users) brings it down to 2.6GB. That’s quite smaller than a full TeX Live (7GB) but maybe you don’t use that either.

I think I remember someone who was in the discussion after Norbert’s talk mentioning that it turned out packages were maybe not a big issue after all, since a Typst file always specifies which version of a package it’s using (and a clone of typst/packages will make all versions available to the Typst compiler). It seems to me that a typst/packages clone together with a specific Typst compiler version is functionally similar to a TeX Live distribution but maybe I’m missing something.

3 Likes
14

That was probably me; yes, I hope I don’t misrepresent the content of this discussion when saying that explaining how getting packages from Universe works made it seem more manageable.

If I’m not mistaken, a TeX Live distribution only contains one version of each package, right? So a paper uses the package, and if the distribution between author and publisher is not matched, the result may be unexpected. That is fundamentally not a problem with how you use packages in Typst.

What can be a problem is compiler and font versions, which are not specified by the document. The compiler could be fixed by the publisher; authors can simply check what version of Typst is required. For fonts, another user fixed a missing font problem by installing the texlive-fonts-extra package. Maybe that could be used as the basis for fulfilling the “distribution” requirements re having the right fonts installed.

1 Like
15

We don’t include a full texlive distribution in our docker file, but that’s only because we know of some inconsistencies of our cls files with existing packages. One thing that isn’t clear to me is how to test that packages can be used with each other. overleaf does not automatically upgrade to the latest texlive distribution. as of this date (Jun 19 2026) they are not using texlive 2026 because it has not yet passed their test procedures. texlive 2026 was released in March 2026. Similarly, arxiv is not yet using texlive 2026 yet. I assume this is because they want to attempt compiling all of their old papers to see if they still compile. Backward compatibility is very important to the TeX community.

16

If I understood Norbert’s talk correctly, he said (beginning at 6:24) that arXiv simply runs all the old distributions. Each paper is tagged with what distribution it should be compiled with, and that continues being used even when new distributions come out.
I would expect the same approach to be applicable to Typst: declare that a certain compiler and texlive-fonts-extra version combination is a “distribution”, and then use that for all papers that declare to use that distribution.

If the concern is that this bespoke distribution definition is not desirable, I understand that. I’m just saying that I think something like that could be the solution. Maybe arXiv’s Typst adoption story will result in some more officially sanctioned distribution definition that publishers can reuse.

I probably don’t know enough about how LaTeX does things here, but wouldn’t it be the TeX Live maintainers who would have to check package compatibility before doing a release? And isn’t the existence of mutually exclusive packages, while annoying, generally acceptable?
For example, codly and zebraw are both packages for formatting raw/code blocks. Using both would not make sense (unless you make sure that each code block is only affected by one of the two packages; in principle, that is feasible with Typst). But a distribution would still want to support both, since a paper author could choose either.

17

I’m not a typst expert (I’ve barely glanced at it). Like many old timers, I’ve used LaTeX for four decades (egad!). A good example of where the TeX community has struggled is in how to manage the hyperref package. This was historically implemented as a hack to manipulate internal pointers to different parts of the document, but this has also caused a lot of incompatibilities (e.g, with cleveref). hyperref has always said it wants to be loaded last because it wants control over the namespace. cleveref is an example of a package that demands that it be loaded after hyperref. This reflects a core weakness of the TeX macro model that there is a global namespace that everyone is fighting over. As part of the LaTeX modernization effort (including accessible PDFs), parts of the hyperref package are being brought into the kernel. That may reduce the conflicts in the future, but in the short term there are always lots of conflicts between packages. Another example is that package A depends on package B, but package B disappears or changes their behavior. kaboom, but it may only show up in how an author uses the packages.

Most of these details are not particularly relevant to the typst ecosystem because typst doesn’t suffer from the global namespace problems. On the other hand, it’s still possible for typst packages to clash with each other (e.g., in their #show implementations at the layout phase, or if packages have different version dependencies, or the definition of slice() changes). These problems are not unique to typst - just take a look at python package management for example. One thing I know for sure - we absolutely will not use dynamic fetching of “the latest release” of a package at compile time.

I’m optimistic for the future, but the packaging issue remains as a yellow flag for me. LaTeX is now a slow moving infrastructure, but that’s actually a good thing for consistency - both for authors and publishers.

18

Yeah, this all makes sense. Since Typst has no global state at all, “loading” a package will never conflict. As far as show rules that may conflict go, it is in theory always possible to scope them in a way that they don’t interact – but that would often mean going off the beaten path, so in practice it may not be as reassuring.

Two things that are global are state keys and introspection results; state keys can be chosen to avoid conflicts, but introspection-based conflicts could be potentially unavoidable.

B changing behavior and thus breaking A can’t happen in Typst, since published package versions can’t be changed and imports always include the version; packages also can’t be unpublished. I guess a potential case where that could happen is if the package contained infringing content and Typst was legally compelled to remove a version; otherwise, all published packages on Universe are required to be open source, meaning the author has no legal ground to demand their own package being removed (Typst has an irrevocable license to publish the package, and so does anyone mirroring the packages).

What can still happen is that A depends on B v1, while the document also uses B v2 directly, leading to undesirable results when combining A and B directly in the document (common real-life example would be CeTZ and Fletcher interacting). So Typst is obviously not immune to all dependency problems, as you mention.

I don’t think anyone is suggesting that; Typst doesn’t even support using “the latest release” of a package anyway. You always have to specify the package version, no exceptions and no plans to change it.

2 Likes
19

Right but I don’t think this kind of issue is a concern for the publisher? The author can have a problem while developing their figure if it mixes Fletcher with CeTZ using a different CeTZ than Fletcher itself is using. But they will have to deal with that themselves. When they submit their paper with a working figure, there’s no risk that the publisher would break it by using a different CeTZ.

20

Yes, I totally agree, but I also don’t see any problem with Typst’s package system at all when it comes to what a publisher needs. Since I don’t know enough about publishers’ needs, and there are at least perceived problems, I wanted to proactively list the pain points that the package system has, in case these are relevant. I feel that these problems are for authors to solve, but maybe it looks differently from a publisher’s point of view.

In the end, if we want publishers to feel comfortable supporting Typst, we need to alleviate their concerns. So @Kevin_McCurley, I’m glad you’re here and listed some. I would hope that we can find specific points on which Typst can improve.

Right now, I’m fairly confident that fonts are an area that limit’s Typst’s determinism: Typst largely depends on using system fonts; a publisher would want to --ignore-system-fonts --font-path ... to fix this, and authors would need a simple way of getting an environment that reproduces what the publisher uses. In other words: I feel a “distribution” needs to include these fonts, and only use those by default.

Likewise, the compiler version obviously affects the output, so the compiler, using a specific version, needs to be included in a distribution.

I don’t see that problem with packages. Packages published to universe

  • are imported by version,
  • versions can’t be changed,
  • versions can’t be removed.

That means, changes to Universe never break a package – not directly, not transitively. Among the concerns that have been brought up:

  • “how to test that packages can be used with each other”: in my view it would be the authors’ job to use packages that work to produce their document, as part of the writing process.
  • “Backward compatibility is very important to the TeX community”: at least arXiv achieves that by keeping old distributions around, which could be done for Typst too. For Typst the situation would even be slightly simplified, because the package archive can be shared between all distributions; older ones would just not give access to all packages.
  • “package A depends on package B, but package B disappears or changes their behavior”: impossible due to versioned package imports and all packages being open source, hosted by Typst.

So as far as I can tell – but I could be missing something, I’m not a publisher – we’re already at the stage where we know what needs to go into a distribution, we’d “just” need to produce one. But I feel the distribution would need to be backed by the Typst team, so that publishers trust it, and the Typst team probably wants confirmation from publishers that this is what they need. so that’s the stalemate I feel currently.

5 Likes