Hauptmenü
Sie sind hier
Globale Optionen
Hi,
ich habe schon des öfteren Angaben von globalen Optionen gesehen, wie z.B.
\documentclass[ngerman]{scrartcl} \usepackage{babel} \begin{document} foobar \end{document}
Jetzt bin ich mal neugierig gewesen: Ein Aufruf von less `kpsewhere scrartcl.cls` und eine eine kurze Suche nach \PassOptions hat mir keinen Hinweis darauf geliefert, dass das obige Beispiel auch wirklich die Option an das babel Paket weiterreicht.
Irre ich mich, wenn ich behaupte, dass das bei mir bisher keine Probleme bereitet hat (Trennmuster sind auf jedenfall immer korrekt geladen worden, Titel waren auch alle auf deutsch) oder bin ich nur zu unerfahren und suche in falschen Datein nach einem Hinweis?
Gruß
Henning
Aktuelle KOMA-Script Release
Die aktuelle KOMA-Script-Release finden sich primär im Dateien-Bereich des Projekts KOMA-Script auf SourceForge.
Schnelle Bugfixes und Prereleases finden sich im KOMA-Script-Repository.
Näheres zur aktuellen und früheren Releases ist dem Beitrag »Welches ist die aktuelle KOMA-Script-Release und wo finde ich sie?« zu entnehmen.
Beispiele aus der 7. Auflage des KOMA-Script-Buchs
Hingucker
Sponsoren
In der Reihenfolge der Spendeneingänge:
2024
Paul Kloß u. a.
2023
Paul Kloß, Manuel Kuehner, Martin Bierbaum, Ulrich Groh, Elke Schubert u. a.
Näheres zu Kosten und Betrieb ist in einem Blog-Beitrag zu finden. Natürlich sind auch Spenden ohne Namensnennung möglich.
Newsfeeds
Die Bedeutung des optionalen Arguments von \documentclass
Entgegen der landläufigen Meinung übergibt man mit dem optionalen Argument von
\documentclassnicht etwa Klassenoptionen an die Klasse, sondern setzt globale Optionen. Alle Pakete, die entsprechende Optionen deklariert haben, erhalten diese Optionen direkt vom LaTeX-Kern. Dies ist insbesondere ein gravierender Unterschied zu\PassOptionsToClassoder\LoadClass. Die mit diesen beiden Anweisungen angegebenen Optionen werden tatsächlich nur an die entsprechende Klasse weitergereicht.Einen wichtigen Unterschied gibt es bezüglich der Optionen, die in Klassen oder Paketen per
\DeclareOption*– man beachten den Stern! – verarbeitet werden. Während die per\documentclassgeladene Klasse hier alle nicht per\DeclareOption– man beachten den fehlenden Stern! – deklarierten Optionen aus dem optionalen Argument von\documentclasserhält, gilt dies für Pakete nicht!Es ist also gar nicht notwendig, dass scrartcl Optionen an Pakete weiterreicht. Dies macht LaTeX bereits selbst. Notwendig war dies einst für Optionen wie
a6paperoderBCOR2cm. Diese Optionen wurden nämlich per\DeclareOption*verarbeitet, da es schlicht nicht möglich ist, für alle möglichen Werte entsprechende Optionen in typearea per\DeclareOptionzu deklarieren. Seit der Umstellung der Optionenverarbeitung auf einekey=value-Syntax ist dieses Problem Vergangenheit, da hierfür eine eigene Optionenverarbeitung implementiert wurde. Diese ist jedoch nicht in scrartcl, sondern in scrkbase – das sich wiederum auf scrbase stützt – enthalten. Das dafür gundlegende Paket scrbase ist dokumentiert, so dass auch andere Paketautoren die Möglichkeit haben, sich auf den Mechanismus zu stützen. Gleichzeitig versteht typearea dadurch nun auch ein global angegebenesBCOR=2cm, wenn typearea gar nicht mit einer KOMA-Script-Klasse, sondern beispielsweise mit einer Standardklasse verwendet wird.Weihnachtsaktion: Wenn diese Antwort Dich weitergebracht hat, bitte ich darum, der Sternsingeraktion min. 1,–€ zu spenden. Es sind dort auch Online-Spenden möglich.
Danke
für die ausführliche Erklärung.
Ist es eigentlich ein »Soll« (wenn man das innerhalb OSS überhaupt verlagen kann), bei zukünftigen Entwicklungen KVP Syntax zu verwenden?
--
Henning Bredel
KV-Syntax
Es gibt dazu meines Wissens keine allgemeingültige Aussage von irgendwem. Einige Entwickler bevorzugen KV-Syntax andere bevorzugen klassische Optionen. Vorteilhaft ist KV-Syntax zweifellos dann, wenn man Optionen auch noch nach dem Laden des Pakets oder der Klasse ändern können soll. Vorteilhaft ist es auch, wenn man eine nicht überschaubare Menge an klassischen Optionen durch eine überschaubare Anzahl an Optionen mit einer möglicherweise unüberschaubaren Anzahl an Werten ersetzen kann. So müsste man beispielsweise, um alle A-, B-, C- und D-Formate zu unterstützen, ohne KV-Syntax bis zu 40 Optionen definieren. BCOR allein mit klassischen Optionen geht gar nicht, weil man von 1sp bis 2Mio sp alles mit diversen Einheiten angeben müsste. Beide Optionen waren deshalb in typearea schon immer mit einer Pattern-Match-Methode implementiert. KV ist im Prinzip nichts anderes, nur dass die Syntax dabei wohldefiniert ist.
Hat man andererseits ein Paket, das nur zwei Optionen kennt, die unbedingt bereits beim Laden angegeben werden müssen, dann ist es nicht unbedingt sinnvoll, diese per KV zu implementieren – außer eventuell, wenn es gegensätzliche Optionen sind, also ein und aus. In dem Fall kann man durchaus die Auffassung vertreten, dass man eigentlich eine einzige Eigenschaft ein- und ausschaltet und deshalb auch eine einzige Option mit zwei Zuständen dafür verantwortlich sein sollte. Bevor man also fooon und foooff definiert, sollte man sich überlegen, ob man damit nicht bereits auf dem Weg zu einem KV-System ist und dann eine kanonische Lösung vorzuziehen wäre.
Das alles ist aber nur eine Meinung. Ich will bestimmt niemandem vorschreiben, wie er das bei seinen Paketen machen soll. Ich halte es auch durchaus für ratsam, wenn ein Jungautor erst einmal versucht, mit den normalen Problemen beim Paketschreiben klar zu kommen.
Bei KOMA-Script war der Schwenk zu einer einheitlichen KV-Lösung letztlich die Lösung verschiedener Implementierungsprobleme. Wobei ich nicht verschweigen will, dass ich die KV-Lösung insgesamt dreimal komplett umgebaut habe, bis ich bei einem Ergebnis war, das bisher alle Anforderungen erfüllt. KOMA-Script ist nunmal ein wenig komplex.