Publishing solutions


INTERVIEW

The key to publishing and media management solutions


In digital publishing and media management solutions, there are two fundamentally different technological approaches to editing InDesign documents. BRANDGUARDIAN follows the server-based approach with one2edit™. Why is that? And what are the advantages over browser-based editing and rendering? Markus Kuhnert, founder and managing director of BRANDGUARDIAN explains the background in an interview.


You created the basis of one2edit™ more than 20 years ago and have remained true to the server-based approach. There are some solutions on the market like Silicon Publish, 2Imagine, Chili Publish or CI Book that rely on browser-based editing and rendering. What are the differences?

Markus Kuhnert: Rendering, i.e. the creation of a preview of the Adobe InDesign document, is the basis for publishing and media management solutions. If editing takes place in the browser, InDesign functions, document geometry, formats, content and fonts must be assigned between the InDesign document (via an InDesign engine, see below) and the online document (in the browser). The Adobe InDesign document is read so that geometry, formats etc. can then be simulated or reproduced online in the browser in an editor. After the online editing, the changed contents are fed back into the InDesign via the mapping or output via a proprietary engine, e.g. as a PDF.


So there is a conversion taking place, isn’t there?

Markus Kuhnert: Partially. There are three ways to read out the functions, geometry, formats and contents of the InDesign document. With the native InDesign format, this can be done server-based via the Adobe InDesign Server or via a plug-in for Adobe InDesign Desktop. Adobe InDesign Server and InDesign Desktop use the identical render engine. Alternatively, instead of a native InDesign document, the InDesign exchange format IDML (InDesign Markup Language) can be used, which is an XML-based representation of the InDesign document. However, this IDML format must be created with an InDesign engine (desktop or server) and is not itself a native InDesign format, but a conversion. Conversely, the use of an InDesign server does not automatically guarantee stand-alone binding or full support of all InDesign functions in the browser.


Why is that?

Markus Kuhnert: In order to reproduce the InDesign document as accurately as possible in a browser-based editor, all InDesign-specific functions must be simulated online. Otherwise, there will be restrictions in terms of function and WYSIWYG-editing (what you see is what you get). However, many of these functions are patented and may not be reproduced or their technical implementation is not known (no public domain). The representation in the browser is therefore severely limited in terms of typography and design functions compared to InDesign. For example, CSS (Cascading Style Sheets describes the presentation of an HTML or XML document) supports only a fraction of the typography functions of InDesign.  And also the implementation of certain functions in the browser is only possible with great difficulty or not at all. InDesign functions are developed in C++, highly optimised, compiled and run natively and thus also with high performance on the system. A browser, on the other hand, is limited to Javascript. Javascript functions must be compiled when they are executed and are not run natively, but in a virtual machine. This requires even more power from the operating system. In comparison, a function in C++ therefore only requires a fraction of the processing time of a comparable Javascript function. 


Can you give an example?

Markus Kuhnert: Let's take the overset function: while an overset check in InDesign is carried out in a fraction of a second with every keystroke or change in formatting, even for complex documents, a calculation via Javascript (i.e. in the browser) can take quite a few minutes. 

Another challenge is the precise mapping of typography and the use of fonts. The fonts have to be converted for display. This is usually legally problematic. Alternatively, fonts can be assigned with a web font. However, these have a different structure, sometimes different kerning and require additional licensing. With one2edit™, on the other hand, users have a central font management for the InDesign server at their disposal: all one2edit™ users can thus use the same fonts and no fonts have to be installed on the user computer for editing InDesign documents via the browser.  The central administration of the fonts ensures legal security, a uniform typeface in the brand design (typography) and, on top of that, usually saves on licensing costs.

But let's get back to the disadvantages of the other solutions: Since the InDesign document in the browser is only a simulation, editing in the browser is not a WYSIWYG-editing and requires additional proofreading of the output document. This results in a higher coordination effort in the production process. Nobody wants that. With a digital publishing and media management solution, you want to significantly reduce the effort, increase the KPIs and increase the degree of automation. This is difficult on a browser basis for the reasons mentioned. And there is another point: marketing departments and agencies are working with ever larger amounts of data and, due to Corona, they are also working in an increasingly distributed manner. Transferring large amounts of data to the browser, especially image data, fonts and large documents, is critical. A 120 MB InDesign document with gigabyte-sized image data cannot be loaded into the browser with high performance.


But there are surely also advantages?

Markus Kuhnert: The biggest advantage of browser-based editing and rendering is the fast feedback on user input. This is possible because inputs do not first have to be sent to the server for calculation and rendering, but are carried out directly by the browser document simulation. It also means that the demands on the server infrastructure are extremely low.

But the disadvantages outweigh the advantages and are easy to understand in practice: Consider complex and/or extensive documents with InDesign-specific functions such as anchored objects, inline graphics, concatenated text frames over several pages, microtypography, optical margin balancing, etc., and try to display and edit them browser-based. Failure is inevitable here.

Or even with large amounts of text, there are usually already differences in line breaks. The native InDesign document, the online simulation in the browser and the output document show differences, which only confuses the editor or the client unnecessarily.


Let's come to server-based editing and rendering with one2edit™. What are the advantages and disadvantages?

Markus Kuhnert: As the name suggests, the rendering of the InDesign document takes place on the server during editing. The view in the browser thus corresponds 1:1 to the Adobe InDesign Desktop/Server, as the Adobe InDesign Engine is used here. The document is opened in parallel on the InDesign server during the editing session in the browser. If content is now edited online in the browser, the changes are sent back to the server. The server executes them, then creates an updated preview (rendering) of the changed areas and sends it to the browser in parallel. 

This means that no conversion or simulation is required to enable online editing. Complex functions are calculated on the server in a high-performance and correct way in the native application. The use of the native InDesign engine saves additional proofreading. All InDesign-specific functions are retained by the native InDesign Engine during editing - especially with regard to typography. The InDesign document can still be used with its full range of functions after online editing (e.g. in InDesign Desktop). Through selective rendering, server-based editing also works with highly complex and extensive documents even at full resolution of the image material. This allows, among other things, a very high magnification of details (1000% zoom). Only small amounts of data are transferred to the browser, as all high-resolution images, the InDesign document and the fonts remain on the server. The solution is therefore also suitable for online editing of InDesign documents with low bandwidth.


Are there certain requirements, for example on the technical infrastructure, that must be ensured?

Markus Kuhnert: The server infrastructure must be designed to be quite performant, as constant rendering is required. As the number of simultaneous users increases, more server resources become necessary. But computing power has not been a decisive criterion for a long time, especially since we know from dozens of partly very complex and international one2edit™ implementations which server capacities are required for which loads and we have also made a giant leap with our new one2edit™ in terms of performance. 

What counts is delivery speed and the degree of automation. When it comes to stand-alone accuracy, when complex or extensive documents are used and/or when the preservation of InDesign-specific functions is relevant, editors with browser-based rendering are clearly at a disadvantage. Browser-based editors are therefore often used for simple printed products, such as individualised advertising materials in B2C (T-shirts, mugs, etc.), birthday cards or other less complex media. Here, a "good enough" solution is usually sufficient. Server-based editors are always in demand when no compromises can be made in terms of function, complexity and quality of print products. Typical applications are, for example, complex packaging, communication materials with high demands on brand design conformity such as advertisements, ads, brochures, trade fair and POS communication, but also instructions and technical documentation.