Was ist echte WYSIWYG-Bearbeitung?

Der Begriff WYSIWYG – What You See Is What You Get – ist weit verbreitet, wird oft ungenau verwendet und häufig missverstanden.

In diesem Artikel erklären wir, was echtes WYSIWYG-Editing aus architektonischer Sicht bedeutet, warum viele Editoren dies nicht umsetzen und worauf Entwickler bei der Integration von Dokumenteneditoren in ihre Produkte achten sollten.

WYSIWYG ist einer dieser Begriffe, die jeder benutzt, aber nur wenige wirklich ernst nehmen. Heutzutage wird fast jedes Rich-Text-Tool, jeder browserbasierte Editor und jedes Inhaltsfeld als WYSIWYG-Editor vermarktet. Doch sobald ein Dokument exportiert wird und sich das Layout ändert, ist das Versprechen hinfällig. Diese Diskrepanz zwischen Erwartung und Realität ist kein Zufall: Sie ist architektonisch bedingt.

In moderner Software wird WYSIWYG oft als UI-Funktion behandelt, doch in Wirklichkeit ist echtes WYSIWYG ein Problem der Dokumentenverarbeitung und -darstellung. Es hängt davon ab, wie Dokumente intern modelliert werden, wie das Layout berechnet wird und ob dieselbe Logik beim Bearbeiten, in der Vorschau und beim Export konsistent angewendet wird.

Diese Unterscheidung wird entscheidend, wenn Dokumenteneditoren in Anwendungen eingebettet werden. Für Entwickler, Systemarchitekten und CTOs ist echtes WYSIWYG kein kosmetisches Detail. Es ist eine Voraussetzung für vorhersehbare Ergebnisse, stabile Vorlagen und das Vertrauen der Benutzer.

Was ist WYSIWYG? Definition und Vorteile

Um zu verstehen, warum echtes WYSIWYG selten ist, hilft es, sich die ursprüngliche Bedeutung von WYSIWYG vor Augen zu führen. „What You See Is What You Get“ (Was Sie sehen, ist, was Sie bekommen) bedeutete nie, die Bearbeitung nur komfortabel zu gestalten. Das ursprüngliche Versprechen war eindeutig: Das während der Bearbeitung angezeigte Dokument muss identisch mit dem Ausgabedokument sein, egal ob gedruckt oder exportiert.

Im Laufe der Zeit wurde diese Definition verwässert. Viele Tools, die heute als WYSIWYG-Texteditoren bezeichnet werden, garantieren nur eine annähernde Formatierung während der Bearbeitung. Sie verlassen sich auf die Nachbearbeitung beim Export, um das Layout zu „korrigieren“, oft mithilfe einer völlig anderen Rendering-Engine. Aus technischer Sicht ist dies bereits ein Vertragsbruch.

Echtes WYSIWYG bedeutet Layoutgenauigkeit, nicht visuelle Ähnlichkeit. Das heißt, Zeilenumbrüche, Seitenumbrüche, Ränder und Objektpositionen sind während der Bearbeitung des Dokuments endgültig. Wenn ein Absatz während der Bearbeitung auf Seite zwei erscheint, muss er auch nach dem Export auf Seite zwei sein.

Dies ist besonders wichtig für Office-Formate wie DOCX, XLSX und PPTX: Diese Formate sind keine HTML-Dokumente, sondern layoutorientierte Spezifikationen mit strengen Regeln für Seitennummerierung, Schriftmetriken, Zeilenabstand und Objektverankerung. Jeder Editor, der sie primär als Webinhalte und erst sekundär als Dokumente behandelt, beeinträchtigt zwangsläufig die WYSIWYG-Genauigkeit.

Herausforderungen und Nachteile von WYSIWYG in Web-Editoren

Wenn echtes WYSIWYG so wertvoll ist, warum gelingt es den meisten Web-Editoren dann nicht? Die Antwort liegt in einer Reihe gängiger technischer Kompromisse, die Komfort und Geschwindigkeit über die Genauigkeit des Layouts stellen.

Der am weitesten verbreitete Kompromiss ist das HTML- und DOM-basierte Rendering. Browser sind zwar hervorragend darin, responsive Webseiten darzustellen, aber grundsätzlich ungeeignet für ein druckgenaues Dokumentlayout. HTML kennt keine festen Seitenzahlen, Kopf- und Fußzeilen, Fußnoten oder an Text verankerte Objekte. Daher wird das Dokumentlayout während der Bearbeitung approximiert und später beim Export neu berechnet.

In der Praxis führt dies zu einer Reihe vorhersehbarer architektonischer Abkürzungen:

• HTML/DOM-basierte Approximation des Dokumentlayouts, wobei Office-Dokumente als Webinhalte und nicht als paginierte Dokumente gerendert werden.
• Unterschiedliche Rendering-Engines für Bearbeitung und Export: Der Browser übernimmt die Bearbeitung auf dem Bildschirm, während eine separate Engine das Layout bei der DOCX- oder PDF-Generierung neu berechnet.
• Die Seitennummerierung wird erst beim Export berechnet. Während der Bearbeitung des Dokuments werden daher keine Seitenumbrüche angezeigt.
• Es gibt Inkonsistenzen bei der Schriftdarstellung auf verschiedenen Plattformen. Kleine Unterschiede in der Schriftwiedergabe summieren sich und können das Layout der Seiten verändern.
• Das Darstellungsverhalten ist browserabhängig. Das Layout variiert je nach Browser oder sogar Browserversion.

Ein weiteres häufiges Problem ist die Seitennummerierung selbst. Viele Redakteure berechnen Seitenumbrüche während der Bearbeitung gar nicht. Seiten existieren nur gedanklich bis zum Export, wodurch seitenabhängige Inhalte wie Kopf- und Fußzeilen sowie Rechtsklauseln unzuverlässig werden.

Die Schriftverarbeitung bringt eine weitere Komplexitätsebene mit sich. Die Schriftmetriken variieren je nach Betriebssystem, Browser und Rendering-Engine. Selbst minimale Unterschiede summieren sich über Zeilen und Seiten und verschieben Inhalte nach vorne oder hinten. Ohne strenge Kontrolle über die Schriften und eine konsistente Metrikberechnung kann die Layoutgenauigkeit nicht gewährleistet werden.

Schließlich untergräbt das browserabhängige Rendering-Verhalten die Deterministik. Verschiedene Browser rendern Text unterschiedlich, und selbst kleinere Browser-Updates können das Layoutverhalten verändern. Wenn das Erscheinungsbild eines Dokuments von der Client-Umgebung abhängt, wird WYSIWYG bedingt statt garantiert.

Technische Kriterien der echten WYSIWYG-Bearbeitung

Echtes WYSIWYG ist nicht subjektiv. Es folgt klaren, unabdingbaren technischen Kriterien, die echte Dokumenteneditoren von visuellen Annäherungen unterscheiden.

Erstens muss für Bearbeitung und Export ein einheitliches Dokumentmodell verwendet werden. Dieses Modell muss die tatsächliche Struktur des Dokumentformats abbilden, nicht eine vereinfachte oder Zwischenversion. Wird der Inhalt zur Bearbeitung in HTML konvertiert und später wiederhergestellt, gehen Informationen verloren und Layoutabweichungen sind unvermeidlich.

Zweitens muss in allen Modi dieselbe Rendering-Logik angewendet werden. Bearbeitungsansicht, Vorschau und Export müssen auf derselben Layout-Engine basieren. Jede Abweichung im Rendering-Verhalten führt zu Inkonsistenzen.

Drittens muss der Editor alle layoutkritischen Elemente korrekt verarbeiten:

• Schriftarten und Schriftmetriken
• Seitennummerierung und Seitenumbrüche
• Ränder, Abstände und Ausrichtung
• Tabellen, Bilder, Formen und schwebende Objekte
• Kopf- und Fußzeilen, Fußnoten und Seitenzahlen

Dies sind keine fortgeschrittenen Funktionen, sondern die Grundlage für die Dokumentgenauigkeit.

Echtes WYSIWYG erfordert plattformunabhängiges Rendering. Ein Dokument muss unabhängig von Browser und Betriebssystem identisch aussehen. Ändert sich das Layout je nach Clientumgebung, erfüllt der Editor die WYSIWYG-Definition nicht.

Die Rolle von WYSIWYG in eingebetteten Editorarchitekturen

Die Bedeutung von WYSIWYG wird in eingebetteten Anwendungsfällen besonders deutlich. Wenn Entwickler fragen, wofür die Funktionalität eines WYSIWYG-Editors wirklich benötigt wird, liegt die Antwort in Vorhersagbarkeit und Vertrauen.

Wird ein Dokumenteneditor in eine SaaS-Plattform eingebettet – sei es über eine API oder eine React-WYSIWYG-Editor-Integration –, liegt die Verantwortung für die Dokumentenausgabe beim Plattformbetreiber. Benutzer erwarten, dass Dokumente exakt wie gestaltet aussehen, und jede Inkonsistenz wirkt sich direkt auf das Produkt aus.

Automatisierte Dokumentengenerierung und vorlagenbasierte Workflows verschärfen dieses Problem. Vorlagen basieren auf festen Layoutvorgaben. Ein einziger unerwarteter Seitenumbruch kann das Branding beeinträchtigen, Unterschriften falsch ausrichten oder die Formatierung ungültig machen. Ohne echtes WYSIWYG werden Vorlagen fehleranfällig und die Wartung wird aufwändig.

Im juristischen, finanziellen und geschäftlichen Kontext ist Layoutgenauigkeit unerlässlich. Verträge, Rechnungen und Berichte müssen die Formatierung exakt beibehalten. Wenn exportierte Dokumente von der Ansicht der Benutzer während der Bearbeitung abweichen, schwindet das Vertrauen in das System sofort.

Aus betrieblicher Sicht erhöht das Fehlen eines WYSIWYG-Editors den Supportaufwand. Layoutprobleme führen zu Supportanfragen, manuellen Korrekturen und Frustration bei den Benutzern. API-Nutzer erwarten eine zuverlässige Exportqualität, die nicht verhandelt werden muss. Wird diese Erwartung nicht erfüllt, wird der integrierte Editor zur Belastung statt zum Vorteil.

WYSIWYG-Bearbeitungsansatz in ONLYOFFICE Docs Developer

ONLYOFFICE Docs Developer basiert auf der Annahme, dass WYSIWYG eine bewusste Architekturentscheidung und keine bloße Verbesserung der Benutzeroberfläche ist.

Im Kern steht ein einheitliches Dokumentmodell, das DOCX-, XLSX- und PPTX-Strukturen direkt abbildet. Es gibt weder einen HTML-Proxy noch eine verlustbehaftete Konvertierungsschicht zwischen Bearbeitung und Export. Der Benutzer bearbeitet direkt das Dokument.

Das gleiche Layout und die gleiche Rendering-Engine werden konsistent für Bearbeitung, Vorschau und Export verwendet. Dadurch wird sichergestellt, dass Seitennummerierung, Abstände und Objektpositionierung nur einmal berechnet werden und während des gesamten Dokumentlebenszyklus stabil bleiben.

Der Editor verwendet JavaScript und HTML5 Canvas für das Rendering, serverseitig Node.js. Dies gewährleistet eine hundertprozentige Darstellungs-, Druck- und Seitennummerierungsgenauigkeit in allen Browsern.

ONLYOFFICE arbeitet nativ mit Office Open XML-Formaten und ermöglicht so die präzise Kontrolle über die in der Spezifikation definierten Layoutregeln. Dieser native Ansatz eliminiert die Inkonsistenzen, die durch Formatkonvertierung entstehen.

In eingebetteten Umgebungen gewährleistet diese Architektur eine konsistente Darstellung unabhängig von Browser und Betriebssystem. Ob in eine SaaS-Plattform, ein Dokumenten-Workflow-System oder eine individuelle Anwendung integriert – das Layoutverhalten bleibt stets vorhersehbar.

ONLYOFFICE Docs Developer wurde als API-First-Lösung konzipiert und unterstützt skalierbare Bereitstellungen bei gleichzeitiger Wahrung der Exportgenauigkeit. Dadurch eignet es sich ideal für Umgebungen mit hoher Last, in denen Dokumentengenauigkeit von entscheidender Bedeutung ist.

Fazit

Echtes WYSIWYG erfordert ein einheitliches Dokumentenmodell, eine einheitliche Rendering-Engine und einen deterministischen Layoutansatz. Alles andere ist nur eine Annäherung, egal wie elegant die Benutzeroberfläche auch erscheinen mag.

Für Entwickler, die Dokumenteneditoren einbinden, ist dieser Unterschied entscheidend. Ohne echtes WYSIWYG werden Exporte unzuverlässig, Vorlagen funktionieren nicht mehr und das Vertrauen der Nutzer schwindet. Mit echtem WYSIWYG hingegen werden Dokumenten-Workflows vorhersehbar, skalierbar und zuverlässig.

Wenn Dokumente in Ihrem Produkt eine wichtige Rolle spielen, ist echtes WYSIWYG unerlässlich.

Sichern Sie sich ONLYOFFICE Docs Developer und bearbeiten Sie Dokumente im echten WYSIWYG-Modus

Gewährleisten Sie eine layoutgenaue Darstellung vom Bearbeiten bis zum Export mit einem einheitlichen Dokumentmodell und einer integrierten Rendering-Engine.

HERUNTERLADEN