Überarbeitungsverlauf

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][1]« 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ε][2]«. 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 ~~gibt es ja bereits~~ 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. [1]: http://www.ctan.org/pkg/clsguide [2]: http://www.ctan.org/pkg/cfgguide

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.~~ Möglichkeiten. Es sei hier auf »[LaTeX2ε for class and package writers][1]« 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ε][1]«.~~ LaTeX2ε][2]«. 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. ~~von Änderungen direkt in den Paketen und Klassen~~ dabei gibt es ja bereits 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. [1]: http://www.ctan.org/pkg/clsguide [2]: http://www.ctan.org/pkg/cfgguide

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. 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ε][1]«. 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. Zu den Fragen der Praktikabilität, der Lizenzen etc. von Änderungen direkt in den Paketen und Klassen gibt es ja bereits 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.~~muss. [1]: http://www.ctan.org/pkg/cfgguide

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.~~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. 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. Zu den Fragen der Praktikabilität, der Lizenzen etc. von Änderungen direkt in den Paketen und Klassen gibt es ja bereits 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.