16

The release of pgf 3.1 on Jan the 6th broke a nightly build I'm running. Updating the package locally allowed me to reproduce the error, so I'm certain that's what caused it.

Here is a broken MWE:

\input tikz
Help?
\bye

Here is the log of running tex on it:

This is TeX, Version 3.14159265 (TeX Live 2018) (preloaded format=tex)
(./main.tex
(/usr/local/texlive/2018/texmf-dist/tex/plain/pgf/frontendlayer/tikz.tex
(/usr/local/texlive/2018/texmf-dist/tex/plain/pgf/basiclayer/pgf.tex
(/usr/local/texlive/2018/texmf-dist/tex/plain/pgf/utilities/pgfrcs.tex
(/usr/local/texlive/2018/texmf-dist/tex/generic/pgf/utilities/pgfutil-common.te
x
(/usr/local/texlive/2018/texmf-dist/tex/generic/pgf/utilities/pgfutil-common-li
sts.tex))
(/usr/local/texlive/2018/texmf-dist/tex/generic/pgf/utilities/pgfutil-plain.def
(/usr/local/texlive/2018/texmf-dist/tex/generic/oberdiek/atbegshi.sty
(/usr/local/texlive/2018/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
(/usr/local/texlive/2018/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)
(/usr/local/texlive/2018/texmf-dist/tex/generic/oberdiek/ifpdf.sty)))
(/usr/local/texlive/2018/texmf-dist/tex/generic/pgf/utilities/pgfrcs.code.tex
(/usr/local/texlive/2018/texmf-dist/tex/generic/pgf/pgf.revision.tex)))
(/usr/local/texlive/2018/texmf-dist/tex/plain/pgf/basiclayer/pgfcore.tex
(/usr/local/texlive/2018/texmf-dist/tex/plain/pgf/systemlayer/pgfsys.tex
(/usr/local/texlive/2018/texmf-dist/tex/plain/pgf/utilities/pgfrcs.tex)
(/usr/local/texlive/2018/texmf-dist/tex/generic/pgf/systemlayer/pgfsys.code.tex
(/usr/local/texlive/2018/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex
(/usr/local/texlive/2018/texmf-dist/tex/generic/pgf/utilities/pgfkeysfiltered.c
ode.tex))
! Undefined control sequence.
\pgfkeyssetevalue ...gfkeys@temptoks =\scantokens
                                                  \expandafter {\expandafter...

\pgfkeys@ifcsname ...\fi \ifpgfkeys@csname@test #2
                                                  \else #3\fi
\pgfkeys@ifcsname ...gfkeys@csname@test #2\else #3
                                                  \fi
\pgfkeys@ifcsname ...gfkeys@csname@test #2\else #3
                                                  \fi
\pgfkeys@unpack ...pgfeov \else \pgfkeys@case@one
                                                  \fi \fi
\pgfkeys@@normal ...pgfkeysnovalue =\pgfkeys@stop
                                                  \pgfkeys@parse
...
l.17 \pgfkeys{/pgf/.is family}

The MWE breaks using tex, ptex and uptex. It works using etex, pdftex, xetex, luatex, eptex and euptex.

It seems to break when using anything that's missing etex extensions. That makes sense since \scantokens is such an extension.

I'm a bit surprised by the breaking change, and I might simply be missing something.

Does this actually mean that pgf lost some compatibility? If that's the case, does anyone know the rationale behind the decision (and perhaps a link to the commit)?

NOTE: There's no complaint here, I'd just like to learn more. I know infinite retrocompatibility is never to be expected, and I think the maintainers of pgf/TikZ are amazing.

8
  • 2
    Addendum: I tested with an older version and it works, so it seems that the recent update started using the extensions. – Phelype Oleinik Feb 4 '19 at 19:45
  • 2
    @PhelypeOleinik TikZ used to work with tex; I've used it a few times. It's also documented as working (except for some things explicitly marked as not working) in the TikZ manual, e.g. see page 30 (section 2.2.2) which says "Gerda can typeset this file using either pdftex or tex together with dvips." I'd go further than the OP, this is definitely a bug. Or if the breaking change was intentional, there doesn't seem to be any announcement. – ShreevatsaR Feb 4 '19 at 20:30
  • 2
    I'm voting to close this question as off-topic because Stack Exchange is not the place to report bugs. Also this is a duplicate bug of sourceforge.net/p/pgf/bugs/508 – Henri Menke Feb 4 '19 at 20:34
  • 13
    @HenriMenke I think the question "does pgf work with classic tex" is a reasonable question to have here, even if the answer is "no, it requires etex" It doesn't have to be seen as a bug report. – David Carlisle Feb 4 '19 at 20:37
  • 5
    @HenriMenke Either it's a bug or it isn't. :-) If TikZ now requires etex then that's a reasonable answer, and the question makes sense because that wasn't the case, and some of the documentation indicates otherwise (e.g. the 2.2.2 mentioned above, also 82.2 which says "This command will use eTeX’s \ifcsname command, if available, for efficiency. This means, however, that it may behave differently for TeX and for eTeX when you set keys to \relax".) and it's not mentioned in Changelog -- but even if it was, a lot of questions on this site can be answered by reading something or the other. – ShreevatsaR Feb 4 '19 at 20:49
23

The answer why PGF 3.1 does not support Knuth TeX is two-fold.

  1. It is the current year. By now e-TeX is over 20 years old and has simplified TeX development tremendously. I consider it a bug on your side that you are not using e-TeX. Unfortunately TeX Live ships a tex binary which does not enable e-TeX extensions. You have to use etex instead.

  2. Development of TikZ/PGF has been dead for a couple of years because Till Tantau has apparently abandoned the project entirely and Christian Feuersänger has been busy in offline life. Around Christmas 2018 I was contacted by Christian (via Stefan Pinnow) to join the PGF development team so that bugs can be fixed and a new release can be prepared. Christian was keen to publish the release around Christmas time before getting back to work. This left very little time for testing and a lot of bugs and broken bug fixes ended up as part of the 3.1 release. My goal is to actively participate in TeX Live 2019 pretest to eradicate all the bugs before the next release. Bottomlined I apologize for this poor quality release but the circumstances forced us to release quickly.

On another note, I'd like to ask everyone to please report bugs on the official PGF bugtracker rather than on Stack Exchange. It's unfortunate that you don't earn internet points there, but it simplifies the work of the developers quite a lot. If you really want to indulge those sweet reputation points, you can post a question on Stack Exchange in addition to your bug report on the official PGF bugtracker. Thanks.

If you are unsure whether what you are observing is a bug and you have already posted it here, but were told to open a bug report, please repeat all the necessary information to reproduce the problem on the PGF bugtracker as well. Bug reports which only contain a link are not very nice as they have an undertone that you do not value the developers' time.

10
  • 1
    BTW, the specific bug you are talking about is fixed sourceforge.net/p/pgf/bugs/508 – Henri Menke Feb 4 '19 at 21:46
  • 2
    BTW not just TL but any distribution is supposed to ship a tex with no extensions: DEK's wishes. I think it's totally reasonable to require eTeX extensions (LaTeX does so since 2017 IIRC). It excludes people using the simplest program for some (educational?) reason or using a derivative that doesn't incorporate eTeX (like NTS, web2w, some obscure/in-development ones), but probably very few of them; eTeX is only about 20% bigger. – ShreevatsaR Feb 4 '19 at 22:54
  • 2
    Your analysis of the situation is biased by your deep understanding of TikZ's code. When I encounter an error, I don't know if it's a bug or if the problem comes from me. So I start by asking the question on tex.stackechange and depending on the answers, I know it's a bug or an error on my part. At that time and only at that time, I will report the bug. If there are no bugs reported on the tracer bug, will you be satisfied? Of course not. Thus, it is preferable that bugs be reported first here in order to be sure and certain that they are bugs. – AndréC Feb 5 '19 at 5:19
  • 2
    @AndréC When loading the package throws an error it is quite obviously a bug. – Henri Menke Feb 5 '19 at 5:26
  • 1
    @HenriMenke The idea was that if someone on one system thought they were using “TeX”, and created some document that behaved in a certain way when run through tex, then on any other system where tex was available, the same command would produce the same behaviour. (E.g if they used extensions and it wouldn't work on another computer, their document isn't portable.) So indeed the name tex was “reserved”. (Of course it's debatable how much sense this makes today when someone insisting on using plain TeX probably knows what they're doing, but that's the original reason for the restriction.) – ShreevatsaR Feb 7 '19 at 12:36

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.