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.

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.

scrartcl, scrbook, scrreprt:
  • 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. Die 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:
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.
scrlayer-notecolumn:
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 aber scrlayer-notecolumn v0.2.3085 aus KOMA-Script 3.27.3085 verfügbar.
Comments for " Geplante Änderungen in zukünftigen KOMA-Script-Versionen" abonnieren