The first LaTeX prerelease for 2020-02-02 is available for testing

A few days ago we have submitted a new LaTeX development format to CTAN and by now it should be available to all users using MikTeX or TeX Live (on any operating system).

This format allows you to test the upcoming LaTeX release scheduled for 2020-02-02 with your documents or packages. Such testing is particularly important for package maintainers to verify that changes to the core LaTeX haven’t introduced incompatibilities with existing code. We try to identify any such problem beforehand, but such an undertaking is necessarily incomplete, which is why we ask for user testing.

Besides developers we also ask ordinary users to try out the new release candidate, because the more people are testing the new format, the higher the chances that any hidden problems are identified before the final release in February hits the streets.

Processing your documents with the prerelease is straightforward. All you have to do is to replace the invocation command by appending -dev to the executable, e.g., on the command line you would run

pdflatex-dev myfile    or    lualatex-dev myfile    or    xelatex-dev myfile

instead of using pdflatex, lualatex or xelatex. If you use an integrated editing environment, then it depends on the system how to configure it to use an alternative format; but in any case the necessary modification should be straightforward.

Main features of 2020-02-02 prerelease 2

For technical reasons this first prerelease is labeled “prerelease 2”. Prerelease 1 existed only for a few hours on CTAN, as it was missing some files due to a problem in the build process, but because it was already on CTAN we had to increase the prerelease number.

A new LuaTeX engine coming up …

In TeXLive 2020 the LuaLaTeX format will always use the new LuaHBTeX engine, which is LuaTeX with an embedded HarfBuzz library. HarfBuzz can be used by setting a suitable renderer in the font declaration. An interface for that is provided by the fontspec package. This additional font renderer will greatly improve the shaping of various scripts, which are currently handled correctly only by XeTeX.

To simplify the testing of the new engine, the necessary executables have been added to MiKTeX and TeXLive 2019 and both have changed the LuaLaTeX-dev format to use it. This means you can already now test the new engine by using the prerelease!

Even if you have no need for the new HarfBuzz functionality it might be worthwhile running some tests, because, from 2020 onwards this will be the only LuaTeX engine for which a LaTeX format will be distributed in TeXLive and MikTeX from 2020 onwards.

Improved load-times for expl3

The LaTeX3 programming layer, expl3, has over the past decade moved from being largely experimental to broadly stable. It is now used in a significant number of third-party packages, either explicitly or implicitly (e.g., by loading xparse to define user command interfaces), so that many documents load the expl3 code at some point in the preamble. Most LaTeX documents compiled using XeTeX or LuaTeX load fontspec, which is written using expl3 so in these engines it is nearly always used.

The expl3 layer contains a non-trivial number of macros, and when used with the XeTeX and LuaTeX engines, it loads a large body of Unicode data. This means that even on a fast computer, there is a relatively large load time penalty whenever expl3 is needed.

For this release, the team have made adjustments in the LaTeX 2e kernel to pre-load a significant portion of expl3 when the format is built. This is transparent at the user level, other than the significant decrease in document processing time: there will be no “pause” for loading Unicode data files. Loading of expl3 in documents and packages can be done as usual; it will, at some future time, become possible to omit

\RequirePackage{expl3}

entirely, but, to support older formats, this explicit loading is at present still recommended.

Please test now — even though there is more to come

We ask you to test now, because (unless we made some mistakes) the above changes should be transparent to the user — other than speeding up the load process or allowing to handle complicated scripts with LuaLaTeX that before would not work correctly.

Probably early January we expect to distribute another prerelease which will most likely contain improvements to the font support for all engines.

The prereleases will never go stale in the future (we hope)

Starting with this prerelease we will make sure that the prerelease in the distributions either matches the main release code or will be newer than the current main release. This was not the case in the last few weeks when the main release was 2019-10-01 with a few hot fixes added, but the -dev format was still from some day prior to October.

In the future we intend to ensure that this does not happen, so that, to avoid confusion, the distributed development release is always newer or the same as the current main release.

More details on prereleases please …

More details and some background information about these concepts and the process of the development formats is available in a TUGboat article:

The LaTeX release workflow and the LaTeX dev formats

• Frank Mittelbach
• TUGboat 40:2, 2019
• Abstract

  How do you prevent creating banana software (i.e., software that gets ripe at the customer site)? By proper testing! But this is anything but easy.

  The paper will give an overview of the efforts made by the LaTeX Project Team over the years to provide high-quality software and explains the changes that we have made this summer to improve the situation further.

Enjoy — Frank