Ihr habt die Basis von one2edit™ vor über 20 Jahren gelegt und seid dem Server-basierten Ansatz treu geblieben. Es gibt ja einige Lösungen am Markt wie Silicon Publish, 2Imagine, Chili Publish oder CI Book, die auf Browser-basiertes Editieren und Rendering setzen. Was sind die Unterschiede?
Markus Kuhnert: Das Rendering, also das Erzeugen einer Vorschau des Adobe InDesign Dokuments, ist die Basis bei Publishing- und Medienmanagement-Lösungen. Findet die Bearbeitung im Browser statt, muss eine Zuordnung von InDesign Funktionen, Dokument-Geometrie, Formaten, Inhalten und Schriften zwischen dem InDesign Dokument (über eine InDesign Engine, s. u.) und dem Online-Dokument (im Browser) stattfinden. Das Adobe InDesign Dokument wird also ausgelesen, damit Geometrie, Formate etc. daraufhin online im Browser in einem Editor simuliert bzw. nachgebildet werden. Nach der Online-Bearbeitung werden die geänderten Inhalte über das Mapping wieder in das InDesign zurückgespielt oder über eine proprietäre Engine z. B. als PDF ausgegeben.
Es findet also eine Konvertierung statt?
Markus Kuhnert: Zum Teil. Zum Auslesen der Funktionen, Geometrie, Formate und Inhalte des InDesign Dokuments gibt es drei Möglichkeiten. Beim nativen InDesign Format kann dies serverbasiert über den Adobe InDesign Server oder über ein Plugin für Adobe InDesign Desktop erfolgen. Adobe InDesign Server und InDesign Desktop nutzen die identische Render-Engine. Alternativ kann statt einem nativen InDesign Dokument auch das InDesign Austauschformat IDML (InDesign Markup Language) genutzt werden, welches eine auf XML-basierende Repräsentation des InDesign Dokuments ist. Dieses IDML Format muss jedoch mit einer InDesign-Engine (Desktop oder Server) erzeugt werden und ist selbst kein natives InDesign Format, sondern eine Konvertierung. Der Einsatz eines InDesign Servers garantiert im Umkehrschluss nicht automatisch eine Standverbindlichkeit oder die volle Unterstützung aller InDesign Funktionen im Browser.
Warum ist das so?
Markus Kuhnert: Damit das InDesign Dokument möglichst getreu in einem browser-basierten Editor nachgebildet werden kann, müssen sämtliche InDesign-spezifischen Funktionen online simuliert werden. Ansonsten kommt es zu Einschränkungen hinsichtlich Funktion und Standverbindlichkeit. Viele dieser Funktionen sind jedoch patentiert und dürfen nicht nachgebaut werden oder deren technische Umsetzung ist nicht bekannt (no public domain). Die Darstellung im Browser ist hinsichtlich der Typografie- und Designfunktionen im Vergleich zu InDesign ist deshalb stark limitiert. Als Beispiel unterstützt CSS (Cascading Style Sheets beschreibt die Präsentation eines HTML oder XML Dokuments) nur einen Bruchteil der Typografie-Funktionen von InDesign.
Und auch die Umsetzung gewisser Funktionen im Browser ist nur sehr schwer oder gar nicht möglich. InDesign Funktionen sind in C++ entwickelt, hochoptimiert, kompiliert und laufen nativ und somit auch hoch-performant auf dem System. Ein Browser hingegen ist auf Javascript beschränkt. Javascript-Funktionen müssen bei der Ausführung kompiliert werden und werden nicht nativ, sondern in einer Virtual Machine ausgeführt. Dies erfordert noch mehr Leistung vom betreibenden System. Im Vergleich benötigt daher eine Funktion in C++ nur einen Bruchteil der Verarbeitungszeit einer vergleichbaren Javascript-Funktion.
Kannst du ein Beispiel nennen?
Markus Kuhnert: Nehmen wir die Übersatz-Funktion: Während eine Übersatzprüfung in InDesign auch bei komplexen Dokumenten in Sekundenbruchteilen bei jedem Tastenanschlag oder Änderung der Formatierung ausgeführt wird, kann eine Berechnung über Javascript (also im Browser) durchaus Minuten dauern.
Eine weitere Herausforderung besteht in der präzisen Abbildung der Typografie und der Verwendung von Schriften. Für eine Darstellung müssen die Schriften konvertiert werden. Das ist rechtlich in der Regel problematisch. Alternativ können Schriften mit einem Webfont zugeordnet werden. Diese haben aber einen unterschiedlichen Aufbau, teilweise abweichendes Kerning und erfordern eine zusätzliche Lizenzierung. Mit one2edit™ steht den Anwendern hingegen eine zentrale Schriftenverwaltung für den InDesign-Server zur Verfügung: alle one2edit™ Anwender können so dieselben Schriften nutzen und es müssen für die Bearbeitung der InDesign Dokumente über den Browser keine Schriften auf dem Anwender-Computer installiert werden. Die zentrale Verwaltung der Schriften sorgt für Rechtssicherheit, ein einheitliches Schriftbild im Brand Design (Typografie) und spart obendrein meist noch Lizenzkosten ein.
Aber kommen wir zurück zu den Nachteilen der anderen Lösungen: Da das InDesign Dokument im Browser nur eine Simulation ist, ist die Bearbeitung im Browser nicht standverbindlich und erfordert zusätzliches Korrekturlesen des Ausgabedokuments. Es entsteht ein höherer Abstimmungsaufwand im Produktionsprozess. Denn will keiner. Mit einer digitalen Publishing- und Medienmanagement-Lösung möchte man den Aufwand ja deutlich senken, die KPIs in die Höhe treiben und den Automatisierungsgrad steigern. Das ist Browser-basiert aus den genannten Gründen schwierig.
Und es gibt noch einen Punkt: Die Marketingabteilungen und die Agenturen arbeiten mit immer größeren Datenmengen und sie arbeiten Corona-bedingt auch immer stärker verteilt. Die Übertragung von hohen Datenmengen in den Browser, insbesondere bei Bilddaten, Schriften und großen Dokumenten ist kritisch. Ein 120 MB InDesign Dokument mit Gigabyte großen Bilddaten kann nicht performant in den Browser geladen werden.
Aber es gibt doch sicher auch Vorteile?
Markus Kuhnert: Der größte Vorteil des browser-basierten Editierens und Rendering stellt die schnelle Rückmeldung auf Benutzereingaben dar. Dies ist möglich, da Eingaben nicht erst an den Server zur Berechnung und Rendering geschickt werden müssen, sondern direkt durch die Browser-Dokumenten-Simulation erfolgen. Außerdem sind dadurch die Ansprüche an die Server-Infrastruktur äußerst gering.
Aber die Nachteile überwiegen und sind in der Praxis leicht nachvollziehbar: Man nehme komplexe und/oder umfangreiche Dokumente mit InDesign-spezifischen Funktionen wie z. B. verankerten Objekten, Inline-Grafiken, verkettete Textrahmen über mehrere Seiten, Mikrotypografie, optischem Randausgleich etc. und versuche diese Browser-basiert darzustellen und zu bearbeiten. Hier ist Scheitern vorprogrammiert.
Oder selbst bei großen Textmengen gibt es in der Regel schon Unterschiede im Zeilenumbruch. Das native InDesign Dokument, die Online-Simulation im Browser und dem Ausgabedokument weisen Unterschiede auf, was den Bearbeitenden bzw. den Auftraggeber nur unnötig verwirrt.
Kommen wir zum Server-basierten Editieren und Rendering mit one2edit™. Welche Vor- und Nachteile gibt es dabei?
Markus Kuhnert: Wie der Name schon sagt, erfolgt das Rendering des InDesign Dokuments während der Bearbeitung auf dem Server statt. Die Ansicht im Browser entspricht dadurch 1:1 dem Adobe InDesign Desktop/Server, da hier die Adobe InDesign Engine genutzt wird. Das Dokument wird während der Bearbeitungs-Session im Browser parallel auf dem InDesign Server geöffnet. Werden Inhalte nun online im Browser bearbeitet, werden die Änderungen an den Server zurückgespielt. Der Server führt diese aus, erzeugt dann eine aktualisierte Vorschau (Rendering) der veränderten Bereiche und sendet diese parallel an den Browser.
Dadurch ist keine Konvertierung oder Simulation erforderlich, um die Online-Bearbeitung zu ermöglichen. Komplexe Funktionen werden auf dem Server hoch-performant und korrekt in der nativen Anwendung berechnet. Das standverbindliche Arbeiten durch die native InDesign Engine erspart zusätzliches Korrekturlesen. Alle InDesign-spezifischen Funktionen bleiben durch die native InDesign Engine bei einer Bearbeitung erhalten – insbesondere hinsichtlich Typografie. Das InDesign Dokument kann im vollen Funktionsumfang auch nach der Online-Bearbeitung noch verwendet werden (z. B. im InDesign Desktop).
Durch selektives Rendering funktioniert serverbasiertes Editieren auch mit hoch komplexen und umfangreichen Dokumenten sogar bei voller Auflösung des Bildmaterials. Dies erlaubt u. a. auch eine sehr starke Vergrößerung von Details (1000% Zoom). Es finden nur geringe Übertragungen von Datenmengen in den Browser statt, da alle hochaufgelösten Bilder, das InDesign Dokument und die Schriften auf dem Server verweilen. Die Lösung eignet sich daher auch für eine Online-Bearbeitung von InDesign Dokumenten bei geringer Bandbreite.
Gibt es bestimmte Anforderungen, zum Beispiel an die technische Infrastruktur, die gewährleistet werden müssen?
Markus Kuhnert: Die Server-Infrastruktur muss recht performant ausgelegt sein, da ein ständiges Rendern erforderlich ist. Mit steigender Anzahl gleichzeitiger Benutzer werden auch mehr Server-Ressourcen notwendig. Aber Rechenleistung ist ja schon lange kein entscheidendes Kriterium mehr, zumal wir aus Dutzenden teils sehr komplexen und internationalen one2edit™ Implementierungen wissen, welche Server-Kapazitäten für welche Lasten erforderlich sind und wir mit unserem neuen one2edit™ auch hinsichtlich der Performance einen Riesensprung geschafft haben.
Was zählt, sind Liefergeschwindigkeit und Automatisierungsgrad. Wenn es auf Standverbindlichkeit ankommt, komplexe oder umfangreiche Dokumente zum Einsatz kommen und/oder der Erhalt InDesign-spezifischen Funktionen relevant ist, sind Editoren mit browser-basiertem Rendering ganz klar im Nachteil. Editoren mit browserbasiertem Rendering werden daher oft für einfache Drucksachen, wie z. B. Werbemittelindividualisierung im B2C (T-Shirts, Tassen etc.), Geburtstagskarten oder andere wenig komplexen Medien geeignet. Hier reicht meist eine „good enough“ Lösung. Editoren mit serverbasiertem Rendering sind immer dann gefragt, wenn keine Kompromisse hinsichtlich Funktion, Standverbindlichkeit, Komplexität und Qualität von Druck-Erzeugnissen eingegangen werden können. Typische Anwendungen sind z. B. komplexe Verpackungen, Kommunikationsmaterialien mit hohem Anspruch an Markendesign-Konformität wie Werbung, Anzeigen, Broschüren, Messe- und POS-Kommunikation, aber auch Anleitungen und technischen Dokumentationen.
