Dealing with a bizarre error due to single-quote characters

[Kirill Elagin]

Hi Paul,

Wow, thank you, that’s such a good catch! Now it all makes sense.

Experimenting with this a bit, I also noticed that if I use your
example and put `hello % world` in the input file, somehow the first
page will literally contain “hello % world” in the header, while the
second one will correctly have only “hello”.

I am getting the same effect for `hello % world` and the same error
for `%'` with the standard report class and fancyhdr, so the problem
is not in KOMA – now we know this.
I guess I'll try to get rid of `fancyhdr` tomorrow to see if this is a
bug in LaTeX or in some code that got shared between fancyhdr and
KOMA.

Cheers,
Kirill

On Thu, Sep 16, 2021 at 11:58 PM Paul Gessler <pdgessler at gmail.com> wrote:
>
> 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
>>