KOMA-Script Documentation Project

ACHTUNG: Im folgenden wird ein BETA-Feature dokumentiert! Vor der Verwendung dieses Features wird ausdrücklich gewarnt!

Bereits seid Version 2.95 BETA unterstützen alle KOMA-Script-Klassen die Anweisung \KOMAoptions zum nachträglichen Setzen von Optionen. Allerdings sind bei den Klassen scrbook, scrreprt und scrartcl noch nicht alle Optionen so umgestellt, dass sie auf diese Weise funktionieren. Einige Optionen werden auch nie umgestellt werden, sondern stattdessen durch andere Optionen bzw. Werte zu anderen Optionen ersetzt. Die alten Optionen werden dann als obsolet deklariert. Bei den drei genannten Klassen ist außerdem noch nicht für alle Optionen, die bereits per \KOMAoptions angesprochen werden können, sichergestellt, dass dies auch noch nach \documentclass funktioniert. Es ist auch nicht dafür gesorgt, dass bei Optionen, auf die das nicht zutrifft, bzw. die nicht innerhalb des Dokuments geändert werden können, ggf. eine sinnvolle Fehlermeldung bei missbräuchlicher Verwendung ausgegeben wird.

Leider weißt KOMA-Script bei obsoleten Optionen, für die bereits ein Ersatz implementiert wurde, in der Log-Datei des Dokuments bereits darauf hin, dass statt der obsoleten Option \KOMAoptions mit einem bestimmten Argument verwendet wird. In einigen Versionen rät es dazu, dies ebenfalls zu tun. Ab Version 2.97c wird korrekterweise stattdessen empfohlen, nur die neue Syntax zu verwenden. Es sollte also statt \documentclass[14pt]{scrartcl} besser \documentclass[fontsize=14pt]{scrartcl} verwendet werden. Die alte Syntax funktioniert jedoch aus Gründen der Kompatibilität weiterhin. Bei einigen Optionen funktioniert die alte Syntax nur noch bedingt. Das betrifft in der Regel nur KOMA-Script-spezifische Optionen, nicht jedoch Optionen, die von den Standardklassen übernommen wurden.

Früher war es bei KOMA-Script so, dass Optionen in der Reihenfolge ausgeführt wurden, in der sie implementiert sind. So war \documentclass[headexclude,headsepline]{scrartcl} beispielsweise identisch mit \documentclass[headsepline,headexclude]{scrartcl}. Da die Option headsepline ihrerseits die Option headinclude aufrief, war mancher Anwender überrascht, dass im ersten Fall trotzdem mit headexclude gearbeitet wurde. Wie sich das dann mit headinclude und headnosepline verhielt, mag jeder selbst ausprobieren. Absolut undurchschaubar wurde das Ganze, sobald Optionen wie DIV, <em>NN</em>pt, BCOR, <em>NN</em>paper ins Spiel kamen. Diese wurden nämlich stattdessen in der Reihenfolge ihrer Verwendung ausgeführt. Allerdings waren einige Papiergrößenoptionen sowie DIVcalc und DIVclassic in typearea wiederum so deklariert, dass sie stattdessen in der Reihenfolge ihrer Deklaration ausgeführt wurden. Für Klassen- und Paketautoren war damit die absolute Konfusion perfekt.

Seit KOMA-Script 2.95a hat sich diesbezüglich einiges geändert. Hier wurden zuerst obsolete Optionen ausgeführt. Danach wurden die Optionen der neuen Syntax in der Reihenfolge ihrer Verwendung ausgeführt. Dabei wurden einige Optionen eventuell auch mehrfach ausgeführt. Auch diese Lösung brachte deshalb nur wenig Durchblick.

In Version 2.97 wurde deshalb die gesamte Optionenangabe und -ausführung neu implementiert. Ziel dabei war, dass alle Optionen in der Reihenfolge ihrer Angabe ausgeführt werden und auch die Klassen keine Optionen mehr explizit an die KOMA-Script-Pakete weiterleiten müssen. So wertet nun beispielsweise das Paket typearea die Angabe DIV=10 selbst aus, statt dass die Option von der Klasse an das Paket gemeldet wird. Das funktioniert auch dann noch, wenn keine KOMA-Script-Klasse verwendet wird. Dieser Umstand führt aber auch dazu, dass beispielsweise bei der Angabe fontsize=10pt,DIV=10,titlepage die Option titlepage vor der Option DIV=10 ausgewertet wird, weil titlepage bereits von der Klasse, DIV=10 aber erst vom Paket typearea verarbeitet wird. Wenn der Anwender aber weiß, welche Optionen von der Klasse und welche von den Paketen verarbeitet werden, dann sollte das kein Problem darstellen.

Diese Änderung führt jedoch zu gewissen Inkompatibilitäten, da nun \documentclass[headinclude=false,headsepline]{scrartcl} dazu führt, dass diese beiden Optionen auch in dieser Reihenfolge ausgeführt werden. Das Ergebnis ist damit ein anderes als bei \documentclass[headsepline,headinclude=false]{scrartcl}.

Folgende Optionen sind obsolet, sollten aber dennoch unbesorgt verwendet werden können:

• final
• 10pt
• 11pt
• 12pt
• notitlepage
• oneside
• onecolumn
• a4paper
• a5paper
• b5paper
• letterpaper
• legalpaper
• executivepaper
• landscape
• portrait

Wird jedoch ein hier nicht angegebenes Papierformat verwendet, so sollte auch die Orientierung in neuer Syntax angegeben werden. Umgekehrt sollte die Orientierung nur dann in neuer Syntax angegeben werden, wenn auch das Papierformat in neuer Syntax angegeben wird. Die Papieroptionen werden dabei erst beim Laden von typearea ausgeführt, während die Schriftgrößenoptionen bereits von der Klasse ausgewertet werden (siehe oben).

Folgende Optionen sind obsolet und sollten stattdessen besser in der neuen Syntax, die hier in Klammern angegeben ist, gesetzt werden:

• headexlude (headinclude=false)
• footexclude (footexclude=false)
• mpexclude (mpinclude=false)
• BCOR<em>Wert</em> (BCOR=<em>Wert</em>)
• DIV<em>Wert</em> (DIV=<em>Wert</em>)
• <em>NN</em>paper (paper=<em>NN</em>) für alle oben nicht explizit genannten Papiergrößenoptionen
• <code>dvips (pagesize=dvips)
• pdftex (pagesize=pdftex)
• <em>NN</em>pt (fontsize=<em>NN</em>pt) für alle oben nicht explizit genannten Schriftgrößenoptionen
• parskip- (parskip=full-)
• parskip+ (parskip=full+)
• parskip* (parskip=full*)
• halfparskip (parskip=half)
• halfparskip- (parskip=half-)
• halfparskip+ (parskip=half+)
• halfparskip* (parskip=half*)
• parindent (parskip=false)
• nochapterprefix (chapterprefix=false)
• noappendixprefix (appendixprefix=false)
• headnosepline (headsepline=false)
• footnosepline (footsepline=false)
• cleardoubleempty (cleardoublepage=empty)
• cleardoubleplain (cleardoublepage=plain)
• cleardoublestandard (cleardoublepage=current)

Für alle obsolete Optionen gilt, dass in der log-Datei angegeben wird, wie sie intern von KOMA-Script ersetzt werden und wie die neue Syntax in der Optionenliste lautet. Bei Problemen mit Optionen kann die Lösung sein, dem Rat von KOMA-Script zur Ersetzung zu folgen.

Folgende Optionen sind noch nicht auf die neue Syntax umgestellt: leqno, fleqn, openright, openany, pointednumbers, pointlessnumbers, bigheadings, normalheadings, smallheadings, tablecaptionabove, tablecaptionbelow, origlongtable, onelinecaption, noonelinecaption, tocleft, tocindent, liststotoc, liststotocnumbered, listsleft, listsindent, openbib, bibtotoc, bibtotocnumbered, idxtotoc.

Alle anderen Optionen sind bereits auf die neue Syntax umgestellt, wobei die Verwendung ohne Angabe eines Wertes der früheren Bedeutung entspricht. Einige Optionen haben zusätzlich neue Werte.

Wie gesagt wurde bei Version 2.97c die gesamte Optionenschnittstelle von KOMA-Script (zu finden in scrkbase) komplett überarbeitet. Ziel dabei war, dass alle Optionen in der Reihenfolge ausgeführt werden, in der sie verwendet sind. Dabei werden zuerst globale Optionen, dann lokale Paket-Optionen ausgeführt. Außerdem werden beim Laden von Klassen und Paketen nur noch die Optionen ausgeführt, die keiner Klasse und keinem Paket oder der jeweiligen Klasse bzw. dem jeweiligen Paket gehören. Als Info für Klassen- und Paketautoren, die sich auf undokumentierte Innereien von KOMA-Script verlassen, sei in diesem Zusammenhang auch erwähnt, dass es neben der keyval-Familie KOMA nun weitere Familien gibt. \KOMAoptions führt weiterhin alle Optionen aus. Sollten Pakete oder Klassen gleichnamige Optionen definieren, werden diese in der Reihenfolge ihrer Definition ausgeführt. Außerdem sind einige BETA-Anweisungen aus scrkbase wieder verschwunden.

Bei der Implementierung der neuen Optionenschnittstelle hat sich dann gezeigt, dass die strikte Regel bezüglich der Reihenfolge nicht mehr funktionieren kann, sobald eine Klasse oder ein Paket Optionen an andere Klassen oder Pakete schickt. Sobald dies innerhalb der Ausführung von Optionen geschieht, gibt es diverse Probleme. Die meisten davon konnten mit etwas Hirnschmalz gelöst werden. Was mit vertretbarem Aufwand nicht gelöst werden kann, ist das Problem, der Reihenfolge, verschachtelter Optionenaufrufe. Bestes Beispiel ist wieder headsepline=true,headinclude=false als globale Optionen. Wenn die Klasse dann in der Ausführung von headsepline die Option headinclude=true an das typearea-Paket schickt, dann wird headinclude=true an die lokalen Optionen von typearea angehängt. Aber natürlich werden von typearea erst die globalen Optionen ausgeführt. Es wird also headinclude=false vor headinclude=true ausgeführt. Dass das nicht im Sinne des Anwenders ist, ist klar. Das konkrete Problem konnte einfach gelöst werden. Wenn aber dann auch noch scrpage2 ebenfalls ein headinclude=true an typearea schickt, dann garantiere ich für nichts mehr. Das Problem werde ich mir anschauen, sobald ich scrpage2 auf keyval-Optionen umstelle.