28

Recently I have become increasingly anxious about LaTeX being (possibly) surpassed by Typst due to its simplicity. This answer shows several edges of Typst over LaTeX.

I have been arguing with one of my classmates about why I still choose LaTeX over Typst:

  • The typesetting quality of LaTeX is superior (though Typst is quickly catching up)
  • I love TikZ, while there is no counterpart in Typst (actually there is now CeTZ)
  • CJK support in Typst is poor, while XeLaTeX and LuaLaTeX handle CJK fonts well (I think they will fix this soon though)
  • Maths in Typst is awful, LaTeX has already set the standard
  • Actually, since I am used to LaTeX, I do not want to switch to Typst :-(

However, I have been stricken with some facts:

  • Macros in LaTeX are not as convenient as actual programming, even though there is LaTeX3 to mitigate the issue.
  • Compilation of LaTeX documents can be slow, compared to Typst using Rust.
  • Easier syntax of Typst will make people more inclined to learn Typst instead of LaTeX. LaTeX has many packages (and some even conflict), which can be very confusing to learners.

I have seen some of the changes made within the LaTeX community, including tectonic rewriting LaTeX using Rust.

So what is the plan of the TeX community to keep TeX/LaTeX this beautiful language continue flourishing? I am eager to learn more and wish to contribute.

22
  • 10
    Sorry, but this is clearly opinion-based.
    – cfr
    Dec 18, 2023 at 6:01
  • 2
    @cfr Is the future plan of the TeX Community an opinion?
    – CarLaTeX
    Dec 18, 2023 at 6:34
  • 2
    @TeddyvanJerry Is Typst free? Will it be always free?
    – CarLaTeX
    Dec 18, 2023 at 6:36
  • 3
    @TeddyvanJerry the first obstacle to overcoming LaTeX is overcome, then :D
    – CarLaTeX
    Dec 18, 2023 at 7:07
  • 3
    See this. mostly about context but applies equally to typst, as noted in a final paragraph tex.stackexchange.com/a/686451/1090 Dec 18, 2023 at 9:09

4 Answers 4

31

Well at first I would be rather wary about the "easy" and "fast" claim. 10 years ago I answered a question about how Word differs to LaTeX with

Yes, you can do most normal things without problem (and sometimes faster or easier) with Word. But what about slightly "unnormal things"?

typst is "modern" which is another word for young. When it started it couldn't even do rather normal things like footnotes, floats, bookmarks, double page layouts, form fields or PDF comments. And while some of them are now implemented they still lack many of the configuration options that exist in LaTeX or supporting packages. An current example is this discussion about how to get something as basic as a \pageref in typst: https://github.com/typst/typst/issues/2873.

It is easy to do easy things in an easy to learn syntax and I quite agree that # my chapter is a nice, short way to create a heading (but the LaTeX syntax \chapter{my chapter} isn't long either), but the question is what happens if you want more complicated things. Is there an intuitive syntax for an unnumbered section? How can you adapt the entry in the toc or the header? Is that built-in or does it require to find and copy ten or more lines of code like for the pageref in the issue quoted above? Will typst stay easy to use once it gets more mature and gets feature requests about more sophisticated document features?

At second I'm quite distressed that a "modern" system like typst doesn't support PDF accessibility features from the start on. Accessibility may not matter for private documents but anyone writing for some organization will have to consider this topic soon. The typst authors knew that and they knew that they need the structure data for a tagged PDF but nevertheless wrote their compiler so that it looses them: "Since the frames currently only contain locators and not a full reverse mapping to the document’s structure, the exporter cannot write this structure information." They claim that they are in a good position because there is quite a lot of semantic information available, but LaTeX has the semantic information available since 30 years and that doesn't make it easy to produce accessible, tagged PDF.

If I had considered to write a typesetting engine from scratch (which I wouldn't as I believe that large systems should be changed by evolution, not by tearing down and rebuilding -- you can't move all inhabitants of a city out while you redesign it from scratch), then I would have made sure that the core design considers accessibility from the start and not add that as an afterthought. That they missed this opportunity makes typst in my eyes very unmodern.

6
  • One should also note that syntax issues could also be resolved using a precompiler it one is more fond with using some kind of "markdown" style. But, as you said, more complex things are most likely hard to code in a simplistic syntax. Dec 18, 2023 at 10:55
  • 5
    @JasperHabicht yes, and you can even do it with luatex "inline", see e.g. the markdown package. But generally I'm not a fan of lots of syntactic sugar. At the end the time you save because you have less to type is spent on understanding the clever parsing rules and figuring out how to handle various edge cases. Dec 18, 2023 at 11:11
  • 2
    ‘how to get something as basic as a \pageref in typst’ — as far as I can tell, the link already provides a way to get a \pageref in Typst, and the discussion is purely about whether to include that function in the standard library or not.
    – bradrn
    Dec 19, 2023 at 6:33
  • @bradrn exactly. Something that is in LaTeX since more than 30 years is here still an open discussion point. That shows how young that is. (And I find it curious that they even consider to ask from their user to add 10 lines of code to get that.) Dec 19, 2023 at 7:19
  • @UlrikeFischer My experience with LaTeX is that I often need to add far more than 10 lines of code to accomplish what I want. Indeed, that is precisely why I use LaTeX — because it’s extensible and flexible. And it is that same extensibility which makes me consider Typst to be the first serious competitor to LaTeX in a long time.
    – bradrn
    Dec 19, 2023 at 12:53
17

As someone who’s also writing a LaTeX replacement, I think that it would be a good thing for LaTeX to be superseded by something in the future. Programming in TeX macro language is a mess and a commitment to backwards compatibility means that progress is slow if not impossible (I still think that it was a gross mistake to fold LaTeX3 into an evolving LaTeX2e rather than take advantage of a major version number to break backwards compatibility.

My prediction is that LaTeX’s successor, should it ever arise, will retain the markup of LaTeX but eschew the macro-based programming model. Authors need to be able to transition with little friction. I don’t think anybody would mourn the death of the fragile LaTeX macro system. Just because TeX is Turing complete doesn’t mean that it’s the best way to do things or even a good way.

Things I would expect to see would be versioning of packages and document classes (or their equivalent) so that nobody will be surprised when CTAN updates a package three dependencies deep and their document no longer compiles. Also, there’s no reason in modern computing systems why multiple runs should be necessary to manage things like references and citations. A single application would be able to handle the capabilities of LaTeX, BibTeX, makeindex etc.

I also kind of feel that rather than writing, e.g.,

\documentclass{amsart}

the better approach might have been to do something like

\DocumentStructure{article}
\DocumentFormat{ams}

or better still:

\DocumentStructure{article:1.0}
\DocumentFormat{ams:ams:1.0}

where we have not only version numbers but namespaces as well so that there’s not that continual worry about crashing into each other’s file names.

Finally, I would propose that external dependencies to the document would be automatically downloaded if a local copy doesn‘t exist so that the core distribution no longer is quite so cetacean in size.

7
  • 2
    I agree with the last sentence. For the rest, you can already compile with one run with arara or latexmk.
    – CarLaTeX
    Dec 18, 2023 at 6:57
  • 2
    For the last sentence this is also already possible with texliveonfly for TeX Live and built-in for the MikTeX package manager. Also disk space and high-speed internet is cheap nowadays so a gigabyte more or less is not really an issue for most users.
    – Marijn
    Dec 18, 2023 at 8:36
  • 1
    You make some good points, but it is possible to do [format=ams]\documentclass{myclass} now. Versioning can also get you into trouble in many other ways, versions disappearing from distributions and bloating them up. Maybe with a preporcessor (no need to be in the format) or this pre-processor can be hidden from the user.
    – yannisl
    Dec 18, 2023 at 8:49
  • 1
    Another point I would like to mention is semantic versioning. LateX stayed at 2e, as it is still compatible with older versions. According to semantic versioning it should go to LaTeX3.0.0 once it makes a change breaking older compatibility. we will then all throw a big party!
    – yannisl
    Dec 18, 2023 at 9:11
  • 1
    I recommend reading up on the disaster that was Python 2 -> Python 3 migration, or Perl 5 -> 6 (which effectively was abandoned), etc. -- it is always easy to say "let's just break compatibility to benefit from some cool breaking changes", but in reality if this is not thought out very well it usually fails. At the very least make a plan that allows the ecosystem gradually/incrementally; that would include allowing to have packages that support both 2e and 3 so that one avoids the usual chicken&egg problems during migration...
    – Max Horn
    Dec 19, 2023 at 17:03
12

The greatest disadvantage of typst and I think a grave design mistake, is that is not compatible with LaTeX. What does one do with large volumes of existing documents, archives etc? Throwing everything away and starting from scratch? I have been using LaTeX since its inception, that is almost 40 years now! Milestones in improvements were the use of Laserjets (adapted quickly), pdfTeX, babel, now the l3 layer, LuaTeX, PGF/Tikz, BiblaTeX, microtype.

TeX/LaTeX's markup language, will endure and last, probably longer that many of the older generation that we are still using it. As anyone that read the Dragon book will tell you, is not easy to come up with a compiler that picks up commands and parameters from a sea of letters around it.

Can it get improved? Yes! Areas in my opinion that can be improved:

  1. Automatic replacement of glyphs that are missing in fonts, similar to what web browsers and IDE do. This can be achieved currently with LuaTeX/LuaLaTeX with fallback fonts, but it gets painfully slow.
  2. Programmable output routines. Defaults should be built into the TeX engine itself.
  3. Many of the problems with conflicts in packages come from hyperef. A new mechanism should be designed, enabling authors to use links, easier, rather than depend on the package. The base classes, can be modified to incorporate this, so no need for hyperref to redefine all the sectioning and referencing commands. Incorporate this into the format.
  4. Handling of Indic and east Asian documents, can be improved by contributing to haffbuz and LuaTeX. There should be no need to load a package to change a language.
  5. Creation of virtual fonts can be improved.

To all those trying and developing different systems, thank you, competition is good and wish you good luck. I was looking the other day at some stats and noted that between the l3 and LuaTeX some 130,000 loc were added onto what is loaded in a run. the original TeX had some 20,000 loc. Maybe some efforts to improve the engines themselves to handle some of the areas that are problematic, will be easier and more useful than re-writing everything form scratch.

3
  • we are working on integrating hyperref features into the format. For example label and ref and contentsline are now in sync. But beside this I'm not aware of "many conflicts" with hyperref, and if you have a concrete example you should open an issue or ask a question. Dec 18, 2023 at 9:55
  • @UlrikeFischer Thanks. I am aware of the changes but I haven't looked hard to check the revised code. On "many conflicts" just consider as to why we need to load it last. What I was saying is to expose an API in hyperref, use it in the standard classes and be done with it, it shouldn't overwrite any commands outside its concern . See for example recent changes in doc and l3doc, there shouldnt be a need for hypdoc!.
    – yannisl
    Dec 18, 2023 at 10:19
  • 1
    you do not need to load hyperref always last. Actually lots of documents load it earlier nowadays and e.g. I recently changed the amsmath code to make it independant from loading order. But mostly the problem is not hyperref but the other packages. If I come across a package which conflicts I try to convince the author to adapt and to make direct use of existing interfaces but not everyone reacts. (and you are quite right hypdoc should disappear, but as it is mostly meant for documentation and basically works, this has not the first priority.) Dec 18, 2023 at 10:33
2

Without knowing concrete plans from the Latex community we can anticipate future development of both Latex and Typst to some degree, reusing 2 scientific findings.

This moves us away from a look at concrete plans or speculations to a sound more global view.

Law a requisite (minimum) variety (complexity)

This goes back to W.Ross Ashby, who is amongst the founding minds of cybernetics. He stated, partly in my words:

  • to deal with complexity
  • the regulator/controller has to be at least as complex;
  • regulation fails with undercomplex regulators
  • especially with noise (disturbances) involved.

Ashby's example

In his "Introduction to Cybernetics", 1956 he uses a temperature controller to illustrate his basic equation and considerations.

Basically it states:

  • within a normal range of environmental temperature variation the controller works fine
  • however, with very disturbed weather conditions it fails, as it simply can't compensate the change any longer.

See e.g. here (a simplified chapter), or here (Wikipedia on Variety) or here (in his book, cited above).

variety-wikipedia

My illustration

Let's think of a simple railway. One track, one train, no problem. The train goes back and forth all day long.

Let's increase complexity (C+) step by step in response to ever increasing disturbances (D+).

D+: Put a second train on the same track. Now problems start, as they hinder each other. As a solution we need to increase complexity of the system.

C+: Let's introduce a time table, which regulates, which train goes where, when, how often etc. This may be fine for many situations.

D+: Riding both trains has become more popular, and people start being annoyed by having to change trains all the time, just to go from one end to the other.

C+: Let's add a rail switch, so both trains can pass each other. Let's adjust the time table.

And so on. We all know the state of complexity railway systems achieved by today, like:

  • often having at least two tracks per direction
  • having many tracks at or near certain stations
  • offering a variety of trains
  • using signals of all kinds
  • providing many different kinds of railroad crossings
  • having digital twins of "what's happening outside"
  • etc.

Simplify, like economic controllers tend to do, and someone pays a price. (Dead end)

Invent, and get both: simpler AND complexer. (Innovation)

Where the later is a summary of the work of the inventor of (intention) "Innovation as a Science", Genrich Altshuller. (TRIZ, russian accronym, my translation by meaning: a practical Theory to Resolve Inventive Zituations)

What does this mean for Latex and Typst ?

We all know: Latex IS complex. Or in Ashby's view: it does cope with a lot of variety/disturbances. It matured to a high level of typesetting ... and still is, see here.

By its very development Typst still is in its so called infancy state. It started out with a certain concept in mind, offering a still limited number of typeset outcomes, and it will evolve further, as any technical system,

  • from contradiction (roadblock, trade-off: this EXOR that)
  • via a solution (system change, exact solution: this AND that)
  • to contradiction (next roadblock).

As many people stated, Typst IS simpler, and is intended to be so. Which does translate into:

  • Typst is less complex than Latex
  • Latex can handle more disturbances/variety/requirements than Typst for now, and perhaps will so for a long time
  • to catch up variety offered by Latex, the Typst ecosystem (syntax, compilers, packages, libraries etc.) has to become more complex, has to be able to absorb more requirements/variety

So in consequence it will probably:

  • be easier to come up with Latex2Typst translators (getting rid of variety)
  • be tough or almost impossible to come up with Typst2Latex translators (adding variety/complexity) (in contrast to just storing in a latex file format)

My conclusions and estimates (having been achieved future)

For the near future I expect Typst to be and to remain Yet Another Markup Language, while Latex will continue to support typesetting ...

Some links between the two (called translators above) will come and go.

There may turn out to be a useful (quite large) subset of Typst, which can be absorbed (provided) by Latex.

The opposite, at least conserving complexity from typesetting, probably will never reach a useable state.

2
  • 3
    Nice metaphors, the only thing I don't quite understand is your point about it being easy/hard for Latex2Typst and Typst2Latex. Since Typst is the simpler system, wouldn't Typst2Latex (taking typst code and converting it into latex code) be easier, similar to how currently Markdown2Latex is easy to do but the inverse is impossible without losing certain things (like colored text for example)?
    – Marijn
    Dec 18, 2023 at 13:29
  • Thank you. // That's what I tried to express. Translating, or better converting, Typst code into corresponding Latex code should be possible, while, say for a book-layout, representing typesetting from Latex as Typst statements will be hard to impossible. It's very similar to when all HTML-ers started to get some kind of WYSIWIG, which led to CSS, which added ... more complexity, and as a by-product, browser incompatability until today.
    – MS-SPO
    Dec 18, 2023 at 14:17

Not the answer you're looking for? Browse other questions tagged .