Hallo liebe KOMA-Community,
ich bin gerade dabei, auf Basis der KOMA-Klassen eigene Klassen für eine Vorlage zu entwerfen. Bei folgendem Problem benötige ich Hilfe bzw. einen Hinweis. Ich möchte gerne einen Schlüssel, der im KOMA-Script bereits definiert ist, um weitere Werte ergänzen.
Im Speziellen möchte ich für den Schlüssel abstract
(welcher ja mit \FamilyBoolKey
definiert wird) neben den möglichen Werten on
und off
einen dritten Wert new
zuweisen können. Gibt es eine Möglichkeit, die Definition des Schlüssels abstract
mit \FamilyNumericalKey
zu überschreiben?
Vielen Dank für eure Hilfe
Falk
Ja, aber
Das sollte theoretisch möglich sein oder bekommst Du beim Versuch eine Fehlermeldung?
Ratsam ist es aber nicht. Die Familie
KOMA
ist ausdrücklich mir vorbehalten. Da sollte man keine Schlüssel hinzufügen oder umdefinieren. Stattdessen solltest Du in Deiner Klasse eine eigene Familie mit eigenen Mitgliedern definieren. Für diese kannst Du dann selbst auch einen Schlüsselabstract
definieren, der wiederum ggf. Optionen für KOMA-Script setzt.Also,
ich habe genau das versucht. Leider wird mir nicht ganz klar, wie ich genau die Standardeinstellung überschreiben soll. Mein erster Versuch sieht folgendermaßen aus:
Solange ich für
abstract
boolesche Werte verwende, funktioniert alles wie gewollt. Sobald ich jedoch die Optionabstract=new
setze, erhalte ich die Fehlermeldung:Package scrbase Error: option `abstract' of family `KOMA' has no value `@abstrt'.
Hat jemand einen Vorschlag für mich, wie ich das ganze anpacken könnte? Vielen dank für die Hilfe.
Grüße
Falk
Hm
OK, bzw. nicht OK, die Fehlermeldung ist an der Stelle ein Missstand. Ich brauche allerdings ein wenig Zeit, um darüber nachzudenken und eine Lösung anzubieten, bzw. scrbase zu ändern. Auf die Schnelle – das wäre also eine Notlösung – könnte man natürlich scrreprt mit
\LoadClass
statt\LoadClassWithOptions
laden und dann entweder alle relevanten Optionen per\KOMAoptions
setzen, aber das wäre tatsächlich sehr umständlich und nicht im Sinne des Erfinders …Dessen ungeachtet solltest Du beachten, dass Dinge wie die
\ifcase-
Geschichte so nicht gemacht werden sollten. Eines der Features von Optionen dieser Art ist, dass man sie auch noch später setzen kann. Also sollten alle Teile so implementiert werden, dass die notwendige Fallunterscheidung nicht zur Ladezeit des Pakets respektive der Klasse gemacht wird, sondern zur Laufzeit. In diesem einfachen Demo-Fall, der sicher nicht der Realität entspricht, sollte die Definition von\foo
also innerhalb der Definition der Option erfolgen.Änderung
Ich habe das Problem jetzt noch einmal analysiert und vor allem noch einmal genau analysiert wie sich LaTeX selbst hier bei normalen Optionen verhält. Das hat dazu geführt, dass ich die Implementierung so geändert habe, dass künftig in obigem Fall scrreprt keinen Fehler mehr meldet, sondern nur eine Info in die Log-Datei schreibt.
Würde man dann beispielsweise
abstract=old
zusätzlich als Option bei\documentclass
angeben, würde auch nur eine unused global option gemeldet.Allerdings ist das ganze in LaTeX selbst wenig einheitlich implementiert. Während das Beispiel:
völlig korrekt und logisch weder Fehler noch Warnungen produziert, wird bei
und auch bei
der Fehler
gemeldet.
Das bedeutet, dass konsequenter Weise für ein Paket, das ein anderes Paket lädt, um es um Optionen zu erweitern,
\RequirePackageWithOptions
nicht verwendet werden kann. Das gilt dann natürlich auch bei Verwendung von\FamilyProcessOptions
statt\ProcessOptions
.Dankeschön
Es funktioniert mittlerweile wie gewünscht.