Sie sind hier

Geplante Änderungen in zukünftigen KOMA-Script-Versionen

Bild von Markus Kohm

Dies wird die zukünftige Release, die bisher allenfalls im Source-Repository auf SourceForge und eventuell teilweise auch bereits als aktuelle Prerelease zur Installation für TeX Live und MiKTeX bereit steht.

Überlegungen:

Es gibt Überlegungen, nach über 10 Jahren die Entwicklung bei den Klassen von KOMA-Script 3 einzustellen und stattdessen mit komaclass (Arbeitsname) ein neues Grunddesign auf der Basis der derzeitigen Entwicklung von scrartcl und scrbook aufzustellen. Dabei würden alle alten Zöpfe abgeschnitten. Die bisherigen Klassen scrartcl, scrbook, scrreprt und scrlttr2 würden dann zukünftig unverändert bleiben. Neuerungen gäbe es nur noch in komaclass und den Paketen. Dabei würden bewusst Inkompatibilitäten beim Wechsel von den alten Klassen zur neuen Klasse in Kauf genommen. Diese Überlegungen stehen quasi in Konkurrenz zu den Änderungen, die nachfolgend bereits für die existierenden Klassen dokumentiert sind.

Geplante Änderungen:

Generell ist geplant, keine Änderungen auf Verdacht mehr herbeizuführen. Ich werde also künftig nur noch in seltenen Fällen Dinge nur deshalb implementieren, weil sie mir nützlich erscheinen. Vielmehr werde ich darauf warten, dass Dinge konkret nachgefragt werden und dann entscheiden, ob sie mir nützlich erscheinen und ich sie einbaue. Da mich solche Nachfragen seit einigen Jahren nur noch selten erreichen und auch Bugs fast nur noch von Leuten gemeldet werden, die mit meinem Repository für TeX Live, TDS-Archive und MiKTeX-Installationspakete gut zurecht kommen, wird es vermutlich nur noch hin und wieder vor allem Bugfix-Releases – das sind die mit den Buchstaben hinter der Nummer – geben.

Diese Änderung bedeutet keine Einschränkung bezüglich des Supports durch mich. Ich bin für Bug-Reports oder Hilfeanfragen zu meinen Klassen und Paketen weiterhin sowohl hier im Forum als auch per E-Mail (siehe erstes Kapitel der KOMA-Script-Anleitung bzw. des KOMA-Script-Buchs) zu erreichen.

Hinweis: Die Angabe einer bestimmten Versionsnummer in der nachfolgenden Liste bedeutet nicht, dass genau diese Version auch bereits über den jeweils angegebenen Link verfügbar ist. Die Auflistung eines Features ist auch keine Garantie, dass dieses in der dokumentierten Weise wirklich in der nächsten Version enthalten sein wird.

scrarticle, scrreport, scrletter (Klasse):
Neue Wrapper-Klassen für die Jüngeren unter uns, die sich nicht mehr an 8.3-Dateinamen erinnern können und deshalb Schwierigkeiten mit den normalen Klassennamen haben. Dabei verwenden die Wrapper-Klassen in \KOMAClassName weiterhin die alten Namen. Es gibt aber zusätzlich dann auch ein \KOMALongClassName, das eigentlich überflüssig ist, weil man es einfach aus scr\ClassName bilden könnte.
Hinweise: Diese ab KOMA-Script 3.27.3091 verfügbaren Wrapper-Klassen, die auf Anregung eines langjährigen Benutzers (sic!) implementiert wurden, sollten nicht als Freibrief verstanden werden, diese an Stelle der echten Klassen zu verwenden. Offiziell dokumentiert sind weiterhin nur scrartcl, scrreprt und scrlttr2. Ab KOMA-Script 3.27.3125 ist die Klasse scrletter eine Wrapper-Klasse für die Verwendung von Klasse scrartcl mit Verwendung von Paket scrletter. Damit bieten die Klasse und das gleichnamige Paket die gleichen Brief-Möglichkeiten, während scrlttr2 ggf. nicht denselben Funktionsumfang hat.
scrartcl, scrbook, scrreprt:
  • Es gibt Überlegungen, keine der Anweisungen, die der LaTeX-Kern zur Definition von Gliederungsbefehlen bereit stellt, mehr umzudefinieren und stattdessen nur intern in KOMA-Script durch eigene interne Anweisungen zu ersetzen. Die Gliederungsbefehle von KOMA-Script würden also insbesondere kein \@startsection, \secdef (das ist bereits der Fall), \@sect, \@ssect oder \@xsect mehr verwenden. Das hätte diverse Auswirkungen:
    • Pakete, die die genannten Makros aus dem LaTeX-Kern für die Definition von eigenen Gliederungsbefehlen verwenden, kommen nicht mehr in den Genuss von speziellen KOMA-Script-Erweiterungen.
    • Pakete, die die genannten Makros aus dem LaTeX-Kern umdefinieren, kommen KOMA-Script nicht mehr in die Quere.
    Für Pakete wie titlesec oder sectsty würde es bedeuten: Wird das Paket verwendet und Gliederungsbefehle damit umdefiniert, verhalten sich diese wie bei den Standardklassen. Für Pakete wie placeins würde es bedeuten, dass sie keinen Einfluss mehr auf die Gliederungsbefehle von KOMA-Script nehmen. Einerseits gäbe es also weniger Kompatibilitätsprobleme, andererseits aber mehr. Die Lösung für die neuen Probleme wäre jedoch, entweder die Pakete zu ersetzen, zu patchen (notfalls mit scrhack) oder mit Hilfe klar definierter Schnittstellen wie den neuen Do-Hooks direkt an KOMA-Script anzupassen.
    Tatsächlich ist derzeit unklar, ob die Änderung zu weniger oder zu mehr Problemen führen würde. In jedem Fall würde sie den Code in KOMA-Script aber zuerst einmal vereinfachen. Wann und ob mit Arbeiten in dieser Richtung begonnen wird, ist derzeit noch unklar.
  • Die interne Anweisung \bprot@dottedtocline ist veraltet und gibt eine entsprechende Warnung aus. Es ist durchaus geplant, sie zukünftig aus den Klassen zu entfernen.
    Hinweis: Diese in der TODO-Datei lang angekündigte Änderung ist ab KOMA-Script 3.27.3106 verfügbar.
  • Wird amsthm zusammen mit einer KOMA-Script-Klasse verwendet, entsteht eine neue Abhängigkeit von Paket xpatch. Obwohl ich normalerweise bemüht bin, derartige Abhängigkeiten zu vermeiden bzw. in scrhack auszulagern, wurde in diesem Fall beschlossen, das Wagnis vorerst einzugehen. Die Entscheidung ist jedoch nicht endgültig.
  • Um zu ermöglichen, dass die Nummerierung aller Gliederungsebenen via \setcounter{secnumdepth}{-\maxdimen} abgeschaltet werden kann (was beispielsweise scrartcl unter gewissen Umständen für Kolumnentitel nutzt), sind bei \DeclareSectionCommand nur noch level-Werte größer als -\maxdimen erlaubt.
    Hinweis: Diese Änderung/Klarstellung geht auf eine Frage bei TeX.Stackexchange und einen Kommentar zu einer dortigen Antwort zurück.
  • Die Anweisung \IfUseNumber{TRUE-Code}{FALSE-Code}, kann innerhalb der Überschriften und nur dort dazu verwendet werden, festzustellen, ob die aktuell in Verarbeitung befindliche Überschrift mit einer Nummer versehen wird oder nicht. Das schließt die Stellung von secnumdepth ebenso wie die Verwendung einer Sternform einer Gliederungsüberschrift oder \addpart, \addchap oder \addsec und bei scrbook auch \frontmatter, \mainmatter und \backmatter ein. Bei einigen Do-Hooks (siehe unten) kann diese Anweisung ggf. nützlich sein. Sie ist aber nicht bei allen Do-Hooks zulässig. Bisher ist sichergestellt, dass sie bei headings/begingroup/… und headings/endgroup/… gültig ist.
    Achtung: Im moving Argument einer Gliederungsanweisung ist der Befehl nicht gültig!
  • Der neue Do-Hook-Mechanismus (siehe Änderungen bei scrbase) wird verwendet. Folgende Hook-Ausführungen mit \ExecuteDoHook wurden bisher implementiert:
    • heading/begingroup/Überschriftenname: wird zu Beginn der Gruppe ausgeführt, in der auch \partlineswithprefixformat, \chapterlineswithprefixformat, \chapterlinesformat, \sectionlinesformat bzw. \sectioncatchphraseformat ausgeführt werden.
    • heading/endgroup/Überschriftenname: wird am Ende der Gruppe ausgeführt, in der auch \partlineswithprefixformat, \chapterlineswithprefixformat, \chapterlinesformat, \sectionlinesformat bzw. \sectioncatchphraseformat ausgeführt werden.
    • heading/preinit/Überschriftenname: wird ganz am Anfang eines Gliederungebefehls ausgeführt, also ggf. noch bevor der vorherige Absatz beendet wurde!
    • heading/postinit/Überschriftenname: wird am Ende der Initialisierung eines Gliederungsbefehls ausgeführt und ersetzt zukünftig \At@startsection. Die Anweisung ist jedoch nicht nur für den section-Stil, sondern auch für chapter und part verfügbar. Die veraltete Anweisung \At@startsection funktioniert weiterhin (nur für Überschriften im Stil section) wird aber auf den neuen Do-Hook abgebildet.
    • heading/branch/nostar/Überschriftenname: wird unmittelbar bei der Verzweigung zwischen Sternvarianten und Normalvarianten eines Gliederungsbefehls für die Normalvariante ausgeführt und ersetzt zukünftig \Before@sect. Die Anweisung ist jedoch nicht nur für den section-Stil, sondern auch für chapter und part verfügbar. Die veraltete Anweisung \Before@sect funktioniert weiterhin (nur für Überschriften im Stil section) wird aber auf den neuen Do-Hook abgebildet.
    • heading/branch/star/Überschriftenname: wird unmittelbar bei der Verzweigung zwischen Sternvarianten und Normalvarianten eines Gliederungsbefehls für die Sternvariante ausgeführt und ersetzt zukünftig \Before@ssect. Die Anweisung ist jedoch nicht nur für den section-Stil, sondern auch für chapter und part verfügbar. Die veraltete Anweisung \Before@ssect funktioniert weiterhin (nur für Überschriften im Stil section) wird aber auf den neuen Do-Hook abgebildet.
    Dabei ist Überschriftenname jeweils der Name einer Überschrift, wie er auch bei \DeclareSectionCommand etc. angegeben wird.
    Diese Hooks sind auf Anforderung der biblatex-Autoren teilweise ab KOMA-Script 3.27.3068, teilweise auch erst ab KOMA-Script 3.27.3071 verfügbar. Weitere Hooks dieser Art können je nach Notwendigkeit entstehen.
scrbase:
  • \IfArgIsEmpty ist nun \long.
    Diese Änderung ist ab KOMA-Script 3.27.3115 verfügbar.
  • Es wurde ein neuer Hook-Mechanismus namens Do-Hook-Mechanismus implementiert, der kaskadierte Hooks erlaubt. Dabei wird ein Hook durch einen Spezifikator bestimmt, der entweder ein String ist oder ein String gefolgt von einem mit / abgetrennten Spezifikator, also beispielsweise heading, aber auch heading/preinit/subsection. Zu dem Mechanismus gehören folgende Befehle:
    • \ExecuteDoHook{Spezifikator}: Diese Anweisung ist Paketautoren vorbehalten und dient dazu einen Do-Hook in der Implementierung eines Befehls zu verankern. Der Spezifikator darf nicht leer sein. Zunächst wird der erste String des Spezifikators abgetrennt. Dann wird String zum Hookname hinzugefügt und der Hook mit dem Rest des Spezifikators als angehängtes Argument ausgeführt. War der Rest nicht leer, wird er anschließend zum neuen Spezifikator und rekursiv die Ausführung von Code fortgesetzt, bis er leer ist.
      Beispiel: \ExecuteDoHook{heading/preinit/subsection} führt zunächst den Code von Hook heading mit dem Argument preinit/subsection aus. Dann den Code von heading/preinit mit Argument subsection und schließlich den Code von heading/preinit/subsection mit einem leeren Argument.
    • \AddtoDoHook{Hook}{Befehl}: Fügt den Befehl dem Hook hinzu. Zu beachten ist, dass bei Ausführung von Befehl immer ein Argument angefügt wird.
      Beispiel: Mit \AddtoDoHook{heading/preinit}{\typeout} wird der Befehl \typeout dem Hook heading/preinit hinzugefügt. So wird beispielsweise \ExecuteDoHook{heading/preinit/chapter} die Anweisung \typeout{chapter} ausführen, \ExecuteDoHook{heading/preinit/section} wird \typeout{section} ausführen etc. Wird dagegen mit \AddtoDoHook{heading/preinit/section}{\typeout} derselbe Befehl dem Hook heading/preinit/section hinzugefügt, so wird lediglich \ExecuteDoHook{heading/preinit/section} die Anweisung \typeout{} ausführen, während \ExecuteDoHook{heading/preinit/chapter} den Befehl nicht ausführen wird.
    • \AddtoOneTimeDoHook{Hook}{Befehl} arbeitet wie \AddtoDoHook{Hook}{Befehl}, allerdings wird der Code für den Hook nach Ausführung gelöscht. Code für One-Time-Hooks wird grundsätzlich nach dem Code für dauerhafte Hooks ausgeführt.
    • \ForDoHook{Spezifikator}{Code}: Durchläuft, wie für \ExecuteDoHook angegeben, die Teilspezifikatoren und führt für jede Unterteilung einmal Code aus. Dem Code werden dabei zwei Parameter angehängt: das Kopfelement und der Rest des Spezifikators.
      Eigentlich ist dies eine interne Anweisung zum Zwecke der Definition von \ExecuteDoHook. Normalerweise sollten Paketautoren (und erst recht Anwender) diese Anweisung nicht benötigen.
    • \SplitDoHook{Spezifikator}{Kopfbefehl}{Restbefehl}: Der Spezifikator wird, wie bei \ExecuteDoHook erklärt, in den ersten String und den Rest-Spezifikator aufgeteilt. Der Kopfbefehl wird als der erste String und der Restbefehl als der Rest definiert.
      Beispiel: \SplitDoHook{heading/preinit/section}{\Kopf}{\Rest} führt zu \def\Kopf{heading}\def\Rest{preinit/section}.
    Hinweis: Die KOMA-Script-Klassen verfügen tatsächlich über die im Beispiel genannten Hooks.
    Hinweis: Dieser Mechanismus wurde aufgrund der steigenden Nachfrage nach Hooks beispielsweise durch die biblatex-Autoren ab KOMA-Script 3.27.3068 eingeführt. Ab KOMA-Script 3.27.3072 steht er mit allen genannten Anweisungen zur Verfügung. Bestehende Hooks von KOMA-Script werden nach und nach zumindest teilweise auf den neuen Mechanismus umgestellt.
scrjura:
Das Paket verwendet nun (endlich) \DeclareTOCStyleEntry für die Definition der Inhaltsverzeichniseinträge.
Hinweis: Wer bisher den undokumentierten Zähler statt der dokumentierten Option zur Festlegung der Eintragsebene verwendet hat, wird mit einer Fehlermeldung bestraft und muss dann eben zur Option wechseln. Das ist kein Bug, sondern so gewollt.
Die Änderung war in der TODO-Datei lange angekündigt und ist ab KOMA-Script 3.27.3103 endlich verfügbar. Damit steht der Weg frei, um \bprot@dottedtocline endlich als veraltet zu kennzeichnen, was in TODO ebenfalls lange angekündigt ist.
scrlayer-notecolumn:
  • Die \catcode-Werte der in \dospecials abgelegten Zeichen werden vor dem Einlesen der Hilfsdatei mit den Notizspalten wieder auf die Werte eingestellt, die sie bei \begin{document} hatten. Ausnahme ist der \catcode von @, der auf 11 (letter) gestellt wird. Dadurch funktionieren Notizspalten nun beispielsweise auch, wenn während einer verbatim-Umgebung ein Seitenumbruch erfolgt. und neue Notizen aus der Hilfsdatei gelesen werden müssen.
    Diese Änderung für ein von Karl gemeldetes Problem ist ab scrlayer-notecolumn 0.3 aus KOMA-Script 3.27.3108 verfügbar.
  • Bei Verwendung von LuaLaTeX oder PDFLaTeX unterstützt das Paket nun auch Farbänderungen mit color oder xcolor innerhalb der Notizspalten. Diese Möglichkeit ist noch sehr experimentell. Bei Verwendung von XeLaTeX werden Farben in Notizspalten weiterhin nicht unterstützt, da dann keine Möglichkeit besteht, den aktuellen color stack umzuschalten.
    Diese Änderung, die auf allerlei Anfragen zurück geht, ist ab scrlayer-notecolumn v0.2.3085 aus KOMA-Script 3.27.3085 verfügbar.
scrlayer-scrpage:
Kombinationen von scrlayer-scrpage mit Paketen, die \centering, \raggedright oder \raggedleft umdefinieren führen immer wieder zu Problemen. Krassestes Beispiel ist tabu. Aber auch auch ragged2e mit Verwendung von dessen Option newcommands oder NewCommands kann bereits dazu führen, dass die Ausrichtung nicht vollkommen korrekt ist. Obwohl das in meinen Augen eindeutig kein Bug von scrlayer-scrpage ist, sondern ein Misfeature der entsprechenden anderen Pakete, verwendet scrlayer-scrpage ab KOMA-Script 3.27.3140 die genannten Anweisungen nicht mehr direkt, sondern nutzt stattdessen \LaTeXcentering, \LaTeXraggedright und \LaTeXraggedleft. Sind diese Anweisungen beim Laden von scrlayer-scrpage bereits (beispielsweise von ragged2e) definiert, so bleiben sie unverändert. Anderenfalls werden sie mit der aktuellen Definition von \centering, \raggedright und \raggedleft versehen. Damit gibt es in scrlayer-scrpage nun auch einen Workaround für das auf TeX.Stackexchange gemeldete Problem bei mehrzeiligen Kopf-/Fußzeilen während eine longtabu verarbeitet wird.
scrletter:
Der Briefbogen wird nicht mehr von \opening erzeugt, sondern über den Layer notepaper und foldmarks und dem darauf basierenden, von der letter-Umgebung gesetzten Seitenstil notepaper.
Dies ist erst teilweise implementiert und derzeit wird \opening noch benötigt (u. a. um die richtige vertikale Position für den Briefanfang automatisch zu finden). Ein Teil der Arbeit wird eventuelle auch noch in die Definition der letter-Umgebung verlagert.
scrletter, scrlttr2:
  • Option symbolicnames kennt die neuen Werte marvosym, fontawesome und awesome. Der Wert marvosym entspricht den bisherigen Werten true, on und yes. Die beiden Werte fontawesome und awesome verwenden dagegen das Pakte fontawesome für die Symbole.
    Dieses Neuerung ist ab KOMA-Script 3.27.3120 verfügbar,
  • Der neue Befehl \foreachkomavar{Variable,}{Code} führt Code{Variable} für jede Variable aus.
    Diese Anweisung ist ab KOMA-Script 3.27.3116 verfügbar.
  • Der neue Befehl \foreachkomavarifempty{Variable,}{True-Code}{False-Code} führt True-Code{Variable} für jede Variable aus, die leer ist, und False-Code{Variable} für jede Variable, die nicht leer ist.
    Diese Anweisung ist ab KOMA-Script 3.27.3116 verfügbar.
  • Der neue Befehl \foreachemptykomavar{Variable,}{Code} führt Code{Variable} für jede Variable aus, die leer ist.
    Diese Anweisung ist ab KOMA-Script 3.27.3116 verfügbar.
  • Der neue Befehl \foreachnonemptykomavar{Variable,}{Code} führt Code{Variable} für jede Variable aus, die nicht leer ist.
    Diese Anweisung ist ab KOMA-Script 3.27.3116 verfügbar.
  • Ab KOMA-Script 3.27.3111 werden Briefe generell \raggedbottom gesetzt. Eine Änderung ist nur noch mit \flushbottom innerhalb von \begin{letter}\end{letter} bzw. über \AtBeginLetter{\flushbottom} möglich.
  • Zwar erlaubt scrlttr2 das Setzen von Option twocolumn, innerhalb der Briefumgebung führt dies jedoch nicht zu sinnvollen Ergebnissen.
    Ab KOMA-Script 3.27.3110 werden Briefe explizit einspaltig gesetzt. In einer Warnung wird ggf. darauf hingewiesen, wie man dennoch zweispaltige Briefe erreichen kann.
Comments for " Geplante Änderungen in zukünftigen KOMA-Script-Versionen" abonnieren