What is the most efficient typst workflow for collaboration and publications

General
1

While we wait on journals and preprint servers to start accepting typst files (as well as reach more and more users), I am wondering what folks are doing to make their manuscript writing/collaboration more efficient.

What is required for a manuscript submission (e.g., in mathematics, physics domains) is

  • Collaboration between authors including track changes and margin comments.
  • Use a journal’s supplied Latex style file and macros to write the manuscript.
  • Submit your document as a Latex file upon acceptance.

Now if my collaborators don’t know Typst (or md for that matter), then the options are Word, G Doc, and Overleaf, with Overleaf being the preference for easy Latex. But I don’t want to use clunky Latex.

So how do I use Typst, my collaborators use Latex, can have margin/comments and track changes, be able to use supplied style files, and ultimately produce a Latex file for submission. I don’t think a solution exists here (with the main issue that folks don’t know how Typst, otherwise we’d just use the Typst online platform).

1 Like
2

You’re right. Typst is easy to learn in minutes, but study well and move workflow from LaTeX to Typst may take quite some time.

When different co-authors use different pens, how to compose a single article?
Well, you have to choose one as the main from Word, LaTeX, Typst…

I can tell that Typst is the best choice, 'cause

  1. incremental, no re-compile from blank
  2. fast, compile pdfs at average over 10x than fastest LaTeX
  3. easy, learn in minutes and migrate from LaTeX in a month (then u have to teach ur co-author about the new pen)
3

Thanks, but there are a few more issues.

  1. My coauthors may not know Typst and therefore creates a learning curve for them. This isn’t particularly that big of an issue, but everyone is busy and I personally would like the work done faster.

  2. The other, more serious, issue is that the journal we are targeting provides its own latex macros as well requires a latex file for submission. So even if I use Typst to write the initial draft, there is going to be some work involved at the submission stage. I recognize there is probably no solution for this 2-language problem right now, but was hoping to get some ideas from folks.

1 Like
4

There has been a talk on a project called ttt for converting from Typst to LaTeX during the last Typst meetup: https://www.youtube.com/watch?v=8nH8epm7jpY

Maybe that could be a solution for your problem :)

1 Like
5

My colleagues and I have been using Typst for writing internal documentation for nearly a year and a half now. We have a private GitLab instance, where each document is in its own repo (usually a fork from our custom document template repo). Each person edits locally and then GitLab CI builds the PDF and publishes it to GitLab Pages (basically Alpine Linux image with typst compiler install + required fonts) when edits are pushed to the repo.

For cases when documents need to be shared with external collaborators for comments, we just make the GitLab pages public while keeping the document source private.

While so far we have continued to use LaTeX for journal submission, for my next paper, I intend to submit a Typst generated PDF for the initial round, and then convert to LaTeX only after editor consideration/first round of referee review.

1 Like
6

Having worked with co-authors on mixed-typography papers (Word and LaTeX, even Google Docs and Word, etc.), I’d say it sounds like you’re setting yourself up for a world of pain. Converting things back and forth between LaTeX and Typst for your co-authors with each round is going to be painful and error-prone.

If you can convince your co-authors to work in Typst, you can manage the conversion to LaTeX at submission time with (usually) minimal pain; but if you can’t, I’d probably just stick with Overleaf until you can recruit more people to the Typst-train.

3 Likes
7

Computer Scientist here, with 5 years experience as a Systems Administrator. Collaborative authorship is one of those hard-to-solve problems. git was invented for source code collaboration, where all code is text. I know everyone is eager to use git for anything and everything, but it was never meant to store binary files such as .pdfs. “Binary” here is Unix-speak for “files which are not plain text files”

I suggest you don’t output to .pdf until a text is finished its draft phase. Like the final .pdf is just that - a final step. Not done all along the way.

Here’s an inelegant, but experience-informed method I would use. As to collaboration: if a paper is very long - too long for an Office suite like LibreOffice to handle without bogging down - then create several LibreOffice files, one per chapter. So a lot of familiar WYSIWYG is leveraged for fast content creation, at first. Formatting is not cared about, or done in the LibreOffice chapter files - that will be Typst’s job later. But what LibreOffice can do is annotate with comments, as collaborators see what they like and don’t like.

Each collaborator agrees to a filename convention, where a version number is appended on the end. There can be many versions of such a chapter file. our_essay_ch01_v01.odt, our_essay_ch01_v02.odt, etc. Don’t delete the old versions. One possible example might be: one collaborator might make even-numbered version files, and another makes odd-numbered version numbers, as they “hand over” control of edits, back and forth.

If you want to get more serious, consider storing the files on a server in a filesystem which has native snapshotting, like BTRFS, using a snapshot tool like “snapper”, to make periodic snapshots of these files.

So how do these LibreOffice chapter docs get shared around for collaboration? You might be tempted to share them around by email. You can do better. There are many good possible filesharing methods, which have privacy built-in (where you retain custody and ownership of all the files):

  • CopyParty
  • SFTP (in an SSH server)
  • Syncthing, if everyone using it is a geek
  • a Deltachat group

I have expertise in all of these (setting them up in a LAN, or in the cloud) and more. Of course, Typst Gmbh also has their own cloud offering as well.

1 Like