So, inspired by Fixing LaTeX2e I've been wondering: Should I be loading fixltx2e and/or eTeX by default?

Typically I start my documents as

%Page layout here
\documentclass[letterpaper, 11pt]{article}

Should this be changed to

%Page layout here
\documentclass[letterpaper, 11pt]{article}

Or should I only load these when I encounter a problem that one of them is needed to fix? Also, what order should I load them in?

  • Wait a couple months and it won't be at all necessary :) – yo' Jan 7 '15 at 19:57
  • 1
    @yo' Not into the engine rather into the LaTeX2e format – Joseph Wright Jan 7 '15 at 20:02
  • 1
    @SeanAllred shoving off couple inches from several miles :D /sarcasm You should watch David Carlisle: Fixing LaTeX2e. – yo' Jan 7 '15 at 20:03
  • 1
    @SeanAllred Read the blog post :-) There is a need for some changes to keep things working: this is all code that is in use anyway, it's a question of trying to put it in the right places. – Joseph Wright Jan 7 '15 at 20:05
  • 1
    Link for the lazy (or those unaware that Joseph keeps a blog). It's on my reading list for tonight! :) – Sean Allred Jan 7 '15 at 20:12

as of a CTAN check on 01/11/2016, here's what I uncovered...

their record for fixltx2e package says:

This pack­age does noth­ing other than is­sue a warn­ing in cur­rent LATEX Re­leases. In ear­lier re­leases it was used to dis­tribute bug fixes and im­prove­ments to the LATEX ker­nel. See the la­texre­lease pack­age for fur­ther de­tails of the new bug fix pol­icy. https://www.ctan.org/topic/obsolete

and for etex it says:

An ex­tended ver­sion of TEX (which is ca­pa­ble of run­ning as if it were TEX un­mod­i­fied). E-TEX has been spec­i­fied by the LATEX team as the en­gine for the de­vel­op­ment of LATEX 2e, in the im­me­di­ate fu­ture; as a re­sult, LATEX pro­gram­mers may (in all cur­rent TEX dis­tri­bu­tions) as­sume e-TEX func­tion­al­ity. Devel­op­ment ver­sions of e-TEX are to be found in the TEX live source repos­i­tory.

and for etex-pkg, there is a "Version 2.5 2016-01-07" out now. The readme file only says:

The package provides a straightforward interface to many of the extensions offered by e-TeX; in particular, it modifies LaTeX's register allocation macros to make use of the extended register range. Note that for LaTeX releases from 2015 onwards, this package is not required to use the extended register range.


Loading the etex package should be safe in almost every case. It's main aim is to alter the allocation scheme to use the extra space made available by the e-TeX, and it does this in such a way as to avoid as far as possible any conflict. (Note that the team plan to enable use of the extended registers in a format release but this will use a subtly different approach to the etex package.) As to whether you need to load etex: only if you find yourself running out of registers. The idea here in adding to the format is that this will free both package authors and end users from worrying about this.

Loading fixltx2e is a bit more tricky, and indeed the team are working to ensure that this can be 'backed out' of the format once it is built in as standard. The changes in fixltx2e are not currently in latex.ltx as they in some way change behaviour. Some of that is nowadays not too much of an issue: for example, making \( and \) robust uses two additional csnames, which could not go into the format when the issue came up (at the time this could have pushed some people's documents over the edge in terms of name use). Other changes in fixltx2e may alter existing documents in some way, and that is more tricky. (For archiving reasons, some documents cannot have any changes at all in output.) That said the content of fixltx2e is all stuff that arguably should have been in the format when released in 1994. As noted in another answer, it's quite possible never to run into a need for fixltx2e. As to whether you should load the package: I'd argue 'yes' as these are things that really should be fixed. However, in many cases you might not notice the difference.

That brings us to the question of why the team are looking to add the functionality here to the standard kernel. In the etex case, neither users nor package authors really should have to worry about enabling an extended allocation scheme. The format should have some 'awareness' of the capabilities available and use them. In terms of fixltx2e, as already noted this is stuff that should have been in the kernel anyway. What adding it will bring is that users won't have to know about the cases where it's useful and package authors should be able to predict more readily the form of certain commands (for patching). There will be a mechanism to reverse this inclusion: there are a few cases where the fixes alter outcomes rather than avoiding out-and-out error, and those are important for the archival stability side of things.

  • 1
    So, if I don't care about backwards compatibility (I'm writing new documents, not altering old ones), I might as well just copy and past fixltx2e into each document. e-TeX I could, but since I'll probably never need it, I might as well not worry about it as LaTeX will tell me if I do. Also: I did hit one of the non-robust things once, which is when I first heard of it. – Canageek Jan 8 '15 at 0:37

These packages serve different purposes. fixltx2e corrects some design errors of LaTeX2e; if these errors bother you, you should use it. They rarely bothered me - I think I encountered them no more than two or three times in my work.

On the other hand etex helps to use the additional features of etex engine; as a user you probably do not need them anyway - unless you, for example, want to define several hundred counters. Class and package designers need them more often; I found I must load them for some of my classes. On the other hand, etex produces an (admittedly small) overhead, so I usually do not load it unless I need it. Anyway, if you use a class or package that needs these features, the designer probably already loaded it. The only scenario when a user must load etex explicitly is when she has several packages each heavily using TeX resources, but still working without etex separately. Then the total may exceed the limit.

  • 3
    In terms of 'overhead' for etex are you thinking of the additional tokens to be skipped in the test for a free register? That is very small in terms of any real document. – Joseph Wright Jan 7 '15 at 20:37
  • 2
    I agree, but some of my machines are oversized smartphones, see tug.org/TUGboat/tb33-2/tb104veytsman-pad.pdf. I have a habit to save cycles. – Boris Jan 7 '15 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.