8

Since updating to the 2020 Fall release (MikTeX on Windows but also tested with TeXLive), I can no longer compile files where tables are imported from an external file using \input and followed by \hline (or \bottomrule).

Things work perfectly with older releases.

Note that it works if the last \\ is outside the file to be imported, but this is not a feasible option if the tables are created automatically from other softwares.

Here is a MWE:


\begin{document}

\begin{table}
  \caption{Table in text}
  \begin{tabular}{lcc}
    a & 1 & 2\\
    b & 1 & 2\\
    \hline
  \end{tabular}
\end{table}

\begin{table}
  \caption{Table in other file 1}
  \begin{tabular}{lcc}
    \input{table1}
    \hline
  \end{tabular}
\end{table}

\begin{table}
  \caption{Table in other file 2}
  \begin{tabular}{lcc}
    \input{table2}\\
    \hline
  \end{tabular}
\end{table}

\end{document}

with external files:

table1.tex:

    a & 1 & 2\\
    b & 1 & 2\\

table2.tex:

    a & 1 & 2\\
    b & 1 & 2

Here is the log when it fails:

This is pdfTeX, Version 3.14159265-2.6-1.40.21 (MiKTeX 20.10)
entering extended mode
(MWE.tex
LaTeX2e <2020-10-01> patch level 1
L3 programming layer <2020-10-05> xparse <2020-03-03>
("C:\Program Files\MiKTeX\tex/latex/base\article.cls"
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
("C:\Program Files\MiKTeX\tex/latex/base\size10.clo"))
("C:\Program Files\MiKTeX\tex/latex/l3backend\l3backend-pdftex.def") (MWE.aux)
(table1.tex)
! Misplaced \noalign.
\hline ->\noalign 
                  {\ifnum 0=`}\fi \hrule \@height \arrayrulewidth \futurelet...
l.18     \hline
               
! You can't use `\hrule' here except with leaders.
\hline ->\noalign {\ifnum 0=`}\fi \hrule 
                                         \@height \arrayrulewidth \futurelet...
l.18     \hline
               
! Missing number, treated as zero.
<to be read again> 
                   \futurelet 
l.18     \hline
               
! Illegal unit of measure (pt inserted).
<to be read again> 
                   \futurelet 
l.18     \hline
               
(table2.tex) [1{C:/Users/Gouel/AppData/Local/MiKTeX/pdftex/config/pdftex.map}]
(MWE.aux) )
(see the transcript file for additional information)<C:/Program Files/MiKTeX/fo
nts/type1/public/amsfonts/cm/cmr10.pfb>
Output written on MWE.pdf (1 page, 14750 bytes).
Transcript written on MWE.log.

With an older release under Linux, it works perfectly:

This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./MWE.tex
LaTeX2e <2020-02-02> patch level 2
L3 programming layer <2020-02-14>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdfmode.def)
(./MWE.aux) (./table1.tex) (./table2.tex) [1{/var/lib/texmf/fonts/map/pdftex/up
dmap/pdftex.map}] (./MWE.aux) )</usr/share/texlive/texmf-dist/fonts/type1/publi
c/amsfonts/cm/cmr10.pfb>
Output written on MWE.pdf (1 page, 13788 bytes).
Transcript written on MWE.log.
1
  • 1
    You could use \input table2.tex (without the braces) in which case \input will use the primitive behaviour of TeX (except that it still isn't fully expandable as it has to test whether there is an opening brace). Note that this might restrict the supported file names (ASCII without spaces should be fine). – Skillmon Oct 23 '20 at 6:20
12

Yes, LaTeX changed here, but it also added new environments hooks, and you could use them to change to the primitive input in all tabular, This would have the additional benefit, that it will also work, if the file starts with a \multicolumn.

(That the engine accepts a braced input is rather new too).

\documentclass{article}

\begin{filecontents}{table1.tex}
a & 1 & 2\\
 b & 1 & 2\\
\end{filecontents}    

\makeatletter
%primitive input in tabular
\AddToHook{env/tabular/begin}{\let\input\@@input}
\makeatother
\begin{document}
\begin{tabular}{lcc}
    \input{table1}
    \hline
  \end{tabular}
\end{document}
3
  • Thanks. Good to know that I was not crazy. This problem puzzled me for days. It is good to have another solution to input files with braces. – Christophe Gouel Oct 23 '20 at 7:07
  • 1
    \input is a rather complicated command (it uses \InputIfFileExists internally), so it never was fully expandable, and in tabular only some things worked more or less by luck, not by design. And as \InputIfFileExists has been extended, it now breaks. – Ulrike Fischer Oct 23 '20 at 7:16
  • @ChristopheGouel well, my quick and dirty hack of directly using \@@input instead will still allow braces (as this is what this answer does as well). Nevertheless, this answer is preferable as it requires less manual correction. – Skillmon Oct 23 '20 at 8:28
8

Using the primitive behaviour of TeX's \input works. This can be used in LaTeX if you omit the braces around the filename, in which case LaTeX will fallback to the primitive.

You'll lose some of the niceties of LaTeX's file handling (no hooks, no utf8 support for filenames in pdfTeX, no spaces in filenames allowed, etc.) but just to input a table body I guess this should be fine.

Since the way LaTeX needs to test for an opening brace isn't expandable, you still can't use arbitrary contents in your table. The first row can't start with something needing \noalign (so no rules here for example) and the first cell can't start with something needing \omit (so no \multicolumn here for example). If that is needed, instead of using \input you'd have to directly call the primitive, which is named \@@input in LaTeX (you'll either need \makeatletter...\makeatother around your table or have to call it with \csname @@input\endcsname mytable1).

\documentclass[]{article}

\begin{filecontents}{mytable1.tex}
    a & 1 & 2\\
    b & 1 & 2\\
\end{filecontents}


\begin{document}
\begin{tabular}{lcc}
  \hline
  \input mytable1
  \hline
\end{tabular}
\end{document}

enter image description here

3
  • 1
    It works perfectly. Thank you. For now, I will adjust all my TeX files for this. However, it remains that this was a huge break for a new release. Am I the only one to have this problem? – Christophe Gouel Oct 23 '20 at 6:31
  • 1
    @ChristopheGouel most people don't rely on this behaviour of \input to include a table body which has to be followed by something needing \noalign or \omit, so I'd not say you're definitely the only one, but most likely one of the unfortunate few. (For example I never included a table body with \input but always with \@@input for the maybe 2 cases I needed this... mostly because it could've started with \toprule or similar) – Skillmon Oct 23 '20 at 6:33
  • @ChristopheGouel You are not the only one, see tex.stackexchange.com/q/569333/45154 . Using the \bottomrule` command from the booktabs package is a frequent pattern, and leads to the same problem with \input. – mrupp Nov 6 '20 at 16:10

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.