TeX Live upgrade—September 2019

On September 23rd 2019 at 13:00 GMT we upgraded our LaTeX compile servers to make the final version of TeX Live 2018 available. Here we provide some notes on important changes in TeX Live 2018 together with some observations based on our own testing.

Upgrade FAQs

You do know it’s 2019, right?

Yes, we realise that we’re a year behind with this 2018 release, and we’re planning to follow up with a TeX Live 2019 release later this year. TeX Live upgrades are a big project for us, because we do a lot of work to make sure that the new release is stable and performant, so we’re taking it slowly and incrementally.

Will my existing projects work as usual?

Yes! The upgrade to TeX Live 2018 will not affect your existing projects because those projects will continue to use the TeX Live image they were created with and should continue to work as normal.

How can I switch to TeX Live 2018 for existing projects?

If you want to transfer an existing project to TeX Live 2018 you can either make a clone of that project or contact us for support. Note that some projects will require changes once they switch to TeX Live 2018 from an older image. We’ve included some of the common breaking changes later in this post.

What’s New in TeX Live 2018?

There are a number of noteworthy changes/updates, including:

• File paths are now “case-insensitive”. That is, if your tex file includes a figure called galaxy.jpg (small g), but in your project it’s called Galaxy.jpg (big G), your compile on Overleaf will no longer complain it can’t find the file.
• Support for typesetting characters with accents and some special characters is now improved. You should no longer have to worry about cryptic \usepackage[utf8]{inputenc} statements in your preamble, because LaTeX has made UTF-8 the default file encoding (but the fontenc package is still required in some cases). If there is a problem with the way that the encoding is set up, you are now more likely to get an error in your project. More details below.
• You can now use biber 2.12 and biblatex 3.12, which compile much faster.
• You can now typeset multilingual documents with the babel package using XeLaTeX/LuaLaTeX and \babelfont—another choice besides polyglossia.

The official release notes for TeX Live 2018 are available from TUG. Read on to find out more...

Overleaf and TeX Live

TeX Live is a free distribution of the TeX typesetting system that includes many, many TeX-related programs, fonts and macro packages, including LaTeX. Overleaf uses TeX Live on our compile servers to power the real time preview and produce the PDFs for your projects. TeX Live is constantly updated with the latest LaTeX packages contributed by the community. That constant innovation is a big part of what makes TeX useful and relevant today, over 40 years after it was first created. It does however mean that sometimes packages will change and documents will break even though you haven't made any changes.

About our upgrade process

TeX Live is an important component of Overleaf and prior to upgrading we recompile a large test set of documents, including roughly 5000 from our gallery of templates, examples and articles to check for breaking changes—including errors and any significant visual change(s) to the compiled output. As a result of those tests we update templates that we have produced - this is why it sometimes takes us a while to update our TeX Live! However, the result is hopefully a more stable experience for our users.

During the tests we conduct, we also measure the comparative time it takes to render documents. We identify significantly slower renders and try to make them faster. The chart below shows that most of our test documents render approximately as fast in 2018 as they did in 2017. We have furthermore seen significantly improved render times for some documents containing a lot of graphics and images.

Despite our testing, updates made to LaTeX, TeX engines, or important fonts and packages in TeX Live, can sometimes introduce incompatibilities, breaking changes and deprecations that are beyond our control. Given the scale of TeX Live and the wealth of packages and tools it provides, we can’t rule out breaking changes, but we have tried our best to minimize any impact on our users. Some user projects may have to be updated to reflect changes introduced by the upgrade to TeX Live 2018. For this update, we estimate less than 5% of projects should be significantly affected.

Key Changes in TeX Live 2018

Case-insensitive file searching

Case sensitivity is a long-standing question in computer file systems—that is, do chapter1.tex (small c) and Chapter1.tex (big C) name different files (case-sensitive) or the same file (case-insensitive)? Windows and Mac are usually case-insensitive, so they would refer to the same file (as would cHaPtEr1.TeX). Linux and other Unix-like systems, however, are usually case-sensitive, so they would refer to different files.

Case sensitivity caused many portability problems when exchanging files between Mac, Windows and Linux users. Overleaf’s compile servers run on Linux, so these differences were also sometimes the cause of “works on my machine but not on Overleaf” problems. In TeX Live 2018, LaTeX will find files regardless of case.

Of course, for maximum portability, it’s still a good idea to adopt a consistent convention for naming your files, including whether to use upper or lower case, and to refer to other files from your .tex files using the correct case, in the event that someone is using an older release. This is especially true of journal and preprint submission systems, which may still be case-sensitive.

Under the hood, this change was implemented in the Kpathsea library, which TeX uses to find files. You can read more about the change in the section on case folding search in the Kpathsea manual.

Unicode character not set up for use with LaTeX?

The release of TeX Live 2018 coincided with an important change to LaTeX: switching to UTF-8 as LaTeX’s default input encoding. This change mainly affects projects that directly use characters with accents, for example by writing inspiré in the .tex file instead of the more portable but less readable inspir\'{e}, in which the é in the output PDF comes from the TeX command \'. Previously, such projects had to include \usepackage[utf8]{inputenc} in their preamble in order for the accents to compile on Overleaf, but now it is the default.

The inputenc package was originally designed to support multiple input text encodings, providing portability for LaTeX documents so they will compile successfully when files are transferred to a computer using a different input encoding. inputenc also provides UTF-8 support for 8-bit TeX engines, such as pdfTeX, which cannot natively read and process UTF-8 encoded text. It is also worth noting that modern Unicode-aware engines such as XeTeX and LuaTeX have built-in (native) support for UTF-8: they do not need to use inputenc and are unaffected by LaTeX’s move to UTF-8.

How will the move to UTF-8 affect Overleaf users?

Overleaf itself has long used UTF-8 as the encoding for all editable text files produced on Overleaf, which is the reason all new blank projects automatically included inputenc with the utf8 option enabled. It is unlikely that Overleaf users will be adversely affected by this change to LaTeX but there is one issue that users should be aware of: LaTeX will now visibly complain if there are characters it cannot handle—and Overleaf reports those errors.

Prior to TeX Live 2018, if your document contained characters that LaTeX could not typeset it might still compile but the resulting PDF would be missing important characters (glyphs)—they were reported as “missing character” warnings in the .log file. LaTeX’s switch to reporting errors is preferable because hard-to-spot missing glyphs now demand your attention to find and fix them, helping to ensure the correctness and fidelity of your typeset document.

Example

The following simple document demonstrates the different default behaviour in TeX Live 2017 and 2018 when using pdfLaTeX to compile a document containing Unicode characters:

\documentclass{article}
\begin{document}
45° to ₹5 the left, α ± β, àm fine ̀am not flow
Ağrı İbrahim Çeçen University
Yıldırım Beyazıt University
\end{document}

Compiling with TeX Live 2017

The document will compile but errors are not visibly reported. Unicode characters are not rendered in the output PDF but warnings about missing characters are reported in the .log file:

Missing character: There is no � in font cmr10!

Result from compilation using pdfLaTeX on TeX Live 2017:

Compiling with TeX Live 2018

Using TeX Live 2018 the result is quite different. On Overleaf the compilation will “succeed” but pdfLaTeX loudly complains about problems that you should fix to get the characters correctly rendered into the output PDF.

Result from compilation using pdfLaTeX on TeX Live 2018:

The errors inform you which characters cannot be typeset:

This difference in behaviour arises because LaTeX within TeX Live 2018 now implicitly assumes use of \usepackage[utf8]{inputenc} which triggers reporting of these errors.

OK, how do I fix it?

Each error in this example requires a different solution:

• For the degree symbol on the first line: add \usepackage{textcomp} to the preamble.
• For the rupee symbol: Add \usepackage{tfrupee} to the preamble, and use \rupee to insert the symbol. (By the way, the textcomp package provides \texteuro.)
• Instead of pasting unicode characters α ± β directly, re-write them using LaTeX math commands, i.e. $\alpha \pm \beta$. (See this guide, or these tools for help on LaTeX math commands.)
• The first à on line 4 is error-free, but the second one is not: that latter ̀a is actually two separate characters ̀ (combine grave accent) and a (normal a). Such combinations usually come from a copy-paste from other document sources especially PDFs, and are not supported by LaTeX: hence the error. This would need to be manually replaced with a proper à, or you can use the LaTeX command \`{a}.
• If you look very carefully at the “flow” on line 4, you may notice that the initial fl is actually one single ligature character. This is again unsupported by pdfLaTeX; so it needs to be manually replaced by two separate characters “fl”. Keep an eye out for other common ligatures like fl, ff, ffi and ffl, especially when copying-and-pasting from other document sources like PDFs and web pages.

Caution with copy and paste

Users who copy and paste text into their LaTeX documents from sources such as Microsoft Word, web pages or their existing PDF documents, might, inadvertently, incorporate a wide range of Unicode characters that their LaTeX document is not configured to typeset.

Text that is copied and pasted into an Overleaf LaTeX document is saved as UTF-8 which will of course result in the corresponding UTF-8 representation being created for all characters present within your pasted-in text—including accented characters, curly quotes, various dashes, mathematical symbols and ligatures (as demonstrated in our example above), and many other possibilities. Prior to TeX Live 2018 such characters might have “just worked”, or quietly been omitted from your document: now it is possible that, with pdfLaTeX, those characters will trigger LaTeX errors unless you’ve correctly setup your document’s output to use the appropriate fonts/encoding with fontenc.

Yes, you still need to use the fontenc package

LaTeX’s adoption of UTF-8 by incorporating functionality equivalent to \usepackage[utf8]{inputenc} into its core code provides UTF-8 support for pdfLaTeX’s input files. You still need to use the fontenc package to specify which fonts pdfLaTeX should use to produce the output. To do that, you configure the fontenc package with the encoding option(s) appropriate to your document: this tells pdfLaTeX to load fonts which contain the symbols (glyphs) corresponding to the range of characters contained in your LaTeX document.

Caution when using the ucs and utf8x packages

During testing we observed that \usepackage{ucs} and \usepackage{utf8x} triggered fatal errors in some templates. The TeX FAQ recommends

“As a general rule, you should never use utf8x until you have convinced yourself that utf8 cannot do the job for you.”

Most projects with these issues will work well if the ucs package is replaced with \usepackage[utf8]{inputenc}; consequently, we echo the advice contained in the TeX FAQ. In cases where utf8 isn't enough, as with some Turkish characters and some Arabic glyphs (when using arabtex and pdflatex) we recommend template authors switch to using XeLaTeX instead of pdfLaTeX.

Confused by inputenc and fontenc and related matters?

If you would like to better understand what inputenc and fontenc are designed to do, we recommend reading this excellent explanation on tex.stackexchange. Another informative background post by the same contributor explains the difference between font encoding and input encoding. The inputenc documentation also provides some accessible background reading, and further information on what UTF-8 actually means can be found in the Overleaf article Unicode, UTF-8 and multilingual text: An introduction.

If you’d like to find out more about this change in LaTeX, it was reported in the April 2018 issue of LaTeX News. Interested readers can find further technical details via the LaTeX GitHub repository or LaTeX’s code documentation Providing some UTF-8 support via inputenc (distributed as part of TeX Live). General background information on TeX and Unicode is contained in the TeX FAQ.

Is it time to switch to XeTeX or LuaTeX?

The advent of pdfTeX in the late 1990s represented a major step forward in TeXnology and it rapidly became the TeX engine of choice. It continues to be extremely popular with TeX users, partly driven by authors who need their LaTeX articles to remain compatible with existing publisher submission systems and production workflows. However, pdfTeX was never designed to natively handle the full complexity of working with Unicode and it doesn’t have built-in support for modern OpenType font technologies. pdfTeX is an 8-bit TeX engine, restricted to handling 256 characters per font and relies on a suite of older typesetting technologies: use of TeX’s TFM (TeX Font Metric) files in conjunction with a plethora of text/font encodings and Adobe’s old Type 1 fonts.

If the nature of your work involves typesetting of complex multilingual documents, or you’d like to exploit OpenType fonts for text or mathematics, it might be a good time to consider using LaTeX with XeTeX or LuaTeX. To do that you need to change your project’s compiler via Overleaf’s Menu and choose either XeLaTeX or LuaLaTeX respectively. Users are advised that not all LaTeX templates submitted to Overleaf’s gallery are necessarily fully compatible with XeLaTeX/LuaLaTeX: it is advisable to perform some tests before committing to using those TeX engines.

Check with your publisher!

If your Overleaf document is destined for submission to a journal, it is extremely important to check with the journal’s editorial office (or contact the publisher) to ask if their article-submission system and production workflow(s) support newer TeX engines: some publisher workflows do not currently support XeTeX or LuaTeX. You should establish this before committing too heavily to LuaTeX- or XeTeX-specific functionality so that you don’t invest a lot of time only to discover you cannot submit it “as is” and need to rewrite large sections of your article to make it compatible with pdfTeX.

New CJK fonts

Overleaf’s TeX Live 2018 installation contains updated Noto Sans CJK (思源黑体) fonts, as well as newly added Noto Serif CJK fonts (思源宋体). This means it is now possible to typeset full CJK documents using Songti (mincho) and Heiti (gothic) families from Noto. Here’s a demonstration of these fonts in action, and here’s a preview of the output.

nonfreefonts in TeX Live 2017 and later

It is not strictly speaking new in this release, but it is worth noting that the non-free font packages distributed via the get-nonfreefonts script are not currently available on Overleaf, so font packages like uarial, classico, garamondx, \usepackage[urw-garamond]{mathdesign} won’t work. The good news is that there are many free alternatives. Here are some suggestions of font packages to replace such non-free font packages:

• arial-urw,uarial -> helvet or tgheros
• classico -> biolinum
• dayroman, urw-garamond, garamondx, garamond -> ebgaramond
• luximono -> newtxtt
• ulgothic -> sourcecodepro
• webomints: Consider alternative packages providing ornaments, such as those listed here.

Outdated \ProvidePackageRCS syntax

If you are using \ProvidePackageRCS, the syntax has changed: \ProvidePackageRCS $...package info...$ will no longer work. TeX Live 2018 insists that the package info be enclosed in braces: \ProvidePackageRCS{$...package info...$}

"EB Garamond" with fontspec

fontspec users who wish to use this font should just write \setmainfont{EB Garamond} instead of trying to guess the .ttf name.

Roboto font

Some older templates had \setmainfont{Roboto Regular}. This should now be just \setmainfont{Roboto}.

Changes to community-contributed templates

Overleaf’s Template Gallery contains thousands of templates submitted by Overleaf users and we are always grateful to receive those contributions for use by the wider community. Where community-contributed templates have not ported cleanly to TeX Live 2018, we have held them on their original image for the time being, until their contributors can update them. If you encounter a template with errors, please contact us to let us know, and we’ll see what we can do to ask the original contributor to update it.

Changes affecting templates used for CVs

The unicode-math package no longer has the vargreek-shape option and this affects the older AwesomeCV and FriggeriCV templates and any user whose CV project makes use of those templates. We have updated the AwesomeCV template but contributed templates have yet to be updated by their creators and may still be using older TeX Live images until they are updated.

Using non-ASCII characters in.cls file information

During our tests we made the following observation which may be of interest to authors of LaTeX .cls files.

Some class files use diacritics, non-ASCII characters in the class information section of .cls files. The example here contains

\ProvidesClass{utfpr-pg}
[2014/11/13 v1.0.0 Classe para trabalhos acadêmicos da UTFPR-PG]

The class information contains an â character and this is destined to be written out to the .log file; however, at this point utf8 configuration hasn’t yet been activated so the LaTeX compiler throws a mysterious error.

The solution is to add \UseRawInputEncoding before \ProvidesClass in the .cls file; it should later load \RequirePackage[utf8]{inputenc} to proceed with the correct configuration. One solution is to test the format version to decide whether to turn on raw encoding:

\@ifl@t@r\fmtversion{2018/04/01}{\UseRawInputEncoding}{}
\ProvidesClass{utfpr-pg}[...]

Package updates

Many packages have been upgraded in TeX Live 2018, but here are a few changes that we’ve noticed:

• pgfgantt: compress calendar option should now be replaced with time slot unit=month
• Listings: the postbreak option is now a lot more fragile, and code listings containing non-ASCII breaks very easily—be careful! Discussions of some known issues can be found at https://tex.stackexchange.com/a/451538, particularly if you’re using lstlinebgrd
• lettrine: if you use a \scalebox with it, you will now need to \protect the \scalebox. See https://tex.stackexchange.com/a/454117 for details.
• cleveref: this package is now quite particular about its loading order: it must be loaded after amsmath and hyperref.
• fontspec: previously you could use \newfontfamily to re-assign font families. Now you must use \renewfontfamily for family names that were already defined.
• The exam class no longer loads framed; users need to load the framed package themselves with \usepackage{framed} if wanted.

Using microtype and LuaLaTeX

As discussed on tex.stackexchange, the microtype package shipped with TeX Live 2018 contains a bug which affects documents being typeset with LuaLaTeX. To work around this problem, add \usepackage{luatexbase} to your document preamble before loading microtype.

For example:

\documentclass{article}
\usepackage{luatexbase}
\usepackage{microtype}

\begin{document}
My LuaLaTeX document starts here...
\end{document}

Post-publication updates (as of 20 November 2019)

We will continue to update this blog post with additional advice/guidance that might be useful to the Overleaf/LaTeX user community.

Using the tabu package with TeX Live 2018

The tabu package shipped with TeX Live 2018 has not been maintained and is now incompatible with many other packages. To address this problem, a community of volunteers has very kindly done some work to fix-up the tabu package; however, because that updated version is not the “official” package release it is not shipped with TeX Live 2018.

If you want to use the tabu package we recommend downloading the community-updated version of tabu.sty and adding it to your Overleaf project.

How to download the updated tabu.sty file

You can save the source code into a text file, naming it tabu.sty, or you can download a ZIP file that contains tabu.sty (along with other files you don’t actually need).

To download a ZIP file containing tabu.sty:

1. Go to https://github.com/tabu-issues-for-future-maintainer/tabu
2. Select Clone or download and choose Download ZIP:

3. Extract the file tabu.sty from the downloaded tabu-master.zip.

Once you have tabu.sty you need to upload that file to your Overleaf project.

Package todonotes affects SyncTeX

As reported on tex.stackexchange the todonotes package shipped with TeX Live 2018 can interfere with SyncTeX.

SyncTeX is a standard extension to TeX engines which enables synchronizing a particular location in a TeX file with the corresponding location within a display of its typeset results. Overleaf’s built-in PDF viewer supports SyncTeX, which enables users to double-click on the PDF preview and jump to the corresponding location in your document’s source code.

Problem and remedy

todonotes loads the TikZ fadings library which can cause SyncTeX to fail on content input with \include{...} or \input{...} commands. If you don’t really need the todonotes package, you can comment it out and SyncTeX should then work—provided your main .tex file is located in the outermost (root) folder level of your Overleaf project.

Typesetting the Overleaf logo

With TeX Live 2018 it is now possible to typeset the Overleaf logo using the XeLaTeX or LuaLaTeX compiler—you can find out how to set your project’s LaTeX compiler in this Overleaf help article.

To include the Overleaf logo in your document:

1. Set your project to compile with XeLaTeX or LuaLaTeX.
2. Add \usepackage{academicons} to your document preamble.
3. Write \aiOverleaf or \aiOverleafSquare at the appropriate location in your document.

Overleaf would like to thank the developers of academicons for adding this feature to their LaTeX package.

Submitting to arXiv from Overleaf when using BibLaTeX/Biber

At the time of writing (November 2019) the arXiv service uses TeX Live 2016 to process LaTeX submissions, whereas new Overleaf projects (either created from scratch or when you clone a project) are now based on TeX Live 2018. Users wishing to submit an Overleaf project to arXiv can be affected by this mismatch in TeX Live versions due to unavoidable differences in .bbl files that arise from Overleaf running the newer BibLaTeX 3.12 and Biber 2.12 compared to arXiv’s use of BibLaTeX 3.7 and Biber 2.7. Note that Overleaf projects using BibTeX are unaffected.

To address this issue, Overleaf users wishing to submit their work to arXiv should either switch to using BibTeX, or contact us and we will revert their project back to using TeX Live 2017, which includes BibLaTeX and Biber versions that are compatible with arXiv's TeX Live 2016.

And finally, you can now typeset ducks

To conclude on a more light-hearted note we feel it would be remiss of us not to cover the important subject of ducks and duck-related packages in TeX Live 2018. The Overleaf team was saddened to receive reports from a flock of anxious users advising us that the duckuments placeholder package and the tikzducks packages were not compatible with Overleaf, generating the LaTeX error duckuments.sty not found. We are ever grateful to our user community, including those from across the pond who waded in, alerting us to such an important omission from our service. This is eggsactly the sort of feedback we are looking for because it is difficult to imagine LaTeX without ducks. So it is with great pride and a sense of fulfilling our civic duty to the LaTeX community that we can confirm the duck packages are back and trust they will fit the bill.

We leave you with these friendly tikzlings and tikzducks to celebrate this momentous occasion!

Getting Help

We’ll be updating this blog post with resolutions or workarounds for any other issues that come up after the upgrade. If your project has stopped working, please contact our support team and include the link to your project, and we'll try to help.