Typst wird zum gleichberechtigten Suite-Dienst: Dokumentenrendering als Service
Hochschulen leben von Dokumenten: Abschlussarbeiten, Klausuren, Vorlesungsskripte, Zertifikate und Verwaltungsschreiben. Die meisten davon entstehen bislang manuell oder mit fragiler Lokal-Software. Mit dem aktuellen Integrationssprint ist Typst, ein markup-basiertes Satzesystem und die moderne Alternative zu LaTeX, nun ein gleichberechtigter openEduSuite-Dienst, der deterministische, template-basierte Dokumentenproduktion antreiben kann.
Warum Satz ins Suite-Repertoire gehört
Die Suite deckt kollaboratives Editieren bereits mit ihren Office- und Editor-Diensten ab. Was fehlte, war Produktionssatz: die Fähigkeit, ein Dokument reproduzierbar aus Template und Daten auf dem Server zu kompilieren. Das ist eine andere Aufgabe: Klausuren, die aus Registry-Daten generiert werden, Zertifikate in Serie, Schreiben aus strukturierten Daten; sie verlangt eine Satz-Engine statt eines interaktiven Editors.
Ein upstream-geführter Fork, keine Abspaltung
Die Suite verwendet tobias-weiss-ai-xr/typst, einen Fork von typst/typst mit strikter Trennungspolitik:
- Wöchentlicher Upstream-Sync: ein geplanter Workflow mergt Upstream
mainin den Fork. Merge-Konflikte lassen den Workflow laut scheitern, damit ein Mensch sie auflöst; nichts wird stillschweigend begraben. - Fork-eigener Code bleibt in seiner Spur: alles Ergänzte liegt unter
render-service/und.github/workflows/, sodass künftige Upstream-Merges konfliktfrei bleiben. - Releases folgen Upstream: das aktuelle Release
v0.15.1trägt die Upstream-Versionsnummer und wird bei jedem Sync zurückgesetzt.
Das Ziel: ein dünner, wohlerzogener Fork bleiben; wir liefern Deployment-Wert, keine Engine-Spaltpaltung.
Ein Renderdienst mit harten Kanten
Der neue Renderdienst ist ein bewusst kleiner HTTP-Wrapper um die typst-CLI, geschrieben allein mit der Python-Standardbibliothek; kein Framework, keine zu auditierenden Abhängigkeiten:
POST /render {"source": "= Hello", "format": "pdf|png|svg",
"assets": {"data.csv": "..."}} -> Dokument-Bytes
GET /healthz -> {"status": "ok", "typst": "typst 0.15.1 ..."}
Die Vertrauensgrenze wird im Prozess selbst erzwungen:
- Request-Limits (5 MB Body, 2 MB Quelltext) und ein Kompilier-Timeout von 60 Sekunden.
- Asset-Namen sind auf flache Bezeichner beschränkt; kein Path Traversal.
- Das Kompilieren läuft in einem isolierten temporären Verzeichnis mit Root-Beschränkung; der Compiler hat keinen Netzwerkzugriff.
- Die Kompilier-Parallelität ist begrenzt, um Cluster-Knoten vor CPU-Sättigung zu schützen.
- Der Container betreibt den Dienst unter einem unprivilegierten Benutzer.
- Liberation-Schriften sind im Image enthalten und decken die metrisch kompatiblen Familien Arial/Times/Courier ab, die die meisten institutionellen Templates voraussetzen.
Eine kleine Lehre aus dem Sprint: Auch ein abhängigkeitsfreier Wrapper braucht echte API-Tests. Ein Fehler bei Schlüsselwortargumenten im Kompilierpfad wurde gefunden und behoben; ein HTTP-End-to-End-Regressionstest bewacht die Stelle jetzt.
Images, die sich selbst ausliefern
Jedes Release veröffentlicht zwei Multi-Arch-Images (linux/amd64 und linux/arm64) in die GitHub Container Registry:
ghcr.io/tobias-weiss-ai-xr/typst: die unveränderte typst-CLIghcr.io/tobias-weiss-ai-xr/typst-render: der Renderdienst
Die Release-Pipeline baut, smoke-testet und veröffentlicht beide Images automatisch; das Smoke-Test-Ergebnis wird am Image-Digest verankert; was getestet wurde, ist nachweislich das, was ausgeliefert wurde.
Deployment in beiden Stacks
| Stack | Anbindung |
|---|---|
| Kubernetes (Hochschulen) | Helmfile-Chart, auf ein Release-Tag gepinnt |
| Docker Compose (KMU) | Eigenes Service-Profil im Compose-Stack |
Beide Deployments folgen derselben Disziplin wie jeder andere Suite-Dienst: nur ein interner Netzwerkpfad, ein Liveness-Probe auf /healthz und Images, die per Release-Tag gepinnt sind. Der Dienst ist bewusst maschinenorientiert; Template-Pipelines, Admin-Werkzeuge und Portal-Backends rufen die API auf; Menschen schreiben Dokumente woanders (siehe unten).
Interaktives Authoring, komplett FOSS
Der gehostete Typst-Editor auf typst.app ist proprietäre Software; für eine Suite, deren Versprechen durchgängig Open Source lautet, kam er nie infrage. Der Sprint liefert deshalb zwei selbst gehostete, vollständig offene Authoring-Flächen:
1. Ein gehärteter Web-Editor auf dem Render-Dienst (typst.openedusuite.org, hinter Keycloak-SSO). Derselbe Wrapper ohne Abhängigkeiten serviert jetzt einen Single-Page-Editor mit Live-SVG/PDF-Vorschau, eingebauten Beispieldokumenten, Formatwahl und Tastatur-first-Bedienung; null externe CDNs, null clientseitige Abhängigkeiten zum Auditieren. Ein Bug beim Response-Streaming (doppeltes Lesen des Render-Bodys) fiel beim Testen auf und ist jetzt durch einen Regressionstest abgesichert.
2. TOSS (der Typst Open-Source Server) (toss.openedusuite.org) für kollaboratives Authoring. TOSS (AGPL-3.0, pku-typst/TOSS) ist ein selbst hostbarer Kollaborations-Arbeitsbereich: Realtime-Multi-User-Editing mit Präsenz-Anzeige, Kompilierung direkt im Browser via Typst-WASM (sofortige Vorschau ohne Server-Roundtrip), versionierte Projekte auf Git-Basis und eine Template-Galerie. Die Suite deployt ihn nativ mit PostgreSQL-Persistenz, Git-Speicher auf einem Persistent Volume und, anders als die übrigen Katalogdienste, direkter OIDC-Föderation mit Keycloak statt oauth2-proxy-Gate: TOSS spricht OIDC nativ, toss.openedusuite.org meldet sich also über dieselbe institutionelle Identität an wie jeder andere Dienst.
Damit verlässt interaktives Authoring nie den Open-Source-Stack: schnelles Einzeldatei-Rendering passiert im Web-Editor, mehrnutzige Dokumentprojekte leben in TOSS, und deterministische Batch-Produktion läuft über die Render-API.
Wie es weitergeht
- Ein Template-Repository für institutionelle Dokumente: Klausuren, Zertifikate, Schreiben, als Futter für die Render-API und die TOSS-Template-Galerie.
- Pipeline-Integrationen, etwa Zertifikate, die regelmäßig aus Registry-Daten erzeugt werden.
- Weiteres Upstream-Tracking: der wöchentliche Sync hält den Fork im schnelllebigen Typst-Ökosystem aktuell.
Call to Action
- Weiterlesen: Die technischen Details stehen im Begleitartikel Typst Document Rendering Architecture.
- Ausprobieren: Richten Sie eine Template-Pipeline auf die Render-API, schreiben Sie Ihr nächstes Übungsblatt im Web-Editor oder laden Co-Autoren in einen TOSS-Arbeitsbereich ein.
- Mitmachen: Treten Sie der openEduSuite-Community bei und helfen Sie beim Template-Repository.
Deterministischer Satz, deployt wie jeder andere Dienst; Dokumente sind auch Infrastruktur.
Markenhinweis: Typst ist ein Produkt von typst (typst.app). Dieser Artikel ist unabhängig und steht in keiner Verbindung zu typst noch wird er von diesem unterstützt. Alle anderen Produktnamen sind Marken ihrer jeweiligen Inhaber.
