Mit folgender Gebrauchtware kann man die Entwicklung von KOMA-Script derzeit unterstützen:
2,5" SATA Festplatte ab 300 GB
eBook-Reader, der das epub-Format versteht
Acrobat Pro (wegen Inspector für PDF/X und PDF/A)
Wer sonst noch etwas hat, das nur ungenutzt in einer Kiste liegt, kann gerne nachfragen, ob ich es brauchen kann.
Beispiele aus der 3. Auflage des KOMA-Script-Buchs
Dieses ZIP-Archiv enthält Beispiele aus den Kapiteln 4 und 12 und den Anhängen B, C, D, E und F von:
Markus Kohm, Jens-Uwe Morawski:
KOMA-Script
Eine Samlung von Klassen und Paketen für LaTeX2e
3., überarbeitete und erweiterte Auflage für KOMA-Script 3; September 2008;
Edition dante by Lehmanns Media;
560 Seiten; Ladenpreis: 19,95 €; ISBN-13: 9783865412911
Ohne das Buch sind die Beispiele uninteressant, da in dem Archiv keinerlei weitere Erklärungen enthalten sind. Mitglieder von DANTE e.V. können das Buch auch über den Verein beziehen.
Es geht hier nicht um konkrete Beispiele neuer Features, sondern um eine generelle Frage. Wobei es ausdrücklich nicht um Bugs, sondern um neue Möglichkeiten geht, die in Widerspruch zu alten stehen. Eins kann als sicher angenommen werden. Ich werde die Entscheidung nicht bei jedem Feature neu treffen, denn wer soll noch den Überblick behalten, wenn mal so mal so entschieden wird.
Letztlich ist die Frage: Ist es eher zuzumuten, dass man in fünf Jahren herausfinden muss, dass ein altes Dokument ggf. mit geänderten Optionen zu setzen ist oder dass man bei neuen Dokumenten einen Rattenschwanz an Optionen angibt, um KOMA-Script ausreizen zu können. Wobei das schon wieder eine andere Designentscheidung beinhaltet, die gar nicht zur Abstimmung stellen wollte. es kann genauso gut sein, dass es nur um eine einzige Option geht, die alles entscheidet.
Zugunsten neuer Möglichkeiten favorisiere ich die Verwendung aktueller Optionen für neue Dokumente. Für ältere reicht mir - analog der Verwendung von KOMAold.lco - eine Kompatibilitätseinstellung in der Form "\setkomamode=2.9".
Für den (hoffentlich anzunehmenden) Fall einer kontinuierlichen Weiterentwicklung von KOMA-Script wird der angesprochene "Rattenschwanz an Optionen" ansonsten zum Beginn einer unendlichen Optionskette, die irgendwann doch aufgebrochen werden muss oder nicht mehr händelbar ist.
Mir wäre es lieber, wenn alte Dokumente sich auch zukünftig ohne Anpassungen problemfrei kompilieren lassen.
Auch sehe ich nicht, wie sich eine "unendliche Optionskette" entwickeln soll. Derartig viele Mankos sehe ich im KOMA-Paket nicht -- wenn ich ehrlich sein soll vermisse ich nur einen Schalter nexthead==firsthead für scrlttr2 ;)
Dem Vorschlag einer Kompatibilitätseinstellung schließe ich mich an. Jeder der KOMA-Script nutzen will, sollte nicht erst etwas aktivieren müssen um UpToDate zu sein. Auf der anderen Seite ist der Wunsch nach einem Code verständlich, der in 10 Jahren noch das gleiche Ergebnis liefert. Wer soll den Überblick darüber behalten, was bis dahin alles geändert wurde. Diesen Wünschen könnte man nachkommen indem man als optionale Angabe im Dokument die KOMA-Version angiebt. Wird sie nicht gegeben, so gilt die aktuelle Einstellung.
Ab Version 3.01a wird die Voreinstellung von KOMA-Script auf version=last geändert. Dafür wird bei Verwendung einer der alten Optionen von KOMA-Script 2, die seit KOMA-Script 3 als obsolet deklariert sind, automatisch auf version=first umgeschaltet und eine entsprechende Warnung ausgegeben, die auch erklärt, wie man diese automatische Umschaltung verhindern kann.
Bewogen hat mich dazu, dass viele Anwender einfach dadurch von Verbesserungen in KOMA-Script ausgeschlossen waren, dass sie in der Anleitung nie bis zur Beschreibung der Option version vorgedrungen sind. Die Aufklärung dazu ist weit schwieriger als bei Beschwerden zu Umbruchänderungen darauf hinzuweisen, dass Option version mit passendem Wert (im Zweifelsfall first) als letztes bei \documentclass angegeben werden sollte.
Aktuelle KOMA-Script Release
Die aktuelle KOMA-Script-Release oder Release-Candidates, die als hinreichend stabil betrachtet werden, finden sich primär im Dateien-Bereich des Projekts koma-script3 auf BerliOS. Im ftp-Bereich gibt es ggf. Beta-Versionen oder Release-Candidates mit Beta-Status.
Kommentare
Neue Möglichkeiten bei Koma-Script
Entschuldigung,
aber in dieser Abstraktion ist das doch kaum zu entscheiden. Könnte man nicht wenigsten zwei Beispiele nennen, an welche Features gedacht ist?
Beispiel: Die Kopfzeile soll von jetzt an immer farbig sein. Da wäre ich sehr stark dafür, dass ich derartiges bewußt anschalten muss.
Gruß,
Alexander
Entweder oder
Es geht hier nicht um konkrete Beispiele neuer Features, sondern um eine generelle Frage. Wobei es ausdrücklich nicht um Bugs, sondern um neue Möglichkeiten geht, die in Widerspruch zu alten stehen. Eins kann als sicher angenommen werden. Ich werde die Entscheidung nicht bei jedem Feature neu treffen, denn wer soll noch den Überblick behalten, wenn mal so mal so entschieden wird.
Letztlich ist die Frage: Ist es eher zuzumuten, dass man in fünf Jahren herausfinden muss, dass ein altes Dokument ggf. mit geänderten Optionen zu setzen ist oder dass man bei neuen Dokumenten einen Rattenschwanz an Optionen angibt, um KOMA-Script ausreizen zu können. Wobei das schon wieder eine andere Designentscheidung beinhaltet, die gar nicht zur Abstimmung stellen wollte. es kann genauso gut sein, dass es nur um eine einzige Option geht, die alles entscheidet.
Konsequentes "entweder"
Zugunsten neuer Möglichkeiten favorisiere ich die Verwendung aktueller Optionen für neue Dokumente. Für ältere reicht mir - analog der Verwendung von KOMAold.lco - eine Kompatibilitätseinstellung in der Form "\setkomamode=2.9".
Für den (hoffentlich anzunehmenden) Fall einer kontinuierlichen Weiterentwicklung von KOMA-Script wird der angesprochene "Rattenschwanz an Optionen" ansonsten zum Beginn einer unendlichen Optionskette, die irgendwann doch aufgebrochen werden muss oder nicht mehr händelbar ist.
lieber kompatibel
Mir wäre es lieber, wenn alte Dokumente sich auch zukünftig ohne Anpassungen problemfrei kompilieren lassen.
Auch sehe ich nicht, wie sich eine "unendliche Optionskette" entwickeln soll. Derartig viele Mankos sehe ich im KOMA-Paket nicht -- wenn ich ehrlich sein soll vermisse ich nur einen Schalter nexthead==firsthead für scrlttr2 ;)
Konsequentes "entweder" klingt gut.
Dem Vorschlag einer Kompatibilitätseinstellung schließe ich mich an. Jeder der KOMA-Script nutzen will, sollte nicht erst etwas aktivieren müssen um UpToDate zu sein. Auf der anderen Seite ist der Wunsch nach einem Code verständlich, der in 10 Jahren noch das gleiche Ergebnis liefert. Wer soll den Überblick darüber behalten, was bis dahin alles geändert wurde. Diesen Wünschen könnte man nachkommen indem man als optionale Angabe im Dokument die KOMA-Version angiebt. Wird sie nicht gegeben, so gilt die aktuelle Einstellung.
Die Sache ist entschieden
Ab Version 3.01a wird die Voreinstellung von KOMA-Script auf
version=lastgeändert. Dafür wird bei Verwendung einer der alten Optionen von KOMA-Script 2, die seit KOMA-Script 3 als obsolet deklariert sind, automatisch aufversion=firstumgeschaltet und eine entsprechende Warnung ausgegeben, die auch erklärt, wie man diese automatische Umschaltung verhindern kann.Bewogen hat mich dazu, dass viele Anwender einfach dadurch von Verbesserungen in KOMA-Script ausgeschlossen waren, dass sie in der Anleitung nie bis zur Beschreibung der Option
versionvorgedrungen sind. Die Aufklärung dazu ist weit schwieriger als bei Beschwerden zu Umbruchänderungen darauf hinzuweisen, dass Optionversionmit passendem Wert (im Zweifelsfallfirst) als letztes bei\documentclassangegeben werden sollte.