I'm currently in the process of building a class file with preferrably a best practice setup of the macros. My current paradigm is to write all macros in (plain) TeX, since I find it contradictory to call dependencies on packages (be it stable releases or not) best practice.

Starting with the assumption that this is correct, I am willing to make use of the extensions provided by the pdf part of pdfTeX and pdfLaTeX (think the \pdfliteral{} command for colouring or what have you). First I'd like to know however what exactly I can expect of these commands. I really wish to use only stable macros in my class file so that this can be used in the distant future by anyone who so desires.

To phrase the question more concisely: Can I expect a change to the \pdf-related commands or can I consider them completely stable so that it compiles in the same way twenty years from now?

  • 1
    I think you get better answers when you ask this on the pdfTeX mailing list. Jan 4, 2015 at 12:03
  • 1
    When you say "Plain TeX", do you mean the TeX "primitives" (such as \long, \outer, \expandafter, \noexpland, and \relax), or the set of macros (described in the TeXbook) that build on the primitives to make TeX usable by humans? While it's true that by not relying on previously written package code you don't make yourself vulnerable to issues that may arise if the packages are ever changed significantly in the future, it's also the case that packages that have been around for a long time are probably thoroughly debugged by now. Why not make use of their embedded accumulated wisdom?
    – Mico
    Jan 4, 2015 at 12:08
  • 3
    If Adobe decides that is q is no more fashionable, then every \pdfliteral{q ...} will become unusable. Not that I expect this, but it's an example of what can go wrong when something depends on third party software.
    – egreg
    Jan 4, 2015 at 12:09
  • 2
    You don't say quite what you want to achieve, but for example \pdfliteral is really required to do some low-level stuff with pdfTeX as it's more-or-less part of the driver interface. What do you plan to do about working with other drivers (dvips, xdvipdfmx, etc.)?
    – Joseph Wright
    Jan 4, 2015 at 12:39
  • @JosephWright Thank you for your answer. I intend to leave the options open to make the output as device independent as possible. I'm not sure yet how I wish to achieve this but I'll first have to investigate the pdf extensions to understand what I'm doing.
    – 1010011010
    Jan 4, 2015 at 16:53

1 Answer 1


As noted in a comment, an ex cathedra answer here really can only come on the pdfTeX mailing list, but hopefully we can at least examine the likely factors involved.

As development effort has moved from pdfTeX to LuaTeX, changes to pdfTeX beyond strict bug fixes seems very unlikely. Indeed, the efforts made in developing pdfTeX have had a strong sense of maintaining stability, which is why both TeX Live and MiKTeX have been prepared to use pdfTeX as the default engine for everything except tex (which will always use an unmodified version of Knuth's TeX).

If you look at the primitives provided by pdfTeX beyond those provided by Knuth's TeX90, the most 'stable' set are the e-TeX extensions, finalised in 1999 and unchanged since (barring bug-fixes). Those prefixes \pdf... may be examined by the version of pdfTeX which first introduced them: those available for longer are more likely to be widely used and thus 'stable' by virtue of the fact that removal would be a significant issue. That said, there has not been a major release of pdfTeX for some years and even then removal of primitives has been very carefully handled (a deprecation phase before withdrawal meaning that several years notice have been available).

If one looks specifically at \pdfliteral, it is equivalent to \special{pdf: ...} and is thus directly linked to the PDF mode driver implemented by pdfTeX. It is thus directly linked to the 'core' ability of pdfTeX and so can be regarded as as stable as anything else.

All of this is of course coloured by what we can interpret as 'stability'. Even Knuth's TeX can still change in the sense of bug fixes, and while these are now extremely rare any change at all in the sources may have a knock-on on one or more use cases. Looking at anything more complex, using TeX in the future depends on the continued availability of TeX systems, the appropriate binaries and so on.

Perhaps worth noting here is that the question seems to focus on developing LaTeX2e classes or packages. (Classes should primarily be about design, so I will assume that the 'programming' element here is in a package.) It thus relies on the fact that LaTeX2e itself will be stable enough that no changes are required to keep files entirely unchanged for that reason. The LaTeX team have been careful to try to provide a system which seeks to do this, but there are bugs in LaTeX and fixing them does mean some changes over time.

What I would note in the LaTeX team context is that for work on expl3/LaTeX3 (where the team want to have a 'stable' underlying basis) the use of a small number of \pdf... primitives has been regarded as sensible. When using pdfTeX, string comparisons use \pdfstrcmp while scalings and rotations exploit \pdfliteral. Graphics inclusion is not written for this but we might assume that \pdfximage and so forth will be used.

  • I'll accept your answer ás soon as I have additional information from the mailing list (for answer completeness). Or maybe authority can provide insight in another answer.
    – 1010011010
    Jan 4, 2015 at 18:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .