Sie sind hier

scrlttr2, \\ in fromname zerbricht closing

Folgendes Minimalbeispiel von TeX.SX auf:

\documentclass{scrlttr2}
\begin{document}
\setkomavar{fromname}{Company Name\\John Public}
%\setkomavar{signature}{Company Name\\john Public}
\begin{letter}{empfaenger}
	\opening{Hallo}
	text
	\closing{schluss}
\end{letter}
\end{document}

liefert folgende Fehler:

Title: no
Subject: no
! Undefined control sequence.
\@gnewline ...\@nolnerr \else \unskip \reserved@e 
                                                  {\reserved@f #1}\nobreak \...
l.8 	\closing{schluss}
 
? 
! Undefined control sequence.
\@gnewline ...se \unskip \reserved@e {\reserved@f 
                                                  #1}\nobreak \hfil \break \fi 
l.8 	\closing{schluss}
 
? 

Einkommentieren der signature-Variable löst den Fehler auf. Auf die Schnelle habe ich keine relevanten Details gefunden, allerdings habe ich nicht wirklich Zeit in die Suche gesteckt.

forum: 
Bild von Markus Kohm

Die Verwendung/Funktion von \\ in fromname ist nirgendwo dokumentiert. Je nach Verwendung der Variablen kann dabei alles mögliche passieren. Derzeit ist die Verwendung von \\ AFAIR nun in fromaddress, toaddress und backaddress dokumentiert. Und dort hat es nicht die Funktion eines Zeilenumbruchs o. ä., sondern die Funktion eines Feldtrenners.

Wer einen Firmennamen benötigt, dem sei empfohlen, einen solchen als eigene Variable zu definieren und dann auch dessen Verwendung explizit zu definieren, wie das beispielsweise bei asymTypB.lco gemacht wird.

Alles klar, super, ich geb das mal so weiter. Danke :-)

Bild von Markus Kohm

Ich habe gestern Abend noch auf TSX geschaut, was dort der Ausgangspunkt war und festgestellt, dass es bereits sehr treffende Kommentare, beispielsweise den Lego-Kommentar, gibt. Nichtsdestotrotz habe ich versuchsweise die Implementierung von \closing so geändert, dass dieser Missbrauch von fromnamean dieser einen Stelle(!) keine Rolle mehr spielen sollte. Allerdings ist nicht gewährleistet, dass die verwendete Methode 100% kompatibel ist. Falls es also Meldungen geben sollte, dass etwas, was bisher funktioniert hat, jetzt nicht mehr funktioniert, werde ich abwägen, was von beidem der größere Missbrauch ist und dann ggf. auch wieder zur alten Methode zurückkehren.

Problem bei der Geschichte ist übrigens das Messen der Breite der Einzelteile von Gruß und Signatur. Das Setzen danach ist unproblematisch.

Grundsätzlich haben Formatierungsanweisungen in Variablen nichts verloren (das gilt natürlich ganz besonders für Lowlevel-Anweisungen wie \newline, das je nach Umgebung gar nicht mal das tut, was der Anwender meist erwartet). Variablen sind dazu da reine Inhalte aufzunehmen. Ausnahmen davon sind: location, firsthead, firstfoot, nexthead und nextfoot. Ursprünglich war location die einzige Ausnahme, weil ich für nur ein Element kein eigenes Konstrukt definieren wollte. Die vier Kopf-Variablen sind hinzu gekommen, weil es sich irgendwann zeigte, dass es praktisch ist, auf die Kopf- und Fußdefinition der ersten Seite zugreifen zu können. Ursprünglich wollte ich dafür dokumentieren, dass man sich Anwendermakros definieren soll, die dann sowohl für das Argument von \firsthead als auch \nexthead verwendet werden können. Da aber ganz offensichtlich immer mehr Anwender mit \newcommand rein gar nichts anfangen können und mit einem reflexartigen Schrei das Weite suchen, wenn sie eine solche Standardanweisung finden, die für argumentlose Anweisungen außerdem recht einfach zu verstehen ist, habe ich mich dann irgendwann dazu entschieden Köpfe und Füße auf Variablen umzustellen. Das ist eine der wenigen Designentscheidungen bei KOMA-Script, die ich inzwischen bereut habe. Ich hätte stattdessen einfach zwei Anweisungen \usefirstheadagain und \usefirstfootagain definieren sollen. Und bei der Gelegenheit hätte ich \setkomavar{location} durch \location ersetzen sollen, um die Variablenschnittstelle zu bereinigen. Weil ich das nicht gemacht habe, kommen Anwender jetzt verstärkt auf die Idee, dass sie in Variablen alles mögliche an Formatierungsanweisungen schreiben können. Zeilenumbrüche und vertikale Abstände sind dabei noch das kleinste Übel (das es eigentlich schon immer gab). Schlimmer sind die Leute, die das Schriftgrößenbefehle, Fontumschalter, Ausrichtungsanweisungen etc. einbauen. Es beschweren sich sogar Leute, die mit \makebox oder \parbox und ähnliches eine bestimmte Formatierung erzwingen, dass dann Änderungen wie die von \raggedsignature nicht mehr funktionieren. Die denken wirklich, dass ich in der Klasse nachträglich ihren Mist wieder ausbügle. OK, die meisten davon denken gar nichts, sondern holen sich eine dieser verkorksten Vorlagen (die möglicherweise sogar auf einer durchdachten Vorlage basieren) von irgendwo und verschlimmern die dann noch – und geben sie wieder weiter.

Ich bin jetzt, nach diesem Vorfall, allen ernstes am Überlegen für scrletter an der Stelle die Kompatibilität zu scrlttr2 aufzugeben und alle Variablen, in denen Formatierungsanweisungen geradezu erwartet werden, durch etwas anderes zu ersetzen. Ich werde an zwei Stellen in scrletter die Kompatibilität ohnehin aufgeben müssen, weil es Kollisionen mit den KOMA-Script-Klassen gibt (betrifft die Font-Einstellung für title und subject, die ggf. auch Konsequenzen für den Namen von Variablen hat). Dann kann ich im Abschnitt über Variablen nämlich noch einmal ohne wenn und aber definieren, dass Variablen nur und ausschließlich Inhalte ohne jegliche Formatierung und ggf. \\ ausschließlich mit der Bedeutung eines Feldtrenners enthalten dürfen.

Ich habe erst jetzt wieder hier reingeschaut. Danke für diesen kleinen Einblick in die Geschichte. Den Frust zum Thema Vorlage/Template kann ich übrigens nachvollziehen. ;-)

Comments for "scrlttr2, \\ in fromname zerbricht closing" abonnieren