# TeX Live 2018 broke compilation of labbook-based document

I've been keeping a lab notebook in LaTeX for several years. I have my own style file that is based on the labbook class.

Unfortunately, when I upgraded to TeX Live 2018 earlier this week, my lab notebook can no longer compile. I get the following error:

...
LaTeX Warning: Unused global option(s):
[index-totoc].

(./Notebook.aux) (/usr/local/texlive/2018/texmf-dist/tex/latex/base/ts1cmr.fd)
(/usr/local/texlive/2018/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
) (/usr/local/texlive/2018/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/usr/local/texlive/2018/texmf-dist/tex/latex/oberdiek/grfext.sty)
(/usr/local/texlive/2018/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
ABD: EveryShipout initializing macros
*geometry* driver: auto-detecting
*geometry* detected driver: pdftex

(/usr/local/texlive/2018/texmf-dist/tex/latex/translator/translator-basic-dicti
onary-English.dict)
(/usr/local/texlive/2018/texmf-dist/tex/latex/siunitx/siunitx-abbreviations.cfg
) (/usr/local/texlive/2018/texmf-dist/tex/latex/siunitx/siunitx-binary.cfg)
No file Notebook.bbl.
(/usr/local/texlive/2018/texmf-dist/tex/latex/hyperref/nameref.sty
(/usr/local/texlive/2018/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
(/usr/local/texlive/2018/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/usr/local/texlive/2018/texmf-dist/tex/latex/amsfonts/umsb.fd) [1{/usr/local/t
exlive/2018/texmf-var/fonts/map/pdftex/updmap/pdftex.map}] [2]
(./FYNotebook.tex
! Undefined control sequence.
\UseRawInputEncoding ...tencodingname \@undefined
\let \DeclareFontEncoding@...
l.11 \experiment{NJOY}

?

I apologize that I don't have a MWE. If I remove anything from my setup, then all kinds of things start breaking.

Has anyone seen this error and know what may be causing this?

• well \UseRawInputEncoding is a new command in the 2018-04-01 release but it's a bit hard to guess how it is being used here just from an error message – David Carlisle May 3 '18 at 21:46
• If making a MWE is too hard you could send me a zip file (which doesn't need to be minimal, and I won't make any data public) and I'll trace what it's doing in the 2018 release. (google my name and you will see my gmail address) – David Carlisle May 3 '18 at 21:52
• @DavidCarlisle see my MWE below. – Ulrike Fischer May 3 '18 at 21:55

Your class is 8-bit encoded and uses non-ascii chars in the code. this breaks as the default encoding of latex is now utf8. You can avoid the error by using \UseRawInputEncoding:

\UseRawInputEncoding %without it you get the error.
\documentclass[12pt]{labbook}

\begin{document}
\experiment{NJOY}
\end{document}
• While this solves the problem I wonder if I should specify a different encoding instead. Is that even possible? Is it a better, i.e., more long lasting, solution? – jlconlin May 3 '18 at 22:01
• @jlconlin yes it is the use of § in the class I'll post something in a bit – David Carlisle May 3 '18 at 22:02
• The problem is the class, it uses an ansi § – Ulrike Fischer May 3 '18 at 22:03
• @UlrikeFischer I think it's just using it as a macro argunment delimiter isn't it? – David Carlisle May 3 '18 at 22:11
• @DavidCarlisle yes I think that's what it is doing. One wonders why not a command... – Ulrike Fischer May 3 '18 at 22:14

The labbook.cls uses § as an internal delimiter for a macro argument.

\chardef\labbook@us=\catcode_
\catcode_=3 % funny catcode

just after the line \RequirePackage{makeidx} \makeindex and substitute all § characters with _ (which is otherwise not used in the class), doing also

\catcode`_=\labbook@us

just before the final \endinput, then the example file compiles without any problem.

Using an 8-bit character for that purpose is wrong anyhow; however, you can add

\UseRawInputEncoding

at the start of any file using labbook.cls and the compilation will go smooth.