I consider myself a LaTeX guru. I’m very comfortable with the language, use it for everything possible and write my own packages. Peers often ask for TeX support, which sadly won’t lead to any co-authorships or citations, but may land me in some acknowledgements, if I’m lucky. Sadly, I am a very forgetful person, so whenever I set up a new PC, I forget what programs I should download, and what websites I should bookmark. This page is a personal reminder of everything useful LaTeX; hopefully it is useful to not just me, but to other people, too.

First, a disclaimer: I personally use Windows for all my machines. Most of the advice here works still, but those who use Linux or Mac should keep in mind that installation of programs may work differently. Since most tutorials online work only for Linux users, I do not feel guilty about this at all; I consider it retribution.

LaTeX installation

This section describes the initial installation of LaTeX. Again, I will only describe the process for Windows machines.

To Overleaf or not to Overleaf

My main advice to anyone using LaTeX is to NOT use Overleaf. Here are some reasons why:

  • Overleaf is proprietary and very expensive. It is unknown how much an organisational subscription is, but since the group professional subscription is, as of writing this post, €332 per user per year, one can assume your organisation will be paying tens of thousands a year.
  • The free version is extremely limiting in its computation time, currently sitting at 10 seconds.
  • Overleaf requires a paid subscription for Git and Zotero connectivity, both of which are open source pieces of software that don’t require any more computation time than your document itself.
  • Overleaf is online-only: you can’t edit while offline.
  • Overleaf is online-only: if it is ever offline (which it frequently is), you can’t access your work. You don’t want this to happen on the day of your project deadline. Overleaf has even been DoS’ed in the past.
  • Overleaf only updates its TeX Live version once a year at irregular times. This means you won’t be able to use new packages until a year later. So you’ll have to import the package yourself, but…
  • Overleaf has no custom package support. If you want to use a custom package or a package not included in Overleaf’s current version of TeX Live, you’ll have to import it in each single project.
  • Overleaf doesn’t have a customisable editor. Most modern editors allow one to install all kinds of plugins, define shortcuts and shorthands, etc.. Overleaf doesn’t permit that.
  • Overleaf doesn’t really explicitly save auxiliary files, which may break some packages. It also makes it impossible to save some computation time (which you have little of, anyway) by generating images in another file.
  • There are probably many other reasons I’m forgetting.

There are only two reasons why one would want to use Overleaf. First, you don’t have to install LaTeX on your local machine. This is valid if you have a computer on which you aren’t allowed to install programs, but in all other situations, this is merely an argument of laziness. LaTeX is a free piece of software that can run on any 21st-century machine. The other reason is that it allows for quite seamless real-time collaboration. Other editors allow a weaker version of this (such as VSCode’s Live Share), but none are at the level of Overleaf. Nevertheless, I am of firm belief that using Git is a much better way to collaborate, and it also comes with a much better version history than Overleaf does.

I recommend a local installation to every LaTeX user.

Distribution

The age-old question: should I install MiKTeX or TeX Live? MiKTeX and TeX Live are LaTeX distributions, which means they take care of the actual running of LaTeX documents and package management. Let me compare the pros and cons of both.

The pros of MiKTeX:

  • Automatically installs new packages.
  • Quite compact (1.5 GB, including packages, as of writing).
  • Very nice GUI.
  • Easy installation.
  • Also supports the installation of some fonts.

The cons of MiKTeX:

  • New packages can’t be used without an internet connection.
  • Custom packages require TEXMF root directory, which is a bit engaged.
  • Slower than TeX Live, especially in big beamer files.
  • Only really maintained by a single person (Christian Schenk).
  • There was at one point a huge bug that broke MiKTeX after updating. The only way to solve it was by updating MiKTeX using the command line. To my knowledge, fresh installations of MiKTeX should never encounter the bug any more, so it should be fine.
  • Doesn’t ship with Perl, so if you want to use latexmk, you have to install it manually (Windows users can do so here).

The pros of TeX Live:

  • All packages are installed by default.
  • Straightforward installation of custom packages.
  • Quite a bit faster.
  • Maintained by a big team.

The cons of TeX Live:

  • Installation takes very long.
  • It’s huge (10 GB as of writing).
  • No real GUI.
  • Installation is quite involved, and requires some tech knowledge.

I, myself, prefer MiKTeX over TeXLive due to its on-the-fly package installation. I also find it much easier to keep my packages up-to-date. Updating packages in MiKTeX is as easy as clicking a button, whereas in TeX Live, one has to go through the command prompt, which is quite a dedication to me.

Introducing international LaTeX update day

Whichever distribution you go with, it is very important to keep your packages up-to-date. I tell my peers to check for updates every first Monday of the month at noon (uncoincidentally coinciding with the Dutch air-raid siren tests and ball alert). That way, your packages remain up-to-date, and you minimise the number of issues you may run into. I have seen way too many people who haven’t updated since their original installation years prior (which is also why people are still encountering the MiKTeX Qt platform error years after it being an issue).

Text editors

While distributions take care of the actual compilation part of writing LaTeX (i.e., taking a .tex file and turning it into some output or .pdf file), you’re going to need something to write the .tex file. Of course, one could use your OS’s built-in text editor, but that doesn’t have any of the cool tools that come with a proper coding editor, such as custom shortcuts, shorthands, syntax highlighting, and much more. Here is a breakdown of editors I have experience with.

VSCode

My current choice. While it is proprietary, and, even worse, owned by Microsoft, it is very good at what it does. Moreover, it is free and based on a bare-bones open source version. Where it truly shines is its community plugins and seamless Git(Hub) integration. And it can be used for any programming language, so you can edit both LaTeX and Python files in the same window, and there is no need to learn to deal with various code editors.

The most important plugin is James Yu’s LaTeX Workshop. It takes care of everything you need to run LaTeX files. It also supports code snippets: if you type certain shorthands and press Tab, it will change it to some code, and automatically places your cursor in the correct place! For example, @/ evaluates to \frac{}{} and bseq evaluates to \begin{equation*}\end{equation*}. By default, LaTeX Workshop wants you to use latexmk (make sure you have Perl installed), but if you prefer manually compiling your documents (as I do), you should change the recipes in your settings.json. Mine are as follows:

    "latex-workshop.latex.tools": [
        {
            "name": "pdflatex",
            "command": "pdflatex",
            "args": [
              "-synctex=1",
              "-interaction=nonstopmode",
              "-file-line-error",
              "-shell-escape",
              "%DOC_EXT%"
            ],
            "env": {}
        },
        {
            "name": "lualatex",
            "command": "lualatex",
            "args": [
                "-synctex=1",
                "-interaction=nonstopmode",
                "-file-line-error",
                "-shell-escape",
                "%DOC_EXT%"
            ]
        },
        {
            "name": "biber",
            "command": "biber",
            "args": [
                "%DOCFILE%"
            ]
        },
        {
            "name": "dtx index",
            "command": "makeindex -s gind.ist",
            "args": [
                "-o",
                "%DOCFILE%.ind",
                "%DOCFILE%.idx"
            ]
        },
        {
            "name": "dtx change history",
            "command": "makeindex -s gglo.ist",
            "args": [
                "-o",
                "%DOCFILE%.gls",
                "%DOCFILE%.glo"
            ]
        }
    ],
    "latex-workshop.latex.recipes": [
        {
            "name": "lualatex × 2",
            "tools": [
                "lualatex",
                "lualatex"
            ]
        },
        {
            "name": "lualatex -> Biber -> lualatex × 2",
            "tools": [
                "lualatex",
                "biber",
                "lualatex",
                "lualatex"
            ]
        },
        {
            "name": "pdflatex × 2",
            "tools": [
                "pdflatex",
                "pdflatex"
            ]
        },
        {
            "name": "pdflatex -> Biber -> pdflatex × 2",
            "tools": [
                "pdflatex",
                "biber",
                "pdflatex",
                "pdflatex"
            ]
        },
        {
            "name": "dtx compilation",
            "tools": [
                "pdflatex",
                "dtx index",
                "dtx change history",
                "pdflatex"
            ]
        }
    ],

The tools and recipes with dtx are only relevant for LaTeX developers, so you may want to omit those. Of course, one may replace biber with bibtex if you prefer (but consider changing to biber since it’s more modern).

Use LTeX+ for a grammar/spell checker compatible with LaTeX. It does have a lot of false positives though, so make sure to hide them regularly (you can find issues in the problems tab of VSCode).

I sometimes use the GitHub Actions plugin to manage my workflow, but since I figured out how to compile LaTeX files in a GitHub action, I haven’t touched my workflows.

Todo Tree is an amazing extension. You can add to-dos in a comment, and the extension makes a list of all of them. Very useful for large projects.

Licenser is a niche extension that automatically adds licences to your files. It’s very situational and not for everyone.

My favourite extension is Prettify Symbols Mode, since it’s able to visually replace certain phrases in your code with custom Unicode. For example, it might replace \mathbb{N} by ℕ in your code, or \alpha by α. Amazing, right? I no longer use it because I would regularly get harassed by my peers for it. Use at your own risk.

Fun extensions: VSCode have a bunch of extensions that only do fun things. Whether you like having Subway Surfers, random cat pictures, or a small zoo in your window while working on your dissertation, VSCode has it. I should remark that of the above extensions, I have only ever used VSCode Pets; the others are there only for comedic value.

TeXstudio

A vintage LaTeX editor. Since it’s made specifically for LaTeX, it has a lot of buttons and shortcuts to make your life much easier, right out of the box. But I honestly feel VSCode does everything it does but better, unless you like pressing big, colourful buttons. It feels very outdated, as if stuck in Windows Vista. It also doesn’t have the same level of customisation as VSCode. It’s open source, though, and especially not owned by Microsoft.

TeXworks

I have only ever opened TeXworks by accident. It comes packaged with MiKTeX and may be associated with some file extensions by default (hence how I opened it by accident). It has the same vintage feeling as TeXstudio, but with way fewer functionalities. If you want a bare-bones, distraction-free editor that works with LaTeX very well, TeXworks is your go-to.

(Neo)Vim

I must be honest: I have never (seriously) used Vim. Despite this, I have heard great things about it, so I had to mention it here. Refer, for example, to these articles.

PDF readers

Now that we have used a code editor to write a .tex file, and used a distribution to compile it into a .pdf file, we still need a way to read the .pdf file. Most code editors will have a PDF reader built-in, but having a dedicated PDF reader remains an essential tool to the LaTeX guru. Beyond just being able to read the document, a good PDF reader also provides valuable metadata, supports annotations, is free, and has a nice “presentation” mode.

Adobe Acrobat Reader

This is not a PDF reader but the PDF reader. After all, the PDF was invented by Adobe. Adobe Acrobat Reader has all the functionalities one would wish in a PDF reader… after paying for the premium version, which is incredibly expensive. I highly advise against using it, because it hits you with a paywall at every corner, even for incredibly basis functionalities. It’s a perfect example of shady proprietary software practices.

It should be mentioned that Adobe Acrobat Reader can run JavaScript inside PDFs. More on this in the section on pdf.js.

Adobe Acrobat Reader is incompatible as a LaTeX reader, since it “locks” PDF files that are currently open. This makes it impossible to compile .tex files whose corresponding .pdf files are already open.

Chromium PDF reader

Probably the most common PDF reader, because you likely already have it installed. Not to mention, if you open a PDF in a Chromium-based browser, it automatically opens in this! It has a very bare-bones presentation mode, and provides some metadata. However, it doesn’t have as many functionalities as most other PDF readers.

Since the PDF “lives” in the address bar, it is very easy to navigate to any anchor in the document (these are the internal links used in navigation). These are generated automatically by hyperref, so it works in almost any LaTeX document (try this one).

As opposed to Adobe Acrobat Reader, PDF files aren’t locked, so you may freely compile them without any compatibility issues.

pdf.js

This is the PDF reader that is included in Mozilla Firefox, and a version of it is included in VSCode’s LaTeX Workshop. It is similar to the Chromium PDF reader (it will likely run in your browser), but it has some extra functionalities. I have found that there sometimes are some rendering issues in pdf.js, especially when two coloured boxes touch. Somehow, there’s always a tiny sliver of white pixels in between them. The presentation mode isn’t anything to write home about, and printing is excruciatingly slow.

Additionally, like Adobe Acrobat Reader, it can run JavaScript in your PDF. As far as I know, these two editors are the only ones that can do this (Adobe Acrobat can do more than pdf.js). It has some cool applications, such as animations and actual interactive games. However, one should remember that neither of these are “intended” LaTeX use, and the portability of a PDF (what the “p” stands for) is jeopardised by writing documents which only render properly in one of two PDF readers. More worryingly, embedded JavaScript can be used to put actual malware in a PDF document. Only Adobe Acrobat Reader and pdf.js are vulnerable to such attacks. Personally, this is sufficient reasoning to not use them.

Okular

This is my personal choice. Okular is open-source and has many of the useful features that Adobe Acrobat Reader does. It has a ton of metadata, no rendering issues (as far as I know), and doesn’t support JavaScript (which is a good thing, as I mentioned). However, the annotations aren’t very intuitive, and it renders a document one page at a time (so no scrolling through!). I remember rendering being very slow, but I haven’t had the issue in years (maybe SSDs fixed it). Both Okular and pdf.js are compatible with PDF layers, which can also be switched on/off manually. This is used by packages such as ocgx to display optional content, and by hyperref’s ocgcolorlinks to make links black when a document is printed. The feature may also be used to remove watermarks from documents, as well as other obstructing things that were wrongfully separated as a layer (recently, the FBI accidentally did this).

A very big advantage of Okular: it automatically reloads PDF files after changing them. So if you rerun a .tex file, the changes are automatically reflected in Okular.

A big disadvantage of Okular (as of writing) is that it does not yet support any of the new accessibility features included in PDF 2.0. This means it gives no insight into the tagging setup and alt texts. This isn’t a huge deal for regular end users, especially since LaTeX’s accessibility features are used very rarely, but is quite annoying for anyone interested. Especially since all major PDF reader lock these features behind a paywall.

Zotero built-in PDF reader

I only put this here because the Zotero reader has reference previews, which are especially useful for citations. I don’t know why the big players haven’t implemented this, yet. It’s absolutely amazing.

Compilers

By default, most people will use pdfLaTeX to compile their documents, but there are way more options. It’s not very difficult to choose which one is best: take the newest one that’s widely supported by the community. Right now, that’s LuaLaTeX. In this section, I will treat some of the big compilers (in historical order) to compare the difference in features.

TeX

TeX is the original program that LaTeX is built upon. TeX is very bare-bones and unintuitive to many. Remarkably, its output files are .dvi files, while modern LaTeX is known for outputting .pdf files. Some TeX macros (which have since been replaced by LaTeX macros) are still in common use today, such as $...$ and $$...$$. Realistically, you shouldn’t use this directly, but every LaTeX file is TeX in disguise. It is still under active development by David Knuth.

LaTeX

LaTeX is actually not a compiler itself: it is more accurately described as a (huge) collection of TeX macros. Notable inclusions are \(...\), \[...\], documentclasses (like article) and the document environment, itself. Almost all TeX users use the LaTeX macros (mostly without even knowing the difference). The “La” is generally believed to be short for Lamport, the creator of LaTeX. Like TeX, LaTeX only outputs .dvi files.

pdfLaTeX

Whenever a compiler is named “(x)LaTeX”, it means that it is the “(x)TeX” compiler together with the LaTeX macro definitions. But since very few people actually use straight-up pdfTeX or LuaTeX, I will only discuss the LaTeX-variants. As the name implies, the main difference between LaTeX and pdfLaTeX is that pdfLaTeX outputs .pdf files. It is the most common contemporary compiler, though not necessarily the best one.

For modern use, pdfLaTeX is lacking. Most of the reasons are technical (for example, there is a maximum of 16 write files, and some packages require LuaTeX), but even low-level users will experience the most famous difference: pdfLaTeX has limited font support. The font file system is highly deprecated, so if you want to use a different font, you’re dependent on the user base to create a package that looks like your font of choice.

Do keep in mind that pdfLaTeX is much faster than the modern LaTeX compilers. So what it loses in raw power is gained in speed. If you have no interest in using fonts or packages which require LuaLaTeX, and your computer is on the slower side (or you’re using Overleaf with its compilation time limits), you might want to stick to pdfTeX.

XeLaTeX

In my experience, XeTeX is something the “cool people” use. Its height of usage was when I, myself, didn’t really understand LaTeX, myself, so I felt like XeLaTeX users must really know what they’re talking about. By the time I actually needed features outside pdfTeX, LuaLaTeX was already starting to supplant XeLaTeX. XeLaTeX’s main new feature is its font support using fontspec. It supports any TrueType and OpenType font, which are the font files actually used by your computer. Whenever I set a font, I often include a piece of code of the following form, which automatically differentiates between pdfLaTeX and modern fontspec-compliant engines.

\RequirePackage{iftex}
\ifpdftex
    % Deprecated LaTeX compilers use these fonts
    \renewcommand\rmdefault{ppl}
    \renewcommand\sfdefault{phv}
    \renewcommand\ttdefault{cmtt}
\else
    % LuaLaTeX and XeLaTeX
    \RequirePackage{fontspec}
    \setmainfont{TeX Gyre Pagella}
    \setsansfont{TeX Gyre Heros}
    \setmonofont{Latin Modern Mono}
\fi

Today, XeTeX has two very large downsides. First, it is no longer in active development. Second, it’s not based on pdfTeX. While it does output PDFs, it does so in a quite roundabout way. Not being based on pdfTeX means there are some compatibility issues, such as with microtype. But its biggest downside is that it is simply not LuaTeX.

LuaLaTeX

Although historically seen as unstable, modern LuaLaTeX is the LaTeX compiler. It has more or less all features of XeLaTeX, is more compatible with pdfLaTeX, works extraordinarily well with PGF/TikZ, and, best of all, includes the Lua programming language. While completely irrelevant to low-level LaTeX users, package authors use Lua to do a lot of difficult tasks that need a smart model to work through. LaTeX simply isn’t very powerful as a true programming language, even with LaTeX3; Lua is. An example of a package which uses Lua is TikZ-Feynman. Lua calculates the optimal positioning of the diagram, which makes it possible to generate Feynman Diagrams without explicitly positioning each vertex.

LuaLaTeX is, however, very slow. It’s improving and catching up to XeLaTeX, but it will never be as fast as pdfLaTeX. On modern hardware, the difference isn’t that important, but if you’re using an old machine or Overleaf, it might be beneficial to use pdfLaTeX, instead. In all other cases, I recommend LuaLaTeX, which is the future of LaTeX.

Useful web tools

This is a collection of useful tools I’ve accumulated over the years.

DeTeXify

DeTeXify is a truly magical website. It uses machine learning to recognise drawings of LaTeX symbols, and tells you what package they’re from and what macro corresponds to them. And it’s written in Haskell, which I respect.

Mathcha

This is a general purpose mathematics editor, but I mainly use it for its drawing functionality. It provides a Microsoft Paint-like UI that can be exported to TikZ. Of course, it won’t be as pixel-perfect as a manual TikZ picture, but it’s great for sketches.

quiver

Quiver is a website for generating commutative diagrams in TikZ-cd. It’s very easy and intuitive to use. Do make sure to \usepackage{quiver} to enable all macros. It is under active development, and new features are added all the time. Do make sure you have an up-to-date version of quiver installed if you use such a newer feature. This especially poses an issue for Overleaf users, whose quiver installation may be outdated by up to a year. Since it’s quite new, historical versions of Overleaf might not have quiver at all.

Tables generator

The name says what it does. There are many alternatives, but I prefer this one, due to its nice features. It allows importing from LaTeX, CSV, Excel, HTML, etc., and exports to many formats, including LaTeX and Markdown. It has a simple, intuitive user interface, that even allows one to make a custom border grid and set the background colour. I only wish it supported exporting to alternative table types, such as tabularx, and (mass-)converting cells to math mode.

TikZ-related tricks/packages

TikZ is a quite odd package, so I’m always looking for more ways to improve my workflow.

Memoize

TikZ pictures are quite intensive to generate. So if you have many of them in a single document, it takes ages to compile. Memoize makes it so you only have to generate TikZ pictures once, and then imports them into the document. Make sure you have Perl installed. TeXLive ships with it, MiKTeX will have to install it manually (Windows users can do so here).

Implicit algebraic curves using gnuplot

TikZ only draws parameterised curves. If you want to instead draw an implicit equation \(f(x,y) = 0\), you’ll need to perform some trickery. You can find how to do this on Pieter Belmans’s website. Make sure to install gnuplot, and don’t forget to add it to PATH (you can do this during installation), or it won’t work.

Bibliography management

It is of course possible to manually create the bibliography in a LaTeX document, but modern LaTeX users instead let this be handled by a package. There are generally three relevant programs for bibliographies.

  1. Reference manager: a program which collects all references and, preferably, exports them as a .bib file, which is a list of references.
  2. Bibliography package: a package which takes a .bib file and outputs another file to be analysed by a bibliography processor. It also has macros which display the info from the .bbl file output by the processor.
  3. Bibliography processor: an external program (not part of LaTeX) which turns the output of the bibliography package into a .bbl file, which is the actual LaTeX code that outputs the list of references.

.bib files and .bbl files can theoretically be created manually, but I recommend using dedicated programs to assure consistent style and accurate links.

Reference managers

Of the programs listed above, reference managers are used the least. However, they greatly simplify and even automate the process of collecting references. A good reference manager has the following features:

  • Make reference folders, where one can collect all references for a specific project.
  • A search functionality, where one can search through all their past and present references.
  • Convert all references in a project to a .bib file, either for bibtex or biblatex.
  • Automatically collect reference information from a URL/DOI/ISBN/arXiv ID.
  • Attach .pdf files to references.
  • Support all the necessary fields that can be used by LaTeX.
  • Make custom fields which will be output in the .bib file.
  • Shared folders with other users for collaboration.

My recommendation for reference management is Zotero. It has all the above features and more, including a browser extension. Make sure to install the Better BibTeX plugin for enhanced LaTeX support, and the ZotMoov plugin for moving .pdf files outside the Zotero cloud (its cloud storage is very limited).

Some people use EndNote, which has most features that Zotero does, but it isn’t nearly as compatible with LaTeX.

Bibliography package

There are two main players in bibliography packages: natbib and biblatex. biblatex is the successor to natbib, and is superior in almost every way. Here are the pros of using biblatex over natbib:

  • It supports biber (in addition to bibtex), which I will discuss below.
  • It supports more citation styles.
  • Through babel, it supports other languages using the language tag, using correct multilingual typography.
  • Similarly, it has better support for Unicode.
  • You can create multiple bibliographies.
  • It’s even backwards-compatible with natbib by using the natbib option.

Nevertheless, natbib is by far the most used package, and you’ll probably want to use it as well. The reason? Academic journals.

  • Many journals have their own citation style in the form of a .bst file, used by natbib. biblatex is incompatible with these files, and uses .bbx files.
  • Other journals don’t allow .bbl files, and require you to put the bibliography directly into your .tex document using bibitems. In natbib, this is as easy as copying and pasting the contents of your generated .bbl file. In biblatex, you need the biblatex2bibitem package.

If possible, I recommend biblatex every time. But if you want to publish in a journal that only supports natbib or bibitems, you’ll of course have to switch. If you want to use biblatex, but might have to change to natbib down the line, I recommend playing it safe by using the natbib=true option. This will simplify the conversion, since it’s only necessary to change the package itself.

Bibliography processor

The discussion on bibliography processors is very similar to the one on bibliography packages above. There are two packages, bibtex (which confusingly isn’t the predecessor to biblatex) and biber. Again, biber is better in almost every way.

  • It supports non-ASCII characters.
  • It can deal with way more entries in the .bib file.
  • It unlocks a lot of extra features in biblatex.

However, bibtex does have the following advantages.

  • It might be required by a journal.
  • It can theoretically be used without a bibliography packages (which might be required by journals).
  • It is much faster (though realistically, your bibliography processor should take much shorter than your LaTeX document).

I recommend using biber if possible.

When using a bibliography processor, you should compile a LaTeX document as follows:

LaTeX -> bibliography processor -> LaTeX -> LaTeX

The first LaTeX run generates the file to be analysed by the processor. We then process it into a .bbl file and run LaTeX twice, to make sure all links work correctly.