Dealing with a bizarre error due to single-quote characters

[Paul Gessler]

Hi Kirill,

I do not know exactly why it happens, but I believe you see the problem
come and go based on the content of the main file because the error will
only happen when there's a verbatim environment at or near a page boundary.
Here's a slightly more minimal example:

\begin{filecontents*}{input.latex}
%'
\end{filecontents*}

\documentclass{article}
\usepackage{scrlayer-scrpage}
\ohead{\input{input.latex}}

\begin{document}
\vspace*{\dimexpr\textheight-\baselineskip\relax}
\begin{verbatim}
x
\end{verbatim}
\end{document}

By changing the \vspace* amount, you can see the error go away when the
verbatim environment is not at the page boundary. I must admit I do not
know exactly why this happens, but it seems like it has to do with the
verbatim environment's catcode setup being in effect at the same time the
page header is processed.

Perhaps there is a more elegant solution than this, but a workaround I
found was to store the contents of the input.latex file in some macro, and
then use that macro inside \ohead rather than \input. This ensures that
the headings are created with a "standard" catcode setup rather than the
verbatim environment's catcodes. One way to achieve that is using the
catchfile package:

\begin{filecontents*}{input.latex}
%'
\end{filecontents*}

\documentclass{article}
\usepackage{scrlayer-scrpage,catchfile}
\CatchFileDef{\myfile}{input.latex}{}
\ohead{\myfile}

\begin{document}
\vspace*{\dimexpr\textheight-\baselineskip\relax}
\begin{verbatim}
x
\end{verbatim}
\end{document}

Other folks on the list may have a better technical explanation, or may
have a proper fix for this. But maybe this workaround helps you out in the
meantime. Best,

Paul

On Thu, 16 Sept 2021 at 20:09, Kirill Elagin <kirelagin at gmail.com> wrote:

> Hello,
>
> I am facing a completely crazy issue that has to do with \input’ing
> documents that contain single-quote characters. I have a document
> template that includes a pdf_tex image (from Inkscape) in page
> headers, which worked perfectly well, until at some point build
> started failing with:
>
> ```
> (./input.latex
> ! Missing $ inserted.
> <inserted text>
>                 $
> l.3 %% Accompanies image file
> ```
>
> It turned out that this was due to single-quote characters occurring
> in comments and string literals in the pdf_tex file. I managed to work
> the issue around for now by replacing those single-quotes with
> something else. What’s crazy about this is that (a) those
> single-quotes are completely valid and (b) the error appears and
> disappears seemingly randomly depending on the content of the main
> file at completely unrelated locations.
>
> Here is a minimal reproducer:
> https://github.com/serokell/latex-quote-repro.
>
> The example might look like I lost my mind, but, I promise, I did not.
> It consists of two files:
>
> 1. `input.latex` is the one that is being \input’ed, and it is just an
> arbitrary file containing a single-quote;
> 2. `main.latex` has a pretty random structure and is full of letters
> “x”, since I obtained it by minimising a real document.
>
> I realise that, unfortunately, this “minimal” example is not so
> minimal, as it depends on KOMA-Script, but that’s as far as I could
> get.
>
> The error is very sensitive to the content of the main file – removing
> any (non-essential) line will make the error go away; also I tried to
> minimise the actual gibberish content, so, in most cases, removing one
> letter “x” will also result in the error going away.
>
> I don’t understand if this is an issue with KOMA-Script or with LaTeX.
> The entire thing, honestly, doesn’t make any sense to me and the only
> reasonable explanation that I have is memory corruption. However,
> given the complexity of the setup, I guess, it might be something in
> KOMA as well, but I can’t prove this, since, due to the extreme
> sensitivity of the error, I can’t get rid of KOMA in the reproducer.
>
> In any case, I will be grateful for any advice and pointers in the
> right direction. I guess, the first thing I need to do is figure out
> where to report this for further investigation.
>
> Cheers,
> Kirill
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texhax/attachments/20210916/32bca1c1/attachment.html>