Ist KOMA-Script UTF8-fest?

Keine der KOMA-Script-Klassen und keines der KOMA-Script-Pakete enthält auch nur ein einziges Zeichen außerhalb von US-ASCII. Damit ist die Codierung der Dateien von KOMA-Script in jedem Fall unkritisch für die Änderung in LaTeX 2018/04/01.

Wieso aber kommt es dann zu dem Fehler? Nun, der Fehler ist nicht KOMA-Script-spezifisch. Er tritt mit den Standardklassen (und sogar ohne das Laden einer Klasse) genauso auf, ist dort nur nicht sofort sichtbar:

\makeatletter
\def\input@path{{\string"Bärendreck/\string"}}
\makeatother
\InputIfFileExists{somefile}{\def\success{Yes}}{\def\success{No}}
\documentclass{article}
\begin{document}
\success
\end{document}

Das Problem ist, dass hier innerhalb von \InputIfFileExists die Anweisung \input@path expandiert wird, dabei in Folge der Encoding-Umstellung in LaTeX das ä aktiv ist, expandiert wird, aber aufgrund der noch nicht erfolgten Font-Initialisierung noch nicht zu etwas gültigem expandiert werden kann. Das führt dann mit pdflatex zu der etwas seltsamen Fehlermeldung

./test-encoding.tex:4: LaTeX Error: Missing \begin{document}.
 
See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              
 
l.4 ...efile}{\def\success{Yes}}{\def\success{No}}
 
You're in trouble here.  Try typing  <return>  to proceed.
If that doesn't work, type  X <return>  to quit.
 
LaTeX Font Info:    Try loading font information for +cmr on input line 4.
LaTeX Font Info:    No file cmr.fd. on input line 4.
 
LaTeX Font Warning: Font shape `/cmr/m/n' undefined
(Font)              using `/cmr/m/n' instead on input line 4.
 
./test-encoding.tex:4: Corrupted NFSS tables.
wrong@fontshape ...message {Corrupted NFSS tables}
                                                  error@fontshape else let f...
l.4 ...efile}{\def\success{Yes}}{\def\success{No}}
 
This error message was generated by an \errmessage
command, so I can't give any explicit help.
Pretend that you're Hercule Poirot: Examine all clues,
and deduce the truth by order and method.
 
 
LaTeX Font Warning: Font shape `/cmr/m/n' undefined
(Font)              using `OT1/cmr/m/n' instead on input line 4.

Und bevor nun jemand auf die Idee kommt, dann sei die Verwendung von \InputIfFileExists vor der Font-Initialisierung eben verboten: Nein, das ist es nicht. Stattdessen ist es schlicht verboten, Sonderzeichen in Dateinamen zu verwenden, ohne sie vor derartiger, unerwünschter Expansion zu schützen. Die Lösung für obiges Problem lautet schlicht \detokenize:

\makeatletter
\def\input@path{{\detokenize{"Bärendreck/"}}}
\makeatother
\InputIfFileExists{somefile}{\def\success{Yes}}{\def\success{No}}
\documentclass{article}
\begin{document}
\success
\end{document}

und natürlich funktioniert das auch mit KOMA-Script:

\makeatletter
\def\input@path{{\detokenize{"Bärendreck/"}}}
\makeatother
\documentclass{scrartcl}[2018/03/30]
\begin{document}
OK
\end{document}

Die Anführungszeichen in der Umdefinierung von \input@path sind in obigem Beispiel übrigens überflüssig. Sie stammen aber aus einer realen Anfrage, in der unter Windows das HOME-Verzeichnis eines Benutzers verwendet wurde und darin, wie unter Windows leider allzu häufig üblich, ein Leerzeichen verwendet wurde. Die von mir vorgeschlagene Lösung wurde im Gegensatz dazu mit TeX Live 2018 unter Linux mit LC_CTYPE=de_DE.UTF-8 getestet. Ich gehe jedoch davon aus, dass sie auch unter Windows funktioniert. Allerdings könnte es dort noch Probleme je nach verwendeter Filesystem-API geben. Rückmeldungen, ob obige Lösung mit MiKTeX und TeX Live 2018 unter Windows funktioniert, sind also willkommen.

Achja: Ich empfehle, solche Spielchen mit \input@path eher zu meiden und stattdessen ggf. die Umgebungsvariable TEXINPUTS zu nutzen. Diese wird üblicherweise nicht auf TeX-Makro-Ebene, sondern beispielsweise von kpathsea auf Programmebene ausgewertet, womit sowohl Probleme mit Leerzeichen als auch Encoding-Probleme reduziert werden.

Achja: Die Verwendung einer UTF8-nativen Engine wie LuaTeX oder XeTeX (für obige Beispiele also die Verwendung von LuaLaTeX oder XeLaTeX) hilft ebenfalls, solche Probleme zu vermeiden. Dabei müssen nämlich die UTF8-Zeichen nicht aktiv gemacht werden.