I recently participated in a presentation at Dscoop Phoenix with three companies that I’ve known for over a decade: Pageflex, XMPie, and Marcom Central. We had joined a “Composition Engine Panel Discussion” with web-to-print luminaries Jen Matt (of web2printexperts.com) and Chris Reisz-Hanson.
It was quite an honor to be on this panel, but an even greater honor has been the opportunity to work with these companies’ rendition technologies since they first came on the scene. I have been involved in solutions involving all four technologies, and I’ve met the developers critical to the success of the underlying rendition codebases. These range from: FusionPro, the composition engine under Marcom, which dates from the 1980s; to PageFlex, the PDF rendition library from BitStream also originating in the 1980s; to InDesign, dating from the late 1990s. InDesign is the engine that we and XMPie use – it was created in part by our staff.
I was happy that Jen went for the “composition engine” topic because although we all dabble in other things, it is primarily our strengths in composition-related work that hold the greatest interest for an enterprise company these days.
Look at the complete picture of our respective offerings:
Jen focused on the common web-to-print functionality that we all provide. I understand why the other companies want to serve smaller printers a “complete solution”, but competing with shopping carts or web/email publishing technologies is not a reasonable goal for us, as we build the largest solutions for the largest companies. Instead of going into tangents dominated by multi-billion dollar organizations like Adobe, we integrate with Adobe, Oracle, Salesforce, etc., for their shopping carts and non-print communication channels, rather than focusing our finite and specialized resources on development in these orthogonal domains.
This is an age of APIs. While Pageflex, XMPie, and Marcom Central may have starting-point offerings in shopping carts and web/email communication, they seem fairly basic and printer-centric. Print output, to me, is the channel in which all of us have by far the most relevance. Certainly Adobe/Oracle/Salesforce/etc. do the carts and Marketing Cloud functionality on a far larger scale, though none of them are as substantive with server-based page rendering for print (other than Adobe, which created InDesign Server but left it to companies such as XMPie and Silicon Publishing to actually make it work in a Web-to-Print context).
Variable Data Publishing (VDP) and Online Editing are the things that we four do best. These both require a high-quality page composition engine. Let’s consider the four platforms in terms of our core composition engines for print output (for either VDP or online editing).
The composition engine is a very significant dimension of any solution, and among the four of us, we have 3 main composition engines. As mentioned above, PageFlex has a PDF library approach, Marcom Central relies on the FusionPro engine, while both XMPie and Silicon Publishing are primarily based on Adobe InDesign Server.
Pageflex dates back to the early days of electronic publishing, and was originally spawned by Bitstream, a font company that created the Pageflex product. It has since changed hands, but the composition engine hasn’t changed much recently. PDF remains the primary output of Pageflex, and although Pageflex documents may start out in Quark or InDesign, neither Quark nor InDesign are used for rendition. Instead, a proprietary engine composes documents: once you’ve set up a template, you’ve left the rendition engine you started with.
Pageflex is well known for the “flex” functionality it provides. This can be extremely valuable when working with advertisements, which are probably the most frequently resized types of documents. Pageflex has robust tools for setting up documents to contract or expand intelligently. The core rendition engine, however, is fairly PDF-centric, which means that it doesn’t go as far as the Quark or InDesign engines with respect to robust typography. In similar fashion to our SDXML or XMPie’s XLIM document models, Pageflex documents have an XML document format that renders directly with the Pageflex composition engine (to PDF or printer-friendly formats like PPML and VIPP). I have seen adept developers modify this XML to inject data and graphics, which is but one approach to extending this well-thought-out and well-established product.
The composition engine underneath Marcom Central also dates back to the 1980s, and shares technology with Adobe FrameMaker. Currently owned by Ricoh, Marcom Central was once known as Printable (later PTI), which acquired the “DL Formatter” software from DataLogics (which itself goes back to the 1960s). I remember DL Formatter from Seybold conferences in the 1990s: in the early 2000s it was re-named “FusionPro”.
FusionPro is still based on that 1980s-vintage composition engine. Under the hood, it shares much with FrameMaker (not surprising, since at one point DataLogics was owned by Frame Technology Corp). I worked with FusionPro in the early 2000s, before InDesign had a server version, and noticed a few commonalities with FrameMaker.
There are both desktop and server forms of FusionPro, and it provides a methodology for starting with PDF and overlaying variables. Beyond the core variable model, scripting as well as a deeper API layer allow for some very refined control.
With FusionPro, as with PageFlex, native InDesign or Quark files can be used as starting points for templates, but neither the InDesign nor the Quark engines render variable content. FusionPro also has plugins for Acrobat that can set a PDF as the starting point for a template. Variable content is rendered within the very Frame-like text engine.
XMPie did not create or acquire their own rendition engine, but instead used Adobe InDesign Server from the beginning. Just like us, they were part of the launch of InDesign Server in 2005, and have remained with that product ever since.
XMPie was a pioneer in flashy, high-color one-to-one marketing, and we built many XMPie solutions when it first came out. It works great for a mail house designer tasked with making a campaign from an arbitrary new set of data, as the XMPie platform included a data-mapping tool and a nice InDesign plugin, letting a user drag variables from the data set into their InDesign documents. XMPie showed off the power of the InDesign engine by swapping layers, implementing dynamic text on a path, and generally exploiting the powerful advances in typography and layout that the engine offered. I have written elsewhere of the power of the InDesign product.
XMPie offers InDesign Server under a unique OEM license that limits the number of core processors (unlike the IDS license of today), which also mandates that InDesign Server is not used directly, but instead must be triggered by the XMPie plugins and/or server infrastructure. Despite these limitations, XMPie offers the InDesign engine completely end-to-end, from the templates that are set up in InDesign, to the dynamic text that is flowed out by the InDesign text engine.
Like XMPie, we didn’t see any reason to re-invent Adobe InDesign, which we consider the greatest software product of all time. Our VDP product (Campaign Paginator) and our online editor (Silicon Designer) are based directly on the Adobe InDesign Server product and are intentionally very loosely coupled. When you buy Designer or Paginator, you must also buy InDesign Server, but under the generic Adobe license, meaning that you could also (theoretically) use InDesign Server for many other things.
Our solutions enable extensibility directly through Adobe ExtendScript, without a rigid requirement to adhere to our specific data-binding models or job processing infrastructure. When we worked with XMPie, we found that it made things easy at the outset, but was less than extensible when you ventured beyond the “mail merge” type of document. We are happy that raw InDesign Server is available directly to our clients/partners, because it allows them to extend our solutions without restrictions imposed by our products.
The composition engines solve the challenge of “how do you make print output?” at a fairly low level. At a higher level, all four approaches provide solutions for binding rendition to data sources and rendering from an online editing experience. They also manage the infrastructure around job management and system administration.
The approach to variables is different, but all four solutions make it easy for end-users to set up templates that are ready to ingest data and flow out final rendition. Each provides tools for desktop template creation (primarily InDesign, but Marcom Central also offers PDF as a starting point), and they all manage server-based rendition of output designed online, or output resulting from processing variable data.
As I’ve discussed elsewhere, Silicon Designer is based on an XML document model called “SDXML”. I know that XMPie has a model they call “XLIM”, which is used to round trip with the web in their uEdit product. If you wish to render between HTML5 and a print format such as InDesign, you’ll have to take a similar approach. In our cases, we’ve invested many person years in reconciling web and mobile text with the text of Adobe InDesign, and we now enjoy extremely accurate round trip processing.
As I’ve explained in a previous post, our Silicon Designer client application is extremely extensible via web standards. You will not find any two Silicon Designers that look the same, as we are primarily a white-label offering, and make it extremely easy for our clients to customize the editing interface themselves.
When it comes to variable data, I believe that we handle the broadest range of document types within these four companies. XMPie, Pageflex, and Marcom Central are natural for the variable data associated with direct mail and marketing campaigns, but are far less suitable for catalogs, directories, long flowing documents with cross-references, etc. With our background in these more complex document types, we offer text flows with in-flow continued heads, for example, something which is impossible for the other tools to achieve.
With any product like this, there is some balance between constraint and freedom, and it is only through constraint that you can make a “plug and play, one size fits all” product that hits the sweet spot of certain use cases. We don’t pretend that our “most flexible, most extensible” solution is right for everyone. Yet that is where we are in this space. There is certainly room for all of us and more in this business, and it is always fun to see this technology evolve.