There are lots of web-to-print and web-to-web solutions out there. Why do we think ours is the best? Here’s some insights into our philosophy that went into creating our solution.
We chose to use InDesign Server as our rending engine for a number of reasons. The two most important reasons being workflow and reliability. By workflow I mean that we feel that creators of templates should have 100% freedom of design. InDesign is by far the most popular application for page layout and we wanted to allow designers the freedom to use the many features available in InDesign when creating templates. By using InDesign Server, all features available in InDesign Desktop are properly preserved on the server side. This allows a seamless workflow for the template designers and existing documents can be used as templates in the PrintUI system with minimum effort.
We believe that features should automatically just work as expected. Some examples of this are: Changing text frame alignment (i.e. bottom align) will automatically change the behavior in the web app. If you want to prevent movement or rotation of an element, just lock it in InDesign, and it will be locked in the web app. And the list goes on.
Workflow is so important to us that we went so far as to create a panel within InDesign for all management tasks related to templates. The template designer can upload templates and fonts and see all assets uploaded to the system without ever leaving InDesign.
Preflighting of documents is done within InDesign as well, and the designer has the option to fix many preflight problems automatically.
However, workflow is only half the picture. Reliability and quality are just as important. There is no output engine available better than InDesign. PDF documents are output using Adobe’s PDF Print Engine. All transparencies are correctly maintained. Color management is properly handled. PDF layers can be used. If interactive output is needed, that is possible as well. The list goes on. There’s many inexpensive pdf rendering engines out there, but we’ve heard from people who’ve tried them, that you will just be burned if you try to go that route. InDesign is a tried true — well tested publishing platform, and of course PDF is just one of many of its output capabilities.
One of our primary concerns while developing our system was a focus on performance. One of the concerns with using InDesign Server (or any server-side technology for that matter) is latency and performance issues. Text processing on the server side can take measurable amounts of time, and when multiplied by thousands of users, that could add up to a serious concern. Even if multiple users would not be a concern, latency definitely would be. We have users from around the world, and constant pauses while working is unacceptable.
Many web to print solutions out there take the easy way out and do most of the rendering on the server side. Besides bottle-necking, this has two major issues:
- You cannot continue to use the app if you are temporarily disconnected from the internet.
- More importantly, there will always be a lag while working.
Our approach was to handle all the preliminary rendering on the client side. This results in a very responsive app, and greatly reduced server communication. This means that latency issues more or less disappear, and our working load on the server is greatly increased.
The actual end-rendering is all done by InDesign Server, but the intermediate rendering while working is all done on the user’s computer. This results in a very elegant system.
Of course the flip-side of this, is we had to write a web-based “mini InDesign” from scratch…
Rendering must be 99.99% faithful to the output.
The single most important factor when developing a WYSIWYG app is the you actually get what you see.
There are lots of issues involved in creating a rendering engine for documents as complex as InDesign. There are native objects, linked graphic files, color issues, font issues, etc. In my mind, the single biggest issue is text.
InDesign has a very sophisticated text rendering engine. One of the biggest challenges when creating an app with faithful rendering was rendering the text true to what you will get in InDesign.
After more than a year of working on our APIs and web app, we are very happy with the results! We achieved incredible rendering parity between our web app and InDesign, and we are achieving more and more feature parity all the time.
I’ll try to cover more of the technological concerns we’ve faced and our future focus in another blog post.