Is LaTeX worth it?

Introduction

While LaTeX is rightfully praised for its qualities, its (sometimes obvious) flaws are often ignored or downplayed. The learning curve is quite steep and its usability is far from optimal. Is it even worth it to learn LaTeX? What kind of work can we realistically get done using it? Are there alternatives? When do we really need LaTeX?

This post is aiming to provide a critical view, mainly highlighting problems and shortcomings. It is not meant as a fair assessment of the pros and cons. This is a rant; you have been warned.

To start the discussion I first want to go into my experience with LaTeX.

Perfect Typesetting Made Easy?

My history with LaTeX started over 10 years ago. I was fed up with WYSIWYG editors after working with Microsoft Word 2007 for a while. Images constantly jumping around, formatting randomly breaking when content changes and no easy way to manipulate the fundamental style of a document after its creation. “There must be a better way,” I thought. And a better way there was.

The Promise…

After looking around online I stumbled upon LaTeX which was praised as the perfect alternative to visual editors. The promise was simple. Don’t worry about formatting or typesetting, just worry about your writing! Design and content are separated and defaults are not just sane, but virtually optimal.

Obviously, I started learning LaTeX and started using it for everything. School work, letters, applications, CVs, presentations, later university work, random manuscripts, software documentation, white papers and any other kind of written document. Why use an visual editor to create diagrams when there is TikZ? Why worry about using proprietary editors when LaTeX distributions are open-source, cross-platform and you can use any editor you like?

It seemed to me that LaTeX was the ultimate way of constructing any document. Why learn different document editors or even a publishing software like InDesign when everything can be done with one unified interface?

…meets Reality

I woke up from this dream when I tried to design a quote template for a small business I had. Designing a document with an address section, small table and some bank details in its footer that didn’t look pretentious was almost impossible. Changing fonts families and sizes? Changing spacing in a table? An utter chore.

At this point I tried something new and redid the document in LibreOffice Writer. It looked much better… and was done in a fraction of the time even though I had virtually no idea how to use Writer.¹

Of course, this was only a small setback in my journey. My first real dissatisfaction arose when using LaTeX for its intended use case: Large documents. While writing both my bachelor’s and master’s thesis I have gotten to know the good and some of the bad parts of LaTeX quite well. I started noticing that the bad, annoying and productivity-destroying parts where harder and harder to ignore. However, I was still convinced that it is the best way to construct documents.

When starting work on my book, I was surprised that my publisher wasn’t using LaTeX but AsciiDoc. This obviously didn’t compute with me at first. However, after working with AsciiDoc for way over a year now it made me rethink many problems that an author has to face when using LaTeX. I want to highlight these problems in the following sections starting with my greatest pain point.

Handling the Syntax

The syntax of LaTeX is weirdly verbose yet unspecific, very expressive yet cryptic and, while trying to make the job of the author easier, a nightmare to type quickly. I think this is one of the major problems of adopting LaTeX for most people.

What Am I Reading?

The source of a LaTeX document is hard to read. By that I don’t mean the physical act of reading the letters on the screen but ascertaining the overall structure of a document just from looking at the source. A LaTeX document consists of many varied control structures that act interdependently. Some change the formatting, some change the font characteristics and many of them add completely new features. Every package that is added to the document adds its own commands and environments with their own rules. Reading something you haven’t written yourself is puzzling.

The readability is worsened by the absurd number of symbol control sequences present. You cannot simply copy an UTF-8 symbol from the web into your document. You cannot just type Wörds with umlauts and expect them to work. You want to include the € symbol? Well, that requires a special package import for it to work and you will have to write it like so: \euro{}. Every triviality has its numerous hoops to jump through.

It also doesn’t help that LaTeX mixes imperative and declarative styles in its language. While most directives work declaratively, like environments, others have to be used in the correct sequence. Examples for imperative directives are font sizes (\tiny, \Large, etc.), spaces (\vspace, \stretch, etc.) and fills (\hfill, \vfill). Font style (\textbf, \textit, etc.) is done declaratively, however.

This leads to bizarre syntax like this:

\Huge % Set text size to "Huge"
\begin{center} % Begin centering
  Title % Only this is centered
\end{center} % End centering
\vspace{10pt} % Add vertical space
\Large % Set text size to "Large"
\noindent % Do not indent the next line
\textbf{Lorem ipsum} dolor sit amet, % Set the first two words to bold
\normalsize % The following text is normal sized
consectetur adipiscing elit. % Just normal text

However, this can be cleaned up slightly by defining a scope for directives such as \Huge. We then end up with this snippet, which is not much better:

{\Huge % Begin "Huge" text size
  \begin{center} % Start centering
    Title % Only this is centered
  \end{center} % End centering
} % End "Huge" text size
\vspace{10pt} % Add vertical space
\noindent % Do not indent the next line
{\Large % Begin "Large" text size
  \textbf{Lorem ipsum} dolor sit amet, % Set the first two words to bold
} % End "Large" text size
consectetur adipiscing elit. % Just normal text

While this might be an artificial and exaggerated example it aims to highlight the inherent problem of the syntax. Each command needs to be evaluated based on where in the code it shows up and what it is surrounded by. For example, \noindent only works if there is no space between it and the next line.

\noindent % This works
I am not indented.

\noindent % This also works
% This comment doesn't count as a blank line
I am also not indented.

\noindent % This doesn't work

I am indented.

In complex documents it is simply not possible to accurately surmise how different directives act on the structure. The complexity is augmented by interdependence between packages leading to confusion on how they change the behavior of other packages like in this example:

\usepackage{hyperref}
\usepackage{cleveref} % Has to be loaded after hyperref!

hyperref is a prime candidate for this problem as can be seen here. This problem worsens when we take into account how code from different packages interacts. As a trivial example, one might look at problems that arises when using figures and the multicol package. To quote Overleaf:

Floats in the multicol package are poorly supported in the current version. Elements inserted with the conventional figure and table environments will show up only at the top or bottom of the next page after they are inserted, and will break the layout.

However, when the question of how included packages work is solved the problems are only beginning. Let’s look at bloated syntax for basic lists.

Verbose Environments

enumerate and itemize provide very simple functionality with inanely complicated syntax. Their job is to define a simple list, either with numbers or bullet points. The problem comes in the way they are written down. Every list has to be wrapped in a special environment.

\begin{enumerate}
    \item First
    \item Second
    \item Third
\end{enumerate}

This seems fine at first until you realize that in nested lists, you have to define an environment inside an environment and each subsequent sub-list has to have its own begin and end.

\begin{enumerate}
    \item First
    \begin{enumerate}
        \item First Sub
        \item Second Sub
    \end{enumerate}
    \item Second
    \begin{enumerate}
        \item Third Sub
        \item Fourth Sub
    \end{enumerate}
\end{enumerate}

In WYSIWYG editors writing such lists is easy, intuitive and can be navigated really quickly with simple keyboard shortcuts. In Markdown-like languages, it’s even easier.

* First
  * First Sub
  * Second Sub
* Second
  * Third Sub
  * Fourth Sub

The syntax for environments, be it for lists, text-alignment, figures, tables, code listings, and almost anything else is simply cumbersome. While configured editors can help with automatically completing the syntax it is still hard to edit existing constructs.

Error Proneness

Let’s look at what can go wrong with these environments:

 1\documentclass{article}
 2
 3\begin{document}
 4
 5\begin{itemize}
 6    \item Foo
 7    \begin{itemize}
 8        \item Bar
 9    % Missing end!
10\end{itemize}
11
12\end{document}

While trying to compile this, pdfTeX will tell us that an error occurred:

! LaTeX Error: \begin{itemize} on input line 5 ended by \end{document}.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

l.12 \end{document}

Your command was ignored.
Type  I <command> <return>  to replace it with another command,
or  <return>  to continue without it.

However, if you have configured your build chain to ignore such errors (or you are using Overleaf which does so by default!) you will get a result regardless. This file will be converted into a list that looks like this:

• Foo
  • Bar

This might not seem that bad at first. However, it becomes incredibly confusing once the error occurs in a larger document. What happens after we add another itemize environment after the first one?

 1\documentclass{article}
 2
 3\begin{document}
 4
 5\begin{itemize}
 6    \item Foo
 7    \begin{itemize}
 8        \item Bar
 9    % Missing end!
10\end{itemize}
11
12\begin{itemize}
13    \item Baz
14\end{itemize}
15
16\end{document}

What will happen now? Just from looking at the code, we might conclude that the second top-level itemize environment will start a new list. Sadly, this is not the case. While we will be presented with the same error as before, the result will look like this:

• Foo
  • Bar
  • Baz

Very confusing and a complete nightmare if such an error went unchecked in a large document. It does not help that the error message points us to the wrong itemize environment. The problem occurs for the environment in line 7, not in line 5. A beginner might be completely left in the dark when trying to figure out what went wrong with their document.

The Problem of Ubiquity

This problem is amplified by the fact that environments are used for practically everything. They are the main control structure in LaTeX documents. We cannot get around using them and we are forced having to work around creating large nested environment monsters. Luckily, we can define aliases for these environments or even wrap them in a simple command. Here is a little example for a command that creates a slide with two independently scaled images in a Beamer presentation:

 1\newcommand{\twoimageslide}[6] {
 2  \begin{frame}{}
 3    \centering
 4    \footnotesize
 5    \begin{minipage}[b]{0.45\linewidth}
 6      \centering
 7      \includegraphics[scale=#3]{Images/#1}\\
 8      #2
 9    \end{minipage}
10    \begin{minipage}[b]{0.45\linewidth}
11      \centering
12      \includegraphics[scale=#6]{Images/#4}\\
13      #5
14    \end{minipage}
15  \end{frame}
16}

And here is how it is used:

\twoimageslide{foo.jpg}{First title}{0.4}{bar.jpg}{Second Title}{0.6}

This can make working with environments slightly simpler. However, now all the complexity of environments is hidden away and might lead to problems laters. For example, what if a code listing (lstlisting environment) is used? It turns out you cannot just simply use that in a Beamer presentation without using fragile frames.

\begin{frame}[fragile]

This leads to completely incomprehensible problems later down the line. Custom commands and environments are inherently not portable without a lot of extra work put into them. While this might be a fine tradeoff for package authors on CTAN, it is a horrible cost for an author to bare. The portability issues get even worse when looking at document specific configurations.

Taking Control over Document Style

The pervasive promise of LaTeX is that the actual content and its formatting are separated. Here is a quote from the LaTeX-Project’s about page.

LaTeX is not a word processor! Instead, LaTeX encourages authors not to worry too much about the appearance of their documents but to concentrate on getting the right content. […] LaTeX is based on the idea that it is better to leave document design to document designers, and to let authors get on with writing documents.

There are two problems with this promise:

1. It’s broken in most documents
2. The author often is the designer

First, let’s take a look at the first point.

Package configurations

It is not uncommon to find code like this at the start of many LaTeX documents:

 1\usepackage{hyperref}
 2\hypersetup{
 3    colorlinks=true,
 4    urlcolor=blue
 5}
 6
 7\usepackage{listings}
 8\usepackage{xcolor}
 9
10\definecolor{codegreen}{rgb}{0,0.6,0}
11\definecolor{codegray}{rgb}{0.5,0.5,0.5}
12\definecolor{codepurple}{rgb}{0.58,0,0.82}
13\definecolor{background}{rgb}{0.95,0.95,0.92}
14
15\lstdefinestyle{code}{
16    backgroundcolor=\color{background},
17    commentstyle=\color{codegreen},
18    keywordstyle=\color{magenta},
19    numberstyle=\tiny\color{codegray},
20    stringstyle=\color{codepurple},
21    ... % many options omitted for brevity
22    tabsize=2
23}
24
25\lstset{style=code}

In the first five lines, the hyperref package is included and configured to use blue as its link color. The following lines define colors and a style for code listings.

This is the first break of our promise. Setting up packages correctly is not handled externally, but in the document the author is concerned with. Of course, these configuration could be put in a special settings.tex or preamble.tex file which is included in the main TeX file, but what if the author wants to add more packages?

The main problem here is that LaTeX files combine formatting and content. It does not work like HTML and CSS, where HTML is used for the structure and CSS is used for the style of a document. While LaTeX has its own style files (.cls and .sty) the separation doesn’t work as well, since these files are used to determine the structure of the content beforehand. This can be read about here:

In the ideal case, a class file will completely define the structure of the document. The familiar article class is a good example: it provides commands for typesetting articles, such as \section, \tableofcontents, \author and so on.

This means that our content files are inherently linked to predefined structure, making them not portable. Turning a normal article to a book, a book to a presentation, or a presentation to an article becomes cumbersome and forces the author to think about formatting and technical details.

Depending on how your file is later used, you as the author have to make sure that certain formatting is taken care of. Sometimes, page numbers have to be explicitly disabled (using \pagestyle{empty}) or the document is restrained to using a fixed selection of packages. This forces the author to write down content differently. For example, it makes a big difference wether listings or minted is used to support code listings and the author is forced to adhere to control structures of the used package.

In document preparation systems like AsciiDoc such features have a much more simple interface which leaves the actual formatting applied at the end to internal settings of the AsciiDoc processor; far away from the author.

The Designing Author

Outside of professionally published books, the author fundamentally has to worry about the design of their document. In doctoral theses, academic papers and presentations the author is tasked with making sure that the document looks good and readable. Even though LaTeX is very good at keeping a document readable, it cannot work wonders. Aesthetic decisions like line height, font type or margins and paddings around inserted graphics often need work and cannot be left to the machine to figure out.

LaTeX has mostly sane defaults for all of these parameters. Thus it is very opinionated. You can ask it nicely to put a figure at a certain position in the document but without some work the typesetter is allowed to simply ignore your request. Manually overriding these decision makes the source even more unreadable and much harder to deal with.

One way of taking control over the document is overriding macros like \baselineskip or \parskip to change the general look of the document. Another method is using \vspace and \hspace to add (or even remove) space around certain elements.

The disadvantage of these methods is that the otherwise sane defaults now break down completely and the document becomes as fragile as your average WYSIWYG editor experience. Now, we are once again forced to take the imperative document style into account, carefully evaluating when certain parameter changes hold true and when they don’t. At this point the syntax of LaTeX makes it hard to figure out what is shown and the complicated logic running in the background make it almost impossible to gauge how anything will look. It is this point where the clear advantage of applications such as LibreOffice Writer, Microsoft Word or Adobe InDesign become apparent. LaTeX simply isn’t made to design anything. If you don’t like its defaults you are simply out of luck.

Beamer Presentations

Beamer presentations are ugly. They are so, so ugly. Just look at the default themes. They are pure visual clutter. Useless progress indicators at the top, redundant information at the bottom, horrendous colors, ugly skewmorphic balls for bullet points, drop shadows from the 2000s, weird interactive navigation elements, which most people deactivate anyways; all of it is awful.² Every fiber of my body screams in agony when I have to look at those ugly, ugly slides. Using Beamer never felt right to me. The presentations simply never looked good, no matter how hard I tried.

It seems that I am not the only one that tried. A quick look at the template collection on Overleaf shows how many institutions and authors tried to make Beamer look good. It cannot be a coincidence that most templates look like a stock template with an adjusted pallette. As was already discussed, changing the design in LaTeX documents is hard.

I also tried my hand at creating a better presentation from the default templates. When I was still in university I played around with a minimalist approach to presentation design, which was the only time I felt productive working with Beamer. My solution to the design problem was to restrict myself to a fixed number of slide types:

• Single image + caption
• Two images + captions
• Centered title
• Equation
• Quote

Then I could write commands that got the design of these slide types exactly right and applied the design rules to the content. The presentation looks like this and here is the (poorly formatted³) source for it:

  1\documentclass[11pt]{beamer}
  2\usetheme{Boadilla}
  3\usepackage[utf8]{inputenc}
  4\usepackage{amsmath}
  5\usepackage{amsfonts}
  6\usepackage{amssymb}
  7\usepackage{varwidth}
  8\usepackage{graphicx}
  9\author{Philipp Hagenlocher}
 10\title{Fermats letzter Satz und Andrew Wiles}
 11\setbeamercovered{transparent}
 12\date{12. Januar 2019}
 13
 14%gets rid of bottom navigation symbols
 15\setbeamertemplate{navigation symbols}{}
 16%gets rid of footer
 17\setbeamertemplate{footline}{}
 18
 19\newenvironment{titleframe}
 20{
 21\begin{frame}[plain]{}
 22\LARGE
 23\centering
 24}
 25{
 26\end{frame}
 27}
 28
 29\newenvironment{citext}
 30{
 31\begin{center}
 32\begin{varwidth}{0.925\textwidth}
 33}
 34{
 35\end{varwidth}
 36\end{center}
 37}
 38
 39\newcommand{\grame}[3] {
 40\begin{frame}{}
 41\centering
 42\begin{minipage}[b]{\linewidth}
 43\centering
 44\footnotesize
 45\includegraphics[scale=#3]{Images/#1}\\
 46#2
 47\end{minipage}
 48\end{frame}
 49}
 50
 51\newcommand{\gwome}[6] {
 52\begin{frame}{}
 53\centering
 54\footnotesize
 55\begin{minipage}[b]{0.45\linewidth}
 56\centering
 57\includegraphics[scale=#3]{Images/#1}\\
 58#2
 59\end{minipage}
 60\begin{minipage}[b]{0.45\linewidth}
 61\centering
 62\includegraphics[scale=#6]{Images/#4}\\
 63#5
 64\end{minipage}
 65\end{frame}
 66}
 67
 68\newcommand{\trame}[1] {
 69\begin{titleframe}
 70#1
 71\end{titleframe}
 72}
 73
 74\newcommand{\erame}[1] {
 75\begin{titleframe}
 76\begin{equation*}
 77#1
 78\end{equation*}
 79\end{titleframe}
 80}
 81
 82\newcommand{\qrame}[1] {
 83\begin{titleframe}
 84\begin{citext}
 85#1
 86\end{citext}
 87\end{titleframe}
 88}
 89
 90\begin{document}
 91
 92\begin{frame}
 93\titlepage
 94\end{frame}
 95
 96\grame{wiles_conf.jpg}{Andrew Wiles (23. Juni 1993)}{1.2}
 97\grame{fermat.jpg}{Pierre de Fermat}{0.5}
 98\grame{diophantus.jpg}{Arithmetica von Diophantos (Edition aus 1621)}{0.34}
 99\gwome{mersenne.jpg}{Marin Mersenne}{0.3}{pascal.jpg}{Blaise Pascal}{0.7}
100\erame{n * \binom{n+m-1}{m-1} = m * \binom{n+m-1}{m}}
101\erame{S_m(N) = \displaystyle\sum_{i=1}^{N} n^m}
102\erame{a^p \equiv a \: (mod \: p)}
103\grame{diophantus.jpg}{Arithmetica von Diophantos (Edition aus 1621)}{0.34}
104\qrame{Es ist nicht möglich, einen Kubus in zwei Kuben, oder ein Biquadrat in zwei Biquadrate und allgemein eine Potenz, höher als die zweite, in zwei Potenzen mit demselben Exponenten zu zerlegen.}
105\erame{x^n + y^n = z^n}
106\erame{\forall_{n \in \{\mathbb{N} \setminus \{1,2\}\}} \not \exists_{x,y,z \in \mathbb{N}} \: . \: x^n + y^n = z^n}
107\erame{x^4 + y^4 = z^4}
108\erame{A_n \rightarrow A_m \: mit \: m<n}
109\grame{euler.png}{Leonard Euler}{0.3}
110\grame{germain.jpg}{Sophie Germain}{0.6}
111\gwome{legendre.jpg}{Adrien-Marie Legendre}{0.4}{dirichlet.jpg}{Peter Gustav Lejeune Dirichlet}{0.4}
112\grame{lame.jpg}{Gabriel Lamé}{0.3}
113\grame{academy.jpg}{Darstellung der französischen Akademie der Wissenschaften (1698)}{0.4}
114\gwome{lame.jpg}{Gabriel Lamé}{0.28}{cauchy.jpg}{Augustin-Louis Cauchy}{0.72}
115\grame{kummer.jpg}{Ernst Kummer}{0.6}
116\grame{wolfskehl.jpg}{Paul Wolfskehl}{0.533}
117\qrame{Sehr geehrte/r .........................,\\ \\ich danke Ihnen für Ihr Manuskript zum Beweis der Fermatschen Vermutung.\\Der erste Fehler findet sich auf:\\Seite .... Zeile ....\\Ihr Beweis ist daher wertlos.\\ \\Professor E. M. Landau}
118\grame{wiles_kid.jpg}{Andrew Wiles}{0.72}
119\grame{wiles_young.jpg}{Andrew Wiles bei seiner Abschlussfeier}{1}
120\erame{y^2 = x^3 + ax + b + c}
121\gwome{taniyama.png}{Yutaka Taniyama}{2}{shimura.png}{Goro Shimura}{0.31}
122\grame{frey.jpg}{Gerhard Frey}{0.6}
123\erame{y^2 = x(x-a^n)(x+b^n)}
124\grame{ribet.jpg}{Kenneth Alan "Ken" Ribet}{0.8}
125\trame{}
126\grame{wiles_port.jpg}{Andrew Wiles}{0.19}
127\trame{L-Funktionen und Arithmetik}
128\trame{Modulformen, elliptische Kurven und Galois-Darstellungen}
129\grame{wiles_conf.jpg}{Andrew Wiles (23. Juni 1993)}{1.2}
130\grame{katz.jpg}{Nicholas Michael "Nick" Katz}{0.3}
131\grame{taylor.jpg}{Richard Taylor}{0.61}
132\trame{}
133\gwome{wiles_port2.jpg}{Andrew Wiles}{0.6}{fermat.jpg}{Pierre de Fermat}{0.45}
134
135\end{document}

Would I have been faster just using copy-paste in a WYSIWYG? Maybe. However, now I have a template to use for further presentations! Too bad I don’t use Beamer anymore.

Collaboration & Efficiency

An important part of writing is collaboration. For the most part, documents are not the product of a lone author, but many people adding content, designing elements and reviewing changes. Sadly, LaTeX makes this essential part of authoring a complicated and frustrating endeavour.

“But I’m not a programmer!”

Most people without a background in computer technology look at LaTeX and think they are staring at the source code of a program.⁴ LaTeX is a complex and unintuitive system and bringing in newcomers is hard work. You cannot send a .tex file to a random contributor expecting they can work with it. This is a death sentence for collaboration.

I am sure that the argument will be made that LaTeX is very frequently used in academia to collaborate on papers but that is a very poor argument. It is no wonder that a homogenous group brought up in the very academic environment that champions the usage of LaTeX, is able to collaborate using it. However, what if interdisciplinary teams need to work on the same document?

What if people outside of academia want to contribute? Especially in business settings LaTeX has no reason to exist. Nobody cares about pretty typesetting for mathematic formulas when all you need is to copy spreadsheets from one document to the other. WYSIWYG editors are far superior when speed and efficiency is important and business is all about optimizing these two measures.

Interop? What Interop?

Office suites have an important property: Interoperability. A chart created in Excel, can effortlessly be inserted into Word and automatically receive updates if the Excel file was changed. When these files live on a NFS, collaboration is made easy. Data scientists publish a CSV file of their data, a consultant links this data in Excel and creates a chart from it and a manager then links this chart into Word or PowerPoint to create presentation material. Sounds like a nice little pipeline.⁵

In LaTeX such a pipeline is hard to imagine without exporting results as images. While pandas, the famous Python data analysis library, is capable of exporting data as LaTeX tables it is rare for a simple copy and paste to just work. In this context, automation means scripting. Get those awk and sed manpages out, we are going to need them when we want to automate anything using LaTeX.

Another problem is the integration of different data sources in the same document. What about diagrams made with Mermaid or PlantUML? AsciiDoctor allows to use Kroki to embed the output of a wide variety of different diagram rendering backends directly into documents. A much more complicated toolchain can be built to even allow automatic exports to services such as Confluence.⁶ Such an interoperability is hard to imagine with documents written with LaTeX.

And what about spellchecking or editorial style linting? Most tools have no easy way of ignoring the numerous, custom control structures of LaTeX documents and will lead to false positivies. While platforms like Overleaf have a built-in spellchecker that seems to be syntax aware, other open-source tools like Vale have no support for LaTeX and focus more on Markdown-based syntax.

That’s why LaTeX doesn’t even come up in discussions around the documentation as code philosophy, while languages like Markdown are used with static-site generators to automatically generate online documentation. LaTeX has simply become to much of a monolithic burden as a document preparation software for it to be useful in this regard.

Slow results

In a study Knauf and Nejasmic find that Microsoft Word users (novices and experts alike) write content quicker and produce fewer formatting and content errors than their LaTeX using peers.⁷ This is a pretty strong claim that has to be taken with a grain of salt. The study uses a small sample size of 40 participants and a single experiment, where the tasks are to recreate three pieces of text in either Word or LaTeX:

• Continuous text
• A table
• Text with equations

While this seems like a fair and balanced task we have to raise the question wether text reproduction can be used to evaluate efficiency of document preparation systems.

Nonetheless, the results from the study are interesting. Not only did Word users outperform LaTeX users, they did so in two of three tasks. While LaTeX users performed slightly better in reproducing a text with equations, they severly underperformed in the other tasks. Word users were better at formatting a table and writing continuous text with less errors.

This result does not shock me. Not only do LaTeX users have to deal with horrible syntax, they also face the problem of bad editor support, unpredictable feature interactions and no way to quickly inspect their output and nudge it in the right direction. It is not far fetched that errors in the content (like gramatical errors) could sneak into the mess of \begin and \end that a LaTeX document quickly becomes.

An Easy Alternative

Why use LaTeX when there are alternatives? Document preparation software is a vast field and many open-source projects try to carve out a space for themselves. Let’s highlight one of them.

AsciiDoc was already named a few times in this post as an alternative to LaTeX. The language is a simple to understand Markdown flavor with special control structures for embedding images, tables, lists, listings, admonition blocks and many more. It is used to create documents in PDF, HTML, DocBook and many more formats. The AsciiDoctor processor provides a fantastic eco-system of plugins and tools. With asciidoctor-kroki we can embedd a huge variety of plain-text diagram description languages into our document using Kroki. Using asciidoctor-mathematical we can use mathematical to render mathematical equations. Editing can be achieved easily with the VSCode extension for AsciiDoctor to provide a live-preview of the structure of the document in real-time.

Let’s look at a small example highlighting a few things that AsciiDoc can do using a simple file creating a bit of text, lists and tables. Additionally, we are using Kroki as part of our local toolchain to include diagrams in our document. Compiling this is only possible in a docker setup with correctly set up networks, so this is just for demonstration. Here is the source for the document:

:library: Asciidoctor
:stylesdir: style
:stylesheet: stylesheet.css
:imagesdir: images
:source-highlighter: pygments
// This lets asciidoctor inline images into the HTML output
:data-uri:
:toc: left
include::misc/kroki-settings.adoc[]

= AsciiDoc Examples

== Paragraphs

**Lorem ipsum dolor sit amet**, consectetur adipiscing elit. Sed eleifend feugiat tortor, in dignissim felis blandit non. Fusce suscipit urna id neque iaculis scelerisque. Fusce convallis leo turpis, vel blandit sapien malesuada at. Vestibulum ut elit eu quam laoreet mattis pulvinar vitae libero. Cras egestas, lacus non condimentum facilisis, risus tortor lobortis velit, quis facilisis ex risus sit amet ligula. Praesent facilisis lacus eros, et dictum tortor varius sed. Nam gravida mollis mattis. Sed eros nulla, varius et posuere sed, congue non dolor. Nullam urna risus, condimentum ac tempus sed, sagittis et nunc. Ut at fermentum diam. Quisque consequat tincidunt tellus vitae consectetur.

_Curabitur vestibulum ante metus_, a vestibulum nisl efficitur iaculis. Sed id massa sed nibh suscipit consectetur sit amet et massa. Morbi ex leo, congue in nunc et, tristique euismod enim. Nunc in dolor vitae erat egestas suscipit. Nulla hendrerit et dolor et sagittis. Praesent posuere nibh ac erat bibendum, vel interdum enim imperdiet. Aliquam erat volutpat. Donec quis porttitor purus. Etiam accumsan dignissim est et porta. Fusce eget sem laoreet, suscipit nisi quis, pulvinar libero. Etiam eu rutrum velit. In tortor arcu, luctus vitae posuere sit amet, molestie in odio. Donec purus tortor, pretium ut erat non, fringilla rhoncus massa. Nam ac dapibus orci, quis convallis nisl. Phasellus quis neque et velit scelerisque maximus.

== Tables

=== Basic

|===
|Column 1, header row |Column 2, header row |Column 3, header row

|Cell in column 1, row 2
|Cell in column 2, row 2
|Cell in column 3, row 2

|Cell in column 1, row 3
|Cell in column 2, row 3
|Cell in column 3, row 3
|===

=== CSV Paste-in

[%header,format=csv]
|===
"Column 1, header row","Column 2, header row","Column 3, header row"
"Cell in column 1, row 2","Cell in column 2, row 2","Cell in column 3, row 2"
"Cell in column 1, row 3","Cell in column 2, row 3","Cell in column 3, row 3",
|===

== Lists

=== Normal

* Hello
* World!

=== Numbered

. Hello
. World!

== Code Highlighting

[source,ruby]
----
puts "Hello World!"
----

== Diagrams

=== Mermaid

[mermaid]
....
flowchart LR
    Hello --> World!
....

=== Graphviz

[graphviz]
....
digraph {
    Hello -> "World!"
}
....

=== Vega-Lite

[vegalite]
....
{
  "$schema": "https://vega.github.io/schema/vega-lite/v4.json",
  "description": "Horizontally concatenated charts that show different types of discretizing scales.",
  "data": {
    "values": [
      {"a": "A", "b": 28},
      {"a": "B", "b": 55},
      {"a": "C", "b": 43},
      {"a": "D", "b": 91},
      {"a": "E", "b": 81},
      {"a": "F", "b": 53},
      {"a": "G", "b": 19},
      {"a": "H", "b": 87},
      {"a": "I", "b": 52}
    ]
  },
  "hconcat": [
    {
      "mark": "circle",
      "encoding": {
        "y": {
          "field": "b",
          "type": "nominal",
          "sort": null,
          "axis": {
            "ticks": false,
            "domain": false,
            "title": null
          }
        },
        "size": {
          "field": "b",
          "type": "quantitative",
          "scale": {
            "type": "quantize"
          }
        },
        "color": {
          "field": "b",
          "type": "quantitative",
          "scale": {
            "type": "quantize",
            "zero": true
          },
          "legend": {
            "title": "Quantize"
          }
        }
      }
    },
    {
      "mark": "circle",
      "encoding": {
        "y": {
          "field": "b",
          "type": "nominal",
          "sort": null,
          "axis": {
            "ticks": false,
            "domain": false,
            "title": null
          }
        },
        "size": {
          "field": "b",
          "type": "quantitative",
          "scale": {
            "type": "quantile",
            "range": [80, 160, 240, 320, 400]
          }
        },
        "color": {
          "field": "b",
          "type": "quantitative",
          "scale": {
            "type": "quantile",
            "scheme": "magma"
          },
          "legend": {
            "format": "d",
            "title": "Quantile"
          }
        }
      }
    },
    {
      "mark": "circle",
      "encoding": {
        "y": {
          "field": "b",
          "type": "nominal",
          "sort": null,
          "axis": {
            "ticks": false,
            "domain": false,
            "title": null
          }
        },
        "size": {
          "field": "b",
          "type": "quantitative",
          "scale": {
            "type": "threshold",
            "domain": [30, 70],
            "range": [80, 200, 320]
          }
        },
        "color": {
          "field": "b",
          "type": "quantitative",
          "scale": {
            "type": "threshold",
            "domain": [30, 70],
            "scheme": "viridis"
          },
          "legend": {
            "title": "Threshold"
          }
        }
      }
    }
  ],
  "resolve": {
    "scale": {
      "color": "independent",
      "size": "independent"
    }
  }
}
....

=== Structurizr

[structurizr]
....
 workspace {
    model {
        user = person "User"
        softwareSystem = softwareSystem "Software System" {
            webapp = container "Web Application" {
                user -> this "Uses!!!"
            }
            database = container "Database" {
                webapp -> this "Reads from and writes to"
            }
        }
    }
    views {
        systemContext softwareSystem {
            include *
            autolayout lr
        }
        container softwareSystem {
            include *
            autolayout lr
        }
        theme default
    }
}
....

This file includes a helper file to set a few settings for the imported Kroki images.

:kroki-fetch-diagram: true
:kroki-default-options: inline
:kroki-default-format: svg
ifdef::backend-pdf[]
// For the PDF backend, using SVG doesn't work with mermaid diagrams
:kroki-default-format: png
endif::[]
// Port to a local docker container running Kroki
:kroki-server-url: http://kroki:8000

This can then be compiled to a asciidoc.html or asciidoc.pdf file. Note that the source includes almost no extraneous syntax that is concerned with document structure or anything but the content. Data from CSV files can be included in AsciiDoc without much hassle and interoperability with multiple diagram backends is demonstrated.

What AsciiDoc shows in simplicity is also its weakest point. It doesn’t leave too many possibilities for formatting or changing the overall structure of the document. While the format shown in this example is fine for many documents, AsciiDoc lacks in a simple way of taking control over the overall design in a meaningful way, even though it can be done. However, one might argue that AsciiDoc precisely keeps LaTeX’ promise that the author ultimately does not have to worry about formatting. It is therefore very popular for technical documentation.

Another serious alternative to LaTeX, especially when it comes to scientific texts, seems to be Typst. I can’t make any real statements about it since I haven’t used it yet. However, its syntax, features and results already look quite nice.

Why LaTeX?

With all the cynical critique aside: What are the features that make people vouch for LaTeX? Looking around online, you will find a large community that simply loves how documents created with it look. The typesetting has become the main argument for defending its use. Is that really LaTeX’ only strong suite?

Typographic Beauty Craze

LaTeX produces some very good looking text. Yep. Don’t believe me? Look at this comparison of Word, InDesign and LaTeX by Roel Zinkstok. Kerning? Ligatures? Proper spacing for easier readability? It’s all there.

But that is expected from a typesetting system isn’t it? The whole point of TeX was to create some beautifully rendered text and at its core, thats what LaTeX can offer. Additionally, LaTeX brings beauty to mathematical typesetting! With its handsomely rendered mathematical formulas, LaTeX has inspired libraries such as MathJax and KaTeX to also provide this typesetting capability in modern webbrowsers.

This quality is an obvious plus when writing professional documents or publishing a book. LaTeX gives self-published authors the ability to provide output that (typographically) matches what professional publishers can achieve. After all, publishers love LaTeX too!

A Publisher’s Tool

The primary idea behind TeX was for it to be used for book publishing. It’s no wonder that many publishers use it. With the help of packages such as memoir it becomes manageable to take full control over typesetting and many other aspects of a document. This kind of deep and precise control cannot be offered by Word nor AsciiDoctor.

LaTeX’ support for cross-references, glossaries, bibliographies, lists of figures and automatic generation of a larger documents structure make it an essential tool for writing scientific books or theses. These features rightfully make it very popular in academic circles for writing papers.

Familiar in Academic Circles

LaTeX is a product of academia. Mathematicians, phycisists and computer scientists rejoice over their favorite document creation software. Therefore it is no wonder that LaTeX is their first choice when collaborating on papers. In the afforementioned disciplines it essentially is the only choice. Back when I went to university, we had no choice but to use LaTeX to write essays and seminar papers, since it was a formal requirement to use specific LaTeX templates.

This implicit familiarity helps in collaboration. Packages developed for LaTeX to provide certain (niche) features that a researcher might need for their paper can be picked up and used by other researchers. The de-facto standard in these fields also helps to standardize the writing and publishing process for academic work.

Conclusion

LaTeX is patchwork. At its core is TeX, a typesetting monolith. Around this core are macros that attempt to patch functionality into a system that fundamentally isn’t designed for it. This leads to a complicated system with strange syntax, fickle interactions and possible problems that nobody wants to deal with.

Authors should not have to care about document formatting and design and LaTeX makes the promise that this isn’t the case. This promise is broken. The author not only has to worry about formatting, they also have to deal with technical details and LaTeX’ intricacies. LaTeX simply isn’t a tool for the author but for the typesetter and publisher.

If the author needs full control over the document’s design, LaTeX is the wrong choice unless they want to spend an enourmous amount of time. It also isn’t the right choice when collaboration and simple interoperability is important. LaTeX forces the author to fully commit to its complex system, wether they like it or not.

So is LaTeX just useless for the author? Absolutely not. In certain scientific fields LaTeX is the de-facto standard and mathematical typesetting rarely looks as good as it does in documents created with it. It sometimes is the only choice depending on the need.

But what if we don’t have these peculiar needs? Sensible usage of LaTeX might consists of using it as a backend. Tools like Sphinx use reStructuredText as an input language which can then be transpiled to LaTeX to generate documents using better typesetting. Using this approach the author gets the best of both worlds. Simple, understandable syntax and TeX’ formatting power.

LaTeX is also not the only document preparation system and it is far from being the standard. It’s good to look at alternatives like AsciiDoc or Typst in order to get a better feel for what kind of tools are out there that might fit your needs much better. LaTeX is best at some things but its design comes from a time that is long gone. Modern times have arrived and with modern times come modern tools. What a time to be alive!