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.

Paolo Brasolin
  • 3,614
  • I'm not sure that TikZ ever worked with (Knuth's) tex (I might be wrong). The incompatibility is due to the lack of the ε-TeX extensions in Knuth's TeX which are used by TikZ (\scantokens, for instance). They are available in most other engines. The original tex will never incorporate these extensions. – Phelype Oleinik Feb 04 '19 at 19:39
  • 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 04 '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 04 '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 https://sourceforge.net/p/pgf/bugs/508/ – Henri Menke Feb 04 '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 04 '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 04 '19 at 20:49
  • 1
    @ShreevatsaR Indeed, I said that before checking. Not a good idea ;) A grep -r scantokens in the pgf files show one occurrence of \scantokens (in pgfkeys.code.tex) which wasn't in previous ones, which is causing the problem OP noticed. – Phelype Oleinik Feb 04 '19 at 21:06
  • @ShreevatsaR This question is ill-phrased because no one apart from the PGF developers can answer it. The official way to ask the PGF developers a question is through the official PGF bugtracker. – Henri Menke Feb 04 '19 at 21:48

1 Answers1

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.

Henri Menke
  • 109,596
  • 1
    BTW, the specific bug you are talking about is fixed https://sourceforge.net/p/pgf/bugs/508/ – Henri Menke Feb 04 '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 04 '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 05 '19 at 05:19
  • 2
    @AndréC When loading the package throws an error it is quite obviously a bug. – Henri Menke Feb 05 '19 at 05:26
  • Thanks for all your efforts @HenriMenke!

    For anyone interested in the full context: the known bug was introduced by ac33f7 while fixing #306 and solved by 287814, 46eaad, and 4abefd thus closing #508. (continues...)

     – Paolo Brasolin Feb 05 '19 at 18:30
  • (...continued) The implemented solution amounts to generalizing this old shim. – Paolo Brasolin Feb 05 '19 at 18:30
  • @ShreevatsaR Any distribution is supposed ship TeX without extensions but I don't think that applies to the name of the binary. So you could have a tex binary with launches e-TeX and a tex90 (or so) binary which launches TeX. – Henri Menke Feb 07 '19 at 10:58
  • 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 07 '19 at 12:36
  • @HenriMenke I'm happy to see you moved to Github ! – Kpym Apr 04 '19 at 10:32
  • @HenriMenke I totally agree with AndréC that asking a question here in advance to know if it's a bug or not is a good thing (for you). Do you really want everyone to raise a bug report as soon as something doesn't work? – Kpym Apr 04 '19 at 10:40