LaTeX Forum

Guten Abend,

ich verwende in einem eigenen Paket einige Funktionen, die nur in KOMA-Skript zur Verfügung stehen. Damit mein Paket auch mit anderen Klassen kompatibel ist, lade ich scrextend. Das Problem dabei ist nun, dass scrextend eine Warnung sendet, wenn es zusammen mit einer KOMA-Klasse geladen wird.

Kann ich irgendwie feststellen, ob KOMA-Skript vorhanden ist?
Den Befehl \KOMAClassName habe ich schon gefunden und überlegt, dann mit zu arbeiten, ich bin aber nicht sicher, ob das in jedem Falle zum Ziel führt und würde gerne eine Paketoption anbieten, die dem Anwender ermöglicht, notfalls einzugreifen und zu bestimmen, dass das Paket geladen werden muss oder eben nicht.
Ich denke da an Fälle, in denen eine eigene Klasse verwendet wird, die intern aber eine der KOMA-Klassen lädt.
Oder ist das überflüssig und ich kann mich auf den \@ifundefined-Ansatz verlassen?

Viele Grüße
Tobi

(Edit: überflüssiges e in KOMAClasseName entfernt)

\KOMAClassName ist immer definiert, wenn eine KOMA-Script-Klasse geladen ist. Dabei spielt es keine Rolle, ob die Klasse via \documentclass vom Anwender oder über \LoadClass oder \LoadClassWithOptions von einer anderen Klasse geladen wurde. Es ist also ein eindeutiger Hinweis, dass eine KOMA-Script-Klasse vorhanden ist. Wenn Du also das »e«, das in Deinem Beispielcode zu viel ist, weg lässt, dann funktioniert das.

Alternativ könnte man auch auf \KOMAScriptVersion testen. Das bietet sich insbesondere an, wenn man Anweisungen verwendet, die erst ab einer bestimmten KOMA-Script-Version vorhanden sind. Allerdings dürfte es dann einfacher sein, nach dem Test auf KOMA-Script noch ein nachzuschieben bzw. beim Laden von scrextend die min. gewünschte Version als Option nach dem Paketnamen anzugeben (siehe die komplette Syntax von \RequirePackage im clsguide).

Je nach Anweisungen, auf die Du zurückgreifen möchtest, wird eventuell scrextend aber gar nicht benötigt. So stellen bereits scrlfile, scrbase, typearea und tocbasic einige Anweisungen für die KOMA-Script-Klassen zur Verfügung (welche ist in der den entsprechenden Kapiteln der Anleitung zu finden). Diese Pakete kann man (ohne Optionenangabe) einfach so laden. Dabei spielt es keine Rolle, wie oft sie geladen werden. Sie müssen nur alle aus der gleichen KOMA-Script-Version stammen.

Theoretisch am besten ist natürlich, wenn man auf das Vorhandensein der Befehle testet, die man benötigt. Es könnte ja durchaus sein, dass andere Klassen diese Befehle irgendwann auch zur Verfügung stellen. Wenn das natürlich sehr viele oder sehr, sehr KOMA-Script spezifische Befehle sind, dann lohnt sich der Aufwand nicht unbedingt.

Nabend KOMA,

konkret geht es – bisher – um die addmargin-Umgebung und die …captionname-Befehle.

Ich denke ein einfacher Test à (so rum oder á…?) la würde mir genügen. Das würde dann ja auf jeden Fall sicher stellen, dass mir das aus KOMA-Script benötigte zur Verfügung steht oder?
Es könnte auch sein, dass noch mehr Befehle dazu kommen...

Gute Nacht
und Danke!
Tobi

Die ganzen \...captionname-Anweisungen sind absichtlich in scrbase definiert. Dafür genügt also ein Ob die addmargin-Umgebung vorhanden ist, kann man mit testen. Wenn scrbase bereits geladen wurde (siehe oben) kann man auch verwenden. Das ist in der Regel besser, spielt aber keine Rolle, wenn danach durch Laden von scrextend im false-Teil ohnehin dafür gesorgt wird, dass es definiert wird.

Guten Morgen,

welche Lösung ist denn dann zu bevorzugen? addmargin brauche ich in jedem Fall und ich wüsste nicht, welches Paket diese Umgebung noch zur Verfügung stellt.
Wenn ich also – bei Bedarf, d.h. außerhalb einer KOMA-Klasse – eh scrextend lade, brauche ich scrbase ja nicht.

Was empfiehlst du mir?

Dass Du kein Paket kennst, ist dieselbe Begründung, mit der seinerzeit in diversen Paketen Tests auf article.cls eingebaut wurden, um zu unterscheiden, ob \chapter oder \section als oberste Gliederungsebene existiert. Das Ergebnis ist, dass all diese Pakete teilweise noch heute sehr schlecht mit KOMA-Script zusammenarbeiten.

Allerdings ist heute die Wahrscheinlichkeit, dass ein Paket addmargin definiert und dabei keine Rücksicht darauf nimmt, dass es eventuell bereits definiert sein könnte, eher gering. Also sollte es kein Problem sein, wenn Du auf \KOMAClassName testest und anderenfalls scrextend lädst, obwohl mein allgemeiner Rat normalerweise lautet: Teste auf die Makros, die Du brauchst und nicht auf die Pakete, in denen Du die Makros vermutest.

Raten werde ich Dir jedoch nicht. Entscheiden musst Du auf Basis dessen, was Du nun weißt, selbst.

Was ich Dir aber rate ist, auf \KOMAClassName nicht mit \@ifundefined zu testen. Danach wäre \KOMAClassName nämlich nicht mehr wirklich undefiniert, sondern \relax. Also besser Falls Du irgendwann Makros benötigst, die erst in neueren KOMA-Script-Versionen enthalten sind, würde ich mich aber nicht auf \KOMAClassName alleine verlassen. Dann solltest Du etwas wie machen, um die Version abzusichern. Natürlich kannst Du auch mit \ClassError oder \PackageError einen Fehler ausgeben oder \ClassWarning oder \PackageWarning für die Warnung verwenden.

Für addmargin ist ein Versionstest IMHO nicht notwendig, da es das schon lange genug gibt.