Oft begegnet einem das Verdikt, daß man keine Klassen oder Styles verändern soll. Warum eigentlich nicht? Es ist mittlerweile gängige Praxis, Definitionen umzudefinieren und sich nicht an die Definitionen der Klassen und Styles zu halten. Sogar neue Klassen und Styles benutzen \renewcommand oder Tipps für die Präamble benutzen \makeatletter etc, um bestehende Definitionen den eigenen Vorstellungen anzupassen.

Der einzige Grund für dieses Verdikt ist vermutlich, daß bestehende Vorlagen nicht überschrieben werden sollen, es genügte also, die veränderte Datei unter neuem Namen abzuspeichern, und fertig ist die Laube, oder gibt es noch mehr Argumente gegen eine Veränderung der Klassen und Styles?

gefragt 13 Okt '13, 01:08

ctansearch's gravatar image

ctansearch
(ausgesetzt)
Akzeptiert-Rate: 18%

bearbeitet 13 Okt '13, 22:01

Qrrbrbirlbel's gravatar image

Qrrbrbirlbel
2.9k2815

2

Vielleicht solltest Du erwähnen, dass mit „Styles“ Pakete gemeint sind. Wenn ich mich nicht irre, nannte man das bei LaTeX 2.09 noch so, da das aber seit 20 Jahren durch 2e abgelöst ist, wird dem durchschnittlichen Anwender der Begriff vermutlich nicht geläufig sein.

(13 Okt '13, 11:00) cgnieder

Habe ich von der Datei-Endung .sty abgeleitet.

(13 Okt '13, 20:49) ctansearch

@ctansearch Ich glaube, bei LaTeX 2.09 wurden die auch Styles genannt und es gab noch keine Pakete oder Klassen im heutigen Sinn. So weit ich weiß gab es nur Styles, etwa article.sty oder book.sty. (Das sage ich nur vom Hörensagen, war vor meiner LaTeX-Zeit...)

(13 Okt '13, 20:55) cgnieder
1

Ich habe das damals mitgemacht. Tatsächlich gab es bei LaTeX 2.09 nur styles, egal ob sie eine Dokumentart beschrieben (heute Klassen) oder eine Erweiterung (heute Pakete). Während man heute spätestens an der Endung erkennt, ob man etwas zusätzlich zur Klasse lädt oder als Klasse, musste man früher wissen ob man etwas zusätzlich zu einem document style als option style lädt oder als document style. Auch die Optionenschnittstelle war damals bei weitem nicht so komfortabel wie heute. Dabei ist LaTeX2e nur als kleiner Schritt Richtung LaTeX3 gedacht, wo das alles noch besser werden soll …

(14 Okt '13, 09:57) saputello

Von einem Verdikt wie Du es nennst, habe ich so noch nicht gehört. Gründe, die dagegen sprechen eine Paket- oder Klassen-Datei direkt zu verändern, fallen mir aber ein paar ein:

  • Die Lizenz erlaubt es einem unter Umständen nicht. Die Großzahl der LaTeX-Pakete und -Klassen steht unter der LaTeX Project Public License (LPPL). Sie erlaubt es explizit, ein Paket zu verändern:

    If you are not the Current Maintainer of the Work, you may modify your copy of the Work, thus creating a Derived Work based on the Work, and compile this Derived Work, thus creating a Compiled Work based on the Derived Work.

    Sie legt aber auch eine Reihe von Bedingungen fest, die einzuhalten sind, wenn man nicht der Current Maintainer ist, die im wesentlichen darauf hinauslaufen, dass man kenntlich machen muss, dass es sich um eine veränderte Version von Paket soundso ist, zusammen mit einem Changelog, was man verändert hat. Sprich: abspeichern des veränderten Pakets foo als myfoo (wobei man unter Umständen auch die Zeile \ProvidesPackage entsprechend ändern muss), zum Beispiel zusammen mit einem README, dass die veränderten Komponenten beschreibt. (Ein paar weitere Punkte werden in der LPPL noch erwähnt. Wen es genauer interessiert, kann dem oben angegebenen Link folgen.)

    So oder so sollte man sich also vorher die Lizenz der zu verändernden Datei anschauen, wenn man vorhat ein Paket oder eine Klasse zu modifizieren.

  • Die Praktikabilität: nimmt man in einer Datei direkt Veränderungen vor, ohne sie als (gekennzeichnete) modifizierte Datei im lokalen Ast des TeX-Baums zu speichern, sind beim nächsten Update die Veränderungen weg => das kann ärgerlich werden.

  • Kooperation: arbeitet man mit anderen zusammen, dann ist davon auszugehen, dass sie die offiziellen Versionen installiert haben. Hier ist dann überhaupt eine veränderte Datei, selbst wenn sie unter Einhaltung aller lizenzrechtlichen Belange erstellt wurde, unpraktischer als ein Patch in der Präambel, weil man die modifizerten Dateien mit dem Dokument zusammen weitergeben muss.

Permanenter link

beantwortet 13 Okt '13, 09:51

cgnieder's gravatar image

cgnieder
22.1k243463
Akzeptiert-Rate: 60%

bearbeitet 13 Okt '13, 11:04

Der Punkt Praktikabilität ist eigentlich der wichtigste.

Der Punkt Kooperation relativiert sich, wenn man einen Teil der Präambel in eine andere Datei verschiebt (sei es eine mehr oder weniger eigenständige Paketdatei mit der Endung .sty oder eine einfache .tex, die mit \input eingebunden wird). Arbeitet man mit anderen zusammen, wird man sicherlich eh nicht alles nur in eine Datei schreiben. — Nichtsdestoweniger muss natürlich ein mit eigenen Anpassungen überschriebenes Paket bei einer gemeinschaftlichen Arbeit mit dem eigentlichen Dokument ausgetauscht werden.

(13 Okt '13, 21:57) Qrrbrbirlbel

@Qrrbrbirbel Finde ich überhaupt nicht. Sagen wir, ich habe eine modifizierte Version von article.cls, die ich angepasst habe: die kann ich in Kooperation nicht verwenden, es sei den ich teile sie ebenfalls. Dann ist es aber sehr gut, wenn ich nicht die originale article.cls im base/-tree modifiziere, sondern eine private myarticle.cls habe, die ich dann verwenden und teilen kann. Ich kann ja schlecht von anderen erwarten, dass meine article.cls eine andere ist, als die die alle anderen verwenden.

(13 Okt '13, 22:42) cgnieder

@Qrrbrbirbel Praktikabilität mag für einen alleine der wichtigste Punkt sein, sobald es aber um LaTeX-Einsatz auf der Arbeit und oder Kooperation geht, wird m.E. Lizenz der wichtigste.

(13 Okt '13, 22:44) cgnieder

Da hätte ich eine Anregung, die praktikabel wäre. Wenn man in jede Klasse oder jeden Style(ich verwende das Wort ab jetzt für .sty- Dateien) eine Sektion \begin{modifications} \input myarticle.sty \end{modifications} o.ä. einfügen würde, die es erlaubt, Veränderungen nachträglich in die Klasse oder den Style zu laden, wäre es bequemer, Anpassungen vorzunehmen und auch bequemer, diese wieder abzuschalten.

(13 Okt '13, 23:15) ctansearch
1

@ctansearch Ich kann Dir versichern: kein Paket-Autor wird so eine Umgebung einfügen und die Basis-Pakete und Klassen bekommen bestenfalls noch einen gelegentlichen Bugfix (in fixltx2e, nicht in den eigentlichen Dateien). Eine ganze Reihe von Paketen bietet einem aber an, eine eigene *.cfg Datei zu verwenden, in die man eigene Definition das Paket betreffend packen kann: microtype, biblatex, exsheets ..., insofern ist Dein Vorschlag schon umgesetzt :)

(13 Okt '13, 23:26) cgnieder
1

@ctansearch Eine Umgebung bedeutet bei LaTeX auch eine Gruppe. Definitionen in einer Gruppe, die global gelten sollen, müssen explizit global vorgenommen werden. Damit wäre eine solche Umgebung eher unangenehm als angenehm. Ist aber auch nicht notwendig, denn es gibt ja die Wrapper-Klassen und Wrapper-Pakete. Siehe dazu meine Antwort.

(14 Okt '13, 09:19) saputello
Ergebnis 5 von 6 show 1 more comments

Es ist bei LaTeX normalerweise gar nicht erforderlich, dass man Klassen oder Pakete editiert, um eine abgewandelte Klasse bzw. ein abgewandeltes Paket zu erstellen.

Bei LaTeX2e wurde das Problem von abgewandelten Klassen und Paketen von Anfang an im Design mit vorgesehen und zwar in Form der Wrapper-Klassen und der Wrapper-Pakete. Im einfachsten Fall, nämlich in dem Fall, dass man die Definition der Klassenoptionen bzw. der Paketoptionen nicht ändern will, lädt eine solche Wrapper-Klasse einfach die Originalklasse über \LoadClassWithOptions und fügt dann ihre Änderungen ein:

\ProvidesClass{myarticle}[2013/10/14 v0.1 my own article wrapper class]
\LoadClassWithOptions{article}
% Und ab hier füge ich nun meine Änderungen an.

In Dokumenten wird dann statt article einfach myarticle verwendet und schon weiß auch jeder, dass eben nicht article im Original verwendet wird.

Bei einem Wrapper-Paket sieht das ganze sehr ähnlich aus:

\ProvidesPackage{mycolor}[2013/10/14 v0.1 my own article wrapper class]
\RequirePackageWithOptions{color}
% Und ab hier füge ich nun meine Änderungen an.

Auch hier sollte dann im Dokument statt des Originalpakets das eigene verwendet werden. Auch dass Pakete teilweise bereits von der Klasse geladen werden, ist in diesem Zusammenhang kein echtes Problem. Man kann trotzdem das eigene Paket noch nach der Klasse laden, das \RequirePackageWithOptions dann das Originalpaket automatisch nicht noch einmal lädt, die eigenen Änderungen aber dennoch ausgeführt werden.

Will man auch die Optionenverarbeitung verändern, so ist der Aufwand ggf. größer. Dann lädt man Klasse oder Paket mit \LoadClass bzw. \RequirePackage und muss eine eigene Optionenverarbeitung implementieren, die auch die nicht selbst verarbeiteten Optionen an die darunter liegende Klasse bzw. das darunter liegende Paket weiterreicht. Auch dafür bietet LaTeX mehrere Möglichkeiten. Es sei hier auf »LaTeX2ε for class and package writers« verwiesen.

Zusätzlich zu dem hier genannten Prinzip der Wrapper-Klassen und -Pakete gibt es noch das Prinzip der Konfigurationsdateien, das ebenfalls bereits in einem Kommentar von Clemens genannt wurde. Für LaTeX selbst und die Kernpakete findet man einige Informationen dazu in »Configuration Option for LaTeX2ε«. Ob andere Klassen und Pakete ebenfalls diese Möglichkeit bieten, ist meist in deren Anleitung dokumentiert.

Wie sich zeigt, bietet LaTeX hier auf der Implementierungsebene für Klassen und Pakete bereits Konzepte an, die weit leistungsfähiger als die TeX-Primitiven zum Laden von Dateien sind. Natürlich könnte man diese auch mit plainTeX nachbilden, landet dann aber zunehmend beim Nachprogrammieren von Formaten wie LaTeX oder ConTeXt. Daher ist es durchaus lohnend, nicht nur alles selbst irgendwie lösen zu wollen, sondern sich auch mit den Schichten dieser Formate zu beschäftigen und zu schauen, wie dergleichen bei diesen bereits gelöst ist.

Aber natürlich ist bei vielen Lizenzen auch die Erstellung eines abgeleiteten bzw. modifizierten Werkes möglich. Zu den Fragen der Praktikabilität, der Lizenzen etc. dabei siehe Clemens' Antworten. Bei den Lizenzen sei nur noch darauf hingewiesen, dass Distribution meist nicht nur bedeutet, dass man ein Paket oder Teile davon, über das Internet verteilt. Auch die Verteilung im lokalen Netzwerk beispielsweise für Familienmitglieder oder Mitarbeitet ist in der Regel bereits eine Distribution. Nach LPPL ist es übrigens nicht zwingend notwendig, eine Datei umzubenennen. Hingegen muss man alle Selbstidentifikationen ändern. Das betrifft bei Klassen beispielsweise den Klassennamen bei \ProvidesClass (darüber identifiziert sich die Klasse beispielsweise für \listfiles selbst) und bei allen Meldungen mit \ClassError, \ClassWarning…, \PackageInfo… oder \typeaout etc. Außerdem betrifft es Kommentare mit Maintainer- oder Support-Angaben. Darüber hinaus muss man ein unverändertes Paket bereitstellen, was allerdings nicht zwingend in physischer Form erfolgen muss.

Permanenter link

beantwortet 14 Okt '13, 09:26

saputello's gravatar image

saputello
11.1k154365
Akzeptiert-Rate: 51%

bearbeitet 14 Okt '13, 09:50

Deine Antwort
Vorschau umschalten

Folgen dieser Frage

Per E-Mail:

Wenn sie sich anmelden, kommen Sie für alle Updates hier in Frage

Per RSS:

Antworten

Antworten und Kommentare

Markdown-Grundlagen

  • *kursiv* oder _kursiv_
  • **Fett** oder __Fett__
  • Link:[Text](http://url.com/ "Titel")
  • Bild?![alt Text](/path/img.jpg "Titel")
  • nummerierte Liste: 1. Foo 2. Bar
  • zum Hinzufügen ein Zeilenumbruchs fügen Sie einfach zwei Leerzeichen an die Stelle an der die neue Linie sein soll.
  • grundlegende HTML-Tags werden ebenfalls unterstützt

Frage-Themen:

×48
×37
×13

gestellte Frage: 13 Okt '13, 01:08

Frage wurde gesehen: 14,517 Mal

zuletzt geändert: 14 Okt '13, 09:57