Wenn fertige Klassen nicht mehr reichen, kannst du eine eigene schreiben. Diese Seite behandelt das Erstellen einer Klasse. Zuerst geht es um die Standardoptionen, die eine Klasse üblicherweise akzeptiert (Schriftgröße, Papier, Spalten usw.). Dann bauen wir den Inhalt einer .cls- oder .sty-Datei auf: Identifikation mit \ProvidesClass, Optionen mit \DeclareOption, Ausführung mit \ProcessOptions, Aufbau auf einer vorhandenen Klasse mit \LoadClass; am Ende steht ein vollständiges Beispiel, das article erweitert. Zum Verwenden von Optionen auf Dokumentseite siehe “Document class & preamble”.
Klasse oder Paket?
Bevor du schreibst, entscheide, ob du eine Klasse (.cls) oder ein Paket (.sty) erstellst. Eine Klasse definiert die Dokumentart selbst und wird mit \documentclass genau einmal geladen; sie liefert das Gesamtgerüst und das Standardaussehen eines Aufsatzes, Buchs oder Foliensatzes. Ein Paket dagegen wird mit \usepackage geladen, und zwar beliebig viele davon, und ergänzt Funktionen unabhängig von der Dokumentart (amsmath für Mathematik, graphicx für Abbildungen usw.).
Mit den Worten des offiziellen clsguide ist der Test einfach: Wenn die Funktion mit jeder Dokumentklasse verwendbar wäre, mache daraus ein Paket; andernfalls eine Klasse. Ein ganzes Erscheinungsbild definieren? Klasse. Nur eine Funktion hinzufügen? Paket. Die Konventionen beim Schreiben sind fast identisch; die Befehle gibt es nur in einer Class- und einer Package-Variante (\ProvidesClass ↔ \ProvidesPackage, \LoadClass ↔ \RequirePackage, \PassOptionsToClass ↔ \PassOptionsToPackage).
Die Standardoptionen deiner Klasse
Nutzer werden deiner Klasse Optionen wie einer Standardklasse übergeben. Mindestens solltest du daher die üblichen Kandidaten unterstützen: 10pt / 11pt / 12pt für die Grundschriftgröße, a4paper / letterpaper für Papier, onecolumn / twocolumn für Spalten, oneside / twoside für ein- oder zweiseitigen Satz und draft (markiert übervolle Zeilen mit einem schwarzen Balken; Gegenstück final). Du musst das nicht selbst implementieren; wie unter “Optionen an eine Basisklasse weiterreichen” zu sehen, ist es üblich, sie einfach an eine Basisklasse wie article weiterzuleiten.
| Option | Bedeutung | Standard |
|---|---|---|
10pt / 11pt / 12pt | Grundschriftgröße des Textkörpers | 10pt |
a4paper / letterpaper | Papierformat (auch b5paper, legalpaper usw.) | letterpaper |
onecolumn / twocolumn | Einspaltig / zweispaltig | onecolumn |
oneside / twoside | Einseitiges / zweiseitiges Layout | oneside (aber twoside bei book) |
draft / final | Ob übervolle Zeilen mit einem schwarzen Balken markiert werden | final |
Ausgearbeitete Beispiele zum Angeben und Verwenden dieser Optionen auf der \documentclass[...]-Seite des Dokuments, einschließlich book-spezifischer Optionen wie openright, stehen auf der Schwesterseite “Document class & preamble”. Ab hier konzentrieren wir uns darauf, wie die empfangende Klasse geschrieben wird.
Die Datei am Anfang identifizieren
Die ersten zwei Zeilen einer Klassendatei (myclass.cls) sind fast Boilerplate. Zuerst deklariert \NeedsTeXFormat{LaTeX2e}, dass die Datei für LaTeX2e gedacht ist; bei älteren Formaten gibt es eine Warnung. Danach meldet \ProvidesClass{myclass}[2026/01/01 v1.0 ...] Klassenname, Veröffentlichungsdatum, Version und Kurzbeschreibung. Der Teil in eckigen Klammern ist optional, erlaubt aber Nutzern, über das Datum im Format YYYY/MM/DD eine Mindestversion anzufordern, etwa \documentclass{...}[2026/01/01], und schreibt die Identifikation ins Log.
Wenn du ein Paket schreibst, lautet das Gegenstück \ProvidesPackage{mypackage}[2026/01/01 v1.0 ...]; \NeedsTeXFormat ist bei beiden gleich. Feste Regel: Der Name in \ProvidesClass / \ProvidesPackage muss dem tatsächlichen Dateinamen entsprechen. In myclass.cls schreibst du also immer \ProvidesClass{myclass}.
\NeedsTeXFormat{LaTeX2e}
\ProvidesClass{myclass}[2026/01/01 v1.0 My example class]Optionen deklarieren — \DeclareOption
Jede Option, die deine Klasse akzeptiert, deklarierst du mit \DeclareOption{option}{code}. Wenn der Nutzer diese Option angibt, läuft ihr Code, sobald \ProcessOptions erreicht wird (unten beschrieben). Zum Beispiel könntest du einen eigenen draft-Schalter anbieten, der ein Boolesches Flag setzt.
Die Auffangstelle für Optionen, die du nicht deklariert hast, ist die Sternform \DeclareOption*{code}. Darin expandiert \CurrentOption zum Namen der gerade verarbeiteten Option. Die häufigste Zeile in einer eigenen Klasse leitet unbekannte Optionen direkt an die Basisklasse weiter. Dadurch können Nutzer Standardoptionen wie 10pt oder a4paper ganz selbstverständlich übergeben, obwohl du sie nie selbst deklariert hast.
% pass anything we do not handle ourselves on to article
\DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}}In einem Paket verwendest du das entsprechende \PassOptionsToPackage{\CurrentOption}{base}. Wenn du Standardwerte vor \ProcessOptions anwenden willst, schreibe \ExecuteOptions{a4paper,11pt}; dadurch läuft der Code dieser Optionen zuerst, auch wenn der Nutzer nichts angibt.
Optionen verarbeiten, dann an eine Basisklasse übergeben
Das Deklarieren von Optionen bewirkt allein noch nichts; ihr Code läuft erst beim Aufruf von \ProcessOptions. In der Praxis schreibt man fast immer \ProcessOptions\relax. Weil es auch die Sternform \ProcessOptions* gibt, wählt das abschließende \relax zuverlässig die ungesternte Form. Ungestertes \ProcessOptions verarbeitet Optionen in der Reihenfolge ihrer Deklaration; die Sternform verarbeitet sie in der vom Aufrufer angegebenen Reihenfolge.
Ein Layout von Grund auf zu bauen ist viel Arbeit, daher stehen die meisten eigenen Klassen auf einer vorhandenen. Das ist \LoadClass[options]{article}: Es lädt alle Befehle und das Styling von article.cls (Optionen wie twocolumn kannst du in den Klammern übergeben). \LoadClass darf nur innerhalb einer Klassendatei verwendet werden. Die Reihenfolge ist entscheidend: Damit die vom Nutzer bei \documentclass[...] angegebenen Optionen die Basisklasse erreichen, kommt \LoadClass nach der Optionsverarbeitung (\ProcessOptions). Erst die Weiterleitung einrichten, dann \ProcessOptions verteilen lassen, dann die Basis laden.
Wenn du der Basisklasse einfach genau dieselben Optionen geben willst, die deine Klasse erhalten hat, ist \LoadClassWithOptions{article} praktisch; es reicht die globalen Optionen der Klasse unverändert weiter. Beim Schreiben eines Pakets verwendest du statt \LoadClass \RequirePackage (das Autoren-Gegenstück zu \usepackage in der Präambel) und für den Alles-durchreichen-Fall \RequirePackageWithOptions.
Alles nach \LoadClass ist der Ort, an dem endlich der Charakter deiner Klasse steht: Überschriften mit \renewcommand umdefinieren, Ränder mit \setlength anpassen, neue Befehle und Umgebungen mit \newcommand / \newenvironment definieren und benötigte Zusatzpakete ab hier mit \RequirePackage laden.
Vollständiges Beispiel: minimale Klasse, die article erweitert
Zusammengesetzt ergibt das diese minimale .cls. Sie baut auf article auf, ergänzt eine eigene draft-Option, leitet unbekannte Optionen an article weiter, richtet zuletzt die Ränder ein und definiert einen eigenen Befehl. Speichere sie als myclass.cls und verwende sie im Dokument mit \documentclass[11pt,a4paper]{myclass}.
\NeedsTeXFormat{LaTeX2e}
\ProvidesClass{myclass}[2026/01/01 v1.0 My example class]
% --- declare options ---
\newif\ifmy@draft
\DeclareOption{draft}{\my@drafttrue}
% forward everything else to article
\DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}}
% --- execute and load the base class ---
\ExecuteOptions{a4paper} % a default if the user gives none
\ProcessOptions\relax
\LoadClass{article}
% --- this class's own setup ---
\RequirePackage[margin=25mm]{geometry}
\setlength{\parindent}{0pt}
\newcommand{\version}{v1.0}
\ifmy@draft \RequirePackage{draftwatermark}\fi
\endinputDas abschließende \endinput teilt LaTeX mit, ab hier nichts weiter aus dieser Datei zu lesen; es ist üblich, es einzufügen. Für ein Paket ersetzt du den Anfang durch \ProvidesPackage und \LoadClass durch \RequirePackage: dasselbe Gerüst wird dann zu einer .sty-Datei.
Der moderne Weg: Schlüssel-Wert-Optionen (expl3)
Der oben gezeigte \DeclareOption-Mechanismus ist weiterhin völlig gültig, ist aber vor allem für Ein/Aus-Schalteroptionen gebaut. Für neuen Code, der natürliche Schlüssel-Wert-Optionen wie name=value verwenden soll, empfiehlt sich heute die eigene Schnittstelle des LaTeX-Kernels: Schlüssel mit \DeclareKeys deklarieren und mit \ProcessKeyOptions verarbeiten. Sie basiert auf l3keys aus expl3 (LaTeX3) und ist Teil aktueller LaTeX-Kernel.
Früher erledigte man das mit dem Paket l3keys2e, doch der Kern dieser Funktionalität ist inzwischen in den Kernel gewandert. Neuer Code kann daher \ProcessKeyOptions direkt aufrufen, ohne das Paket zu laden. Trotzdem beruhen vorhandene Tutorials und viele Pakete noch auf dem \DeclareOption-Stil; das Gerüst dieser Seite zu verstehen bleibt also wichtig. Beim Umstieg auf Schlüssel-Wert-Optionen solltest du den entsprechenden Abschnitt des aktuellen clsguide (“LaTeX2e for class and package writers”) lesen.
Ein Minimaltest vor der Weitergabe
Eine Klasse beeinflusst das ganze Dokument, sobald sie geladen ist. Kläre ihr Verhalten daher mit einem winzigen Testdokument, bevor du echten Inhalt schreibst. Prüfe zuerst, dass Standardoptionen wie 10pt, 11pt, a4paper und draft die Basisklasse erreichen, während nur deine eigenen Optionen von deinem Code verarbeitet werden. Scheitert das, liegt es meist an der Position von \ProcessOptions / \ProcessKeyOptions, der Weiterleitung unbekannter Optionen oder der Reihenfolge von \LoadClass.
\documentclass[11pt,a4paper,draft]{myclass}
\begin{document}
\section{Smoke test}
本文の基準サイズ、用紙、下書き表示、見出し、余白を確認する。
\end{document}- Identifiziert das Log die Klasse? Prüfe, dass Datum und Version aus
\ProvidesClassim.logerscheinen. Unterschiedliche Datei- und Klassennamen sorgen später für Verwirrung. - Sind Standardoptionen erhalten geblieben? Wenn
11ptodertwocolumnignoriert wird, prüfe die Behandlung unbekannter Optionen, die zur Basisklasse weiterleitet. - Verhalten sich Dokumentmakros in Präambel und Textkörper? Kompiliere je eine Überschrift, Anmerkung, Abbildung und Tabelle, denn das sind die ersten Elemente, die echte Nutzer anfassen.
- Alles nach
\endinputinert halten. Notizen oder Beispiele danach können unerwartet gelesen werden, wenn die Markierung fehlt oder verschoben wird.
Auch die Verteilungsform bedenken
Eine eigene Klasse wird nicht dann geprüft, wenn sie bei dir erstmals läuft, sondern wenn jemand anders sie in einer anderen Umgebung lädt. Mindestens sollten .cls, ein kurzes Beispieldokument, README und Changelog im selben Verzeichnis liegen, und das Beispiel sollte unverändert kompilieren. Trenne im README Optionen, die an die Basisklasse weitergehen, von Optionen, die deine Klasse selbst behandelt, damit Nutzer sehen, wo 11pt oder a4paper wirken. Lege je eine Überschrift, Liste, Abbildung/Tabelle und Bibliografie ins Beispiel, damit die Elemente, die Klassen am häufigsten zuerst beschädigen, gemeinsam geprüft werden.
myclass/
myclass.cls
sample.tex
README.md
CHANGELOG.mdVor der Verteilung solltest du \listfiles ins Beispiel setzen, damit das Log die geladenen Dateien und Versionen aufzeichnet. So lässt sich diagnostizieren, ob ein Nutzer eine alte lokale myclass.cls hat oder ob nötige Pakete wie erwartet geladen werden. Weil eine Klasse das Fundament des gesamten Dokuments ist, zählen saubere Ladereihenfolge, Optionsverarbeitung und Log-Informationen auf lange Sicht mehr als ein weiteres Textkörper-Makro.