Sie sind hier

Wie soll die Option zur Zusammenarbeit mit geometry heißen?

geometry
43% (3 Stimmen)
geometryhack
0% (0 Stimmen)
geometrysupport
14% (1 Stimme)
influencegeometry
0% (0 Stimmen)
usegeometry
43% (3 Stimmen)
Gesamte Stimmenzahl: 7

Kommentare

Diese Umfrage bezieht sich auf die vermutlich in KOMA-Script 3.17 für typearea geplante Änderung. Siehe die dortige Erklärung. Die Umfrage ist natürlich nur so lange sinnvoll, bis eine KOMA-Script-Version mit dieser Option veröffentlicht ist. Wer also mitbestimmen will, sollte jetzt abstimmen. Alternativ kann man mir auch weitere Vorschläge hier als Kommentar oder per E-Mail an die KOMA-Script-Support-Adresse (siehe KOMA-Script.-Anleitung) unterbreiten.

Siehe auch die Abstimmung über die Voreinstellung der Option.

Ich finde "geometry¹" ausreichend. Als Paket ist das so ein Klassiker, dass der Name schon eine "Marke" ist. Als Option wäre es so generisch, dass man es ohnehin nicht in anderem Kontext verwenden würde. "usegeometry¹" fände ich als ausführlichere Option zwar aussagekräftiger, jedoch hätte das in meinen Augen nur Sinn, wenn es zur Unterscheidung beiträgt, also wenn es (bisher fiktive) Optionen "dontusegeometry¹", "ignoregeometry¹" oder andere gäbe.

Weiterhin könnte man verschiedene Stufen der Zusammenarbeit festlegen, einmal fabuliert:

geometry = true | false | use | donotuse | ignore | override¹

oder man bietet das gleichzeitige Laden von geometry mit Optionen, falls es statt "true" oder simpler key-Angabe mit einem Value-Set geladen wird.

Bleibt es bei dem Zweck der Kompatibilität und Harmonie, fände ich den Paketnamen als Option prägnanter. ntheorem hat auch "amsmath¹" als Option, und nicht "useamsmath¹". Weiterhin würde "usegeometry¹" für mich implizieren, dass es genutzt wird - ich würde nicht erwarten, es noch laden zu müssen.

Ein ganz anderer spontaner Gedanke wäre eine Option, in der man zusätzlichen Support für Fremdpakete anwählt, also etwa support={geometry, caption, titlesec}¹ oder mit anderem Namen wie compatibility¹ oder compat¹, wobei "support¹" konstruktiver klingt. In diesem Fall braucht man jedenfalls nur einen Optionen-Namen, falls mehrere Pakete einmal in Frage kommen.

Stefan

[Admin-Edit:]

  1. <code></code> Tags eingefügt (siehe Formatierungshinweise)

Die Option wird schon die üblichen Werte für einfache Schalter in KOMA-Script verstehen. Allerdings wird ist die Möglichkeit, eine einmal aktivierten Option zu deaktivieren in diesem Fall begrenzt. Derzeit funktioniert das ganze so, dass innerhalb von \activateareas (wird automatisch bei jeder Berechnung von Satzspiegel und Rändern in typearea ausgeführt) die Einstellungen an geometry weitergereicht werden. Schaltet man danach die Option ein- oder aus, dann wirkt sich das nicht auf zurückliegende \activateareas aus, sondern nur auf zukünftige.

Irgendwelche Optionen an geometry weiterzureichen wäre hingegen wenig sinnvoll. Das der Anwender das Paket ohnehin selbst laden muss, kann er dann auch die Optionen mit angeben. Es geht wirklich nur darum, die Kooperation zu verbessern und auch das nur für typearea-Einstellungen, die bereits aktiv wurden.

Es gab kurzzeitig mal die Überlegung, das weniger von KOMA-Script-Seite zu machen als durch Eingriffe in geometry (was KOMA-Script ja nach dem Laden eines Pakets durchaus beherrscht). Das hätte ich dann über scrhack und nicht direkt in typearea realisiert. Ich habe mich aber aus verschiedenen Gründen dagegen entschieden. Einer davon war, dass ich mich dann noch tiefer in geometry hätte hineinknien müssen und vermutlich weit mehr Interna von geometry hätte nutzen müssen. Die jetzige Lösung benötigt nur drei interne Makros von geometry. Vermutlich kann ich das sogar noch auf zwei reduzieren. Es wird auch nur eines davon schreibend verwendet. Ich hoffe, dass das einige Zeit funktionieren wird.

Comments for "Wie soll die Option zur Zusammenarbeit mit geometry heißen?" abonnieren