Liebe KOMA-Experten,
ich habe heute meine TL2019-Installation aktualisiert (tlmgr update --all). Wobei ich komascript aus dem KOMA-Repository beziehe.
Nun bekomme ich beim Kompilieren eines Briefes mit scrlttr2 oder scrartcl/scrletter (s. MWE unten) die Fehlermeldung:
! LaTeX Error: Command \enclname undefined.
Wenn ich die folgende Zeile auskommentiere herrscht zwar Ruh, aber das Ergebnis gefällt mir nicht ... ;-)
\renewcaptionname{ngerman}{\enclname}{Anlage}
Bisher hat der Code mit TL19 problem-, naja zumindest lautlos funktioniert (letztes TL19-Update ist ca. drei, vier Monate her).
Frage: Woran liegt's und wie lässt sich das Problem beheben?
Vielen Dank für Eure Hilfe!
MfG
MM
\documentclass[version=last ]{scrlttr2} %]{scrartcl} %\usepackage{scrletter} \usepackage[% main=ngerman, %english, british, american, french, ]{babel} \renewcaptionname{ngerman}{\enclname}{Anlage} \begin{document} \begin{letter}{% Kunde }% \opening{Sehr geehrter Kunde,} das gewünschte Angebot finden Sie in der Anlage. \closing{Mit freundlichen Grüßen} \encl{Angebot} \end{letter} \end{document}
Teilantwort
Ich kann Dir noch nicht sagen, woran es liegt. Seltsam ist, dass beispielsweise das Umdefinieren von
\listfigurename
weiterhin auf diese Weise funktioniert.Ich kann Dir aber einen Workaround anbieten:
funktioniert.
Restantwort
Das Problem tritt nur für Begriffe auf, die in der Dokumentpräambel noch gar nicht definiert sind. Siehe auch die Hinweise dazu in den Release-Informationen zu KOMA-Script 3.27.
Danke für die Teilanworten ...
aber was bedeutet: "Das Problem [...] ist ab KOMA-Script 3.27a.3265 behoben."
Ich nutze wie gesagt das KOMA-repository (gepinnt), aber ein tlmgr install reinstal ... scheint mir nicht die genannte Version zu liefern.
Wie finde ich die aktuell installierte Version heraus. Im log des letzten build-Laufs steht:
"Document Class: scrlttr2 2019/10/12 v3.27 KOMA-Script document class (letter)"
Wie komme ich an die Version 3.27a.3265 ran? Ist diese evtl. nur in einem Development-Repository verfügbar oder muss ich auf ne Art internes Mirroring warten?
Vielen Dank nochmals!
MM
Wie in der Präambel der
Wie in der Präambel der Release-Seite zu lesen lesen ist
Da es in diesem Fall einen recht einfachen, dokumentierten Workaround gibt, werde ich für diesen Bug nicht auf die Schnelle eine Prerelease erstellen. Grundsätzlich erstelle ich nicht nach jedem gefixten Bug und nach jedem neu implementierten Feature direkt eine Prerelese. Der Bug, um den es hier geht, war aber bereits seit Monaten über Prereleases verfügbar – nämlich in allen Prereleaes seit dem 10. Juli, also seit dem am 23. Juli veröffentlichten KOMA-Script 3.27.3173.
Ob und welche Prerelease man verwendet, erkennt man in der Tat über die Versionsnummer der Klassen und Pakete. Releases haben Versionsnummern im Schema vMajorrelease.Minorrelease, Prereleases Versionsnummern im Schema vMajorrelease.Minorrelease.Revision. Wer dagegen eine Developer-Version verwendet, wird in der Regel eine Release-Versionsnummer mit dem Zusatz BETA angezeigt bekommen.
Verstehe, ich wusste nicht,
bzw. hätte nicht gedacht, dass das Erzeugen eines Releases notwendig ist und Aufwand bedeutet. Sorry für meine möglicherweise dreist erscheinende Erwartung.
Logisch
Nichts ist ohne Aufwand. Für die Prerelease nach der Umstellung auf UTF-8 musste ich sogar ein neues minimales TeX-Live 2019 auf dem Server installieren. Da sich etwas beim Format der Collection-Dateien in TeX-Live geändert hat, versagte dabei mein dafür vor drei Jahren geschriebenes Skript und ich musste das (unter enormem Zeitdruck) letzten Mittwoch von Hand machen.
Auch für eine Prerelease muss der jeweilige Entwicklungsstand (die Entwicklung geht ja ständig weiter) einen Punkt erreichen, an dem eine Prerelease überhaupt sinnvoll möglich ist. Solange mehr neue Fehler enthalten sind als beseitigt werden oder Neuerungen leicht mit Fehlern verwechselt werden können, weil sie komplett undokumentiert sind, wäre eine Prerelease kontraproduktiv. Also habe ich selbst dann, wenn die Erzeugung im Hintergrund abläuft, im Vorfeld reichlich Arbeit damit. Wenn bei der Erzeugung der Prerelease irgend etwas schief geht, wird es richtig aufwändig.
Bei einer Release kommt dann noch einmal reichlich zusätzliche Arbeit hinzu. Die aktuellen Anleitungen müssen extrahiert und auf den beiden Anleitungsseiten veröffentlicht werden. Das Release-Archiv selbst muss nach Sourceforge kopiert und dort eingepflegt werden. Seite mit der Vorschau auf die nächste Release muss zu einer Releaseinfo umgebaut werden. Die vorherige Releaseinfoseite muss vermerken, dass es eine neue Release gibt. Eine neue Vorschau auf zukünftige Releases muss erstellt werden. Ich muss Uwe informieren und Uwe muss dann die CTAN-Release erzeugen und vornehmen. CTAN wiederum muss die Release einpflegen und die Maintainer der TeX-Distributionen müssen aus der CTAN-Release dann Pakete für ihre Distributionen erzeugen. Für keinen Beteiligten ist KOMA-Script eine leichte Kost.
Und Stunden nach der Release gibt es dann Bug-Reports, die bearbeitet werden müssen und zu neuen Prereleases oder neuen Releases führen. Releases keinesfalls zu schnell, weil sonst eine Release die nächste jagt und irgendwann ich selbst, Uwe, das CTAN-Team oder die TeX-Live-Leute das große Würfelhusten bekommen.
Und dann gibt es noch die unangenehmen Zeitgenossen, die an jeder Änderung grundsätzlich etwas auszusetzen haben und das auch teilweise mehr als massiv. Natürlich nur, wenn sie nicht zufällig, sehr deutlich erkennbar selbst von er Änderung profitieren. Nein, ich meine damit nicht dich. Dein Bugreport gehört selbstverständlich zu den richtigen und wichtigen, von denen es leider viel zu wenige gibt. Dass ich davon genervt bin, dass er unmittelbar nach (statt lange vor) der Release erfolgte, ist mein Problem. Hätte ich besser aufgepasst, hätte ich das Problem jetzt nicht.
Du musst Dich also für nichts entschuldigen. Ich entschuldige mich für den Bug und dass ich möglicherweise nicht ganz verbergen kann, wenn ich mich über mich selbst ärgere.
Es ist natürlich nicht im Sinne des Erfinders...
... das KOMA-Repository - so wie ich es bisher praktiziere - nur dann und wann, dümmstenfalls nach einem Release-Announcement zu aktualisieren. Da diese Strategie der Reduzierung Deines Stresslevels nicht zuträglich seien dürfte, gelobe ich diesbezüglich Besserung.
Allerdings weiß ich noch nicht wie ich das hinbekomme: Unter Linux ist das dank Cron kein Problem, nur nutze ich zum TeXen Windows und da weiß ich nicht wie ich das als nicht-Admin vernünftig automatisieren kann. Am liebsten wäre mir ja eine E-Mail-Benachrichtigung über ein neues Pre-Release - falls Dein CMS das unterstützt, würde ich davon gerne Gebrauch machen um so zumindest einen kleinen Beitrag zum Stressabbau, bzw. zur Stressprävention leisten zu können.
Workaround: Ich versuche zukünftig öfter an das "tlmgr update --all" zu denken ... kann aber nichts versprechen.