It has been over a year since I wrote a comparison of InDesign Server and Scene7 Web to Print technologies. This entire past year I’ve been asked about this every few weeks, if not every day (which was the case last week), and I continue to point to that post. I just re-read that blog post again, and I think it is still largely correct in outlining core differences between these two technologies provided by the world leader in print software for server-base document rendition to print.
I am thankful to work with both InDesign Server and Scene7 Web to Print day in and day out, both on an increasing scale. Our Silicon Designer product is rapidly becoming the tool of choice for editing documents online that render in these technologies, and we continue to watch these evolve, help them evolve, and pray that Adobe corporate doesn’t oppress Adobe engineering any further than they have in the past.
Adobe is a pendulum-swinging sort of company, turning back and forth in slow motion on directions such as acceptance/rejection of Web Standards, and I remain optimistic that the engineering-centric nature that characterized the first 20 years of Adobe will return some day and bring the company back to full health and economic stability. Meanwhile, we watch our favorite tools advance or stagnate in different dimensions depending on political climate in a business sphere far-removed from the technical.
Overall, I am optimistic. I have calculated that Adobe has 143 times the engineering staff required to make the world safe for web-to-print. Yet the game isn’t over, at a business level Adobe is at a crossroads, and the core technologies that they have succeeded with in the past are political footballs. Even if InDesign is the default application for making serious documents for print, yet we have no guarantee it won’t be destroyed by ineptitude and pure corporate politics. Same with Scene7: it is obvious that the values and criticality of these technologies are under-estimated by corporate management in this season, but equally obvious that their value will be understood over time.
If you asked me what changed with both over the past year, I would say “not much, yet both are more stable” – I think next year things may be quite different. The InDesign Server momentum is around scalability, cloud-based rendition, and DPS export, while Scene7 Web to Print momentum is around CQ integration and finishing out the feature set. Both have exciting HTML5 stories, yet it remains to be seen how these relate to the other HTML5 developments at Adobe.
We are today issuing a press release about Silicon Designer, two years after the first announcement. It has been a busy two years since we announced this as a product, yet it really has a much deeper history. Today’s release touts our recent success with multi-channel output, yet it is not that multi-channel is new to us at all, it is that we are finally doing it the right way from a single system. Let us go back to some of the early work that led to the organic productization of Silicon Designer in 2009 and the recent work that has brought us success with multi-channel, most notably email and tablet output from the same editor used for editing print documents. Finally, we’ll consider the two ways HTML5 is central to the future of Silicon Designer.
1998 was a great year. Back then, the Silicon Publishing founders were working at Bertelsmann Industry Services (now known as Arvato, a group of the Bertelsmann publishing conglomerate), in a San Francisco-based automated typesetting division (formerly Delta Electronic Publishing) that had been acquired by Bertelsmann earlier in the 90s, which had a rich 20-year history and codebase.
We were continuing the legacy work of automated typesetting, for example churning out hundreds of directories or catalogs from databases in a single pass using tools such as Xyvision. More exciting, we were leveraging the same data-generated-markup tactics that had been used for 20 years in typesetting, now to feed dynamic content to the web. We were also creating online composition applications. So the same clients that 10 years ago had hired BIS to automate the typesetting of healthcare provider directories for print could now have us build dynamic web applications from the same data (“find the Spanish-speaking OB/GYNs within 10 miles from your home”). When the list came back, we could dynamically create PDF output (“generate a personalized directory from your search results”).
We were good at dynamic web output very soon after the web came out. The reality was (and still is) that the fundamental coding central to dynamic typography is identical to the coding of web output. While there are unique characteristics to the web vs. print paradigms from a design perspective, yet the coding has more similarity than difference, and those of us with robust toolsets for dynamic markup in the mid-90s were able to do things on the web with more sophistication and flexibility than many who were new to the game. Our SGML background from working in the tech doc space didn’t hurt, either. After all, HTML was an SGML dialect.
Even back then, we were building online design tools, they were just crude, limited by the capabilities of browsers and rendition engines. Users would typically control content from HTML forms, from which they could either enter the content for a single document, or map data sources and define business rules to generate multiple documents, or single data-generated documents, from a web interface.
In 2000, we founded Silicon Publishing. The success with BIS had been too extreme, and at the peak of the dot com era things got just a bit crazy when our division was spun into a dot com unrelated to what it had been doing the previous 20 years.
We founded Silicon Publishing with no greater ambition than to continue to do what we had done at BIS… the most exciting part of which was online document generation.
Silicon Publishing was initially less capable at web-to-print than we had been at Bertelsmann. We could compose with PDF libraries, but we didn’t have a composition engine with real typography on the server such as Xyvision. We found that automating InDesign (even version 1.5) could produce stunning results offline, but it was not licensed for server. So our first years we did very separate web development from print automation in most cases. This was in some ways a step back, yet it let us focus on web and print in separate streams, as 95% of organizations still tend to do today.
We were passionate about SVG and hoped to use that as something of a web-to-print engine, yet it was an uphill battle to get either browser support for SVG from then-dominant Microsoft, or good print support from the SVG spec itself, from open source projects such as Batik and FOP, or from commercial vendors such as Adobe. In those days, Adobe was still squarely focused on the desktop. Still we prototyped online editing tools in SVG.
Our InDesign automation kept going, and we begged Adobe for an InDesign Server for years. They finally released InDesign Server in 2005 along with CS2. We were in the first group of InDesign Server resellers and we were able to take the batch composition work we’d done with desktop indesign and port it over to server.
From then on, Silicon Designer was inevitable. We got requests to build Flash or HTML front ends to InDesign Server, and we started building them one by one. By then we had totally mastered automating InDesign in terms of batch composition, yet there was some work to reconcile the graphic models of InDesign to either Flash or HTML, especially when it came to text.
BIS had instilled in us a religious belief in services. The charismatic leader of BIS in the 1990s had been a young guy named Ralf Bierfischer, and he would passionately declare that we did services, not products. I think this was instilled in my subconscious, I never considered productization until it became really obvious. “Hey, we have built the same exact application 15 times now, maybe we should consider building it as a product?”
By 2009 we had built many forms of web front end to InDesign Server, and with the Flex 4/Flash 10 text capabilities, we were really round-tripping Flash and InDesign extremely well. At this point we began building a product based on our years of experience with custom solutions. We were able to hire some amazing talent to do this, in part thanks to Adobe layoffs.
At that same time, a new form of back-end composition entered our lives: Scene7 Web to Print. While InDesign Server had the ultimate composition power one could ever dream of, it had not been built as a true server, and scaling it was (and remains) a fine art. It can be done; with enough instances/servers you can attain any level of throughput, yet the response time is not what one would write home about, even with optimization (by 2009 we mitigated this by letting all edits occur on the client and only using the server for back-end rendition for print). Scene7 was different: it started out as a very true, server-based product.
We started building Scene7 solutions and helping Adobe with the Scene7 product. We decided to have a second form of Silicon Designer, with a common front end but using Scene7 Web to Print instead of InDesign Server (or in some cases combining) on the back end. Scene7 had certain advantages over IDS in some cases: the updates to vector art were very quick, the cross-sell/up-sell capability great (because of the speed of preview); in general it is more server-like, but less finished in terms of pagination and typographic detail. I have explained the differences in fairly excruciating detail.
Still, this did not stop our work with InDesign Server at all. As I’ve explained, there are still tradeoffs, and our Silicon Designer product makes the one big Achilles heal of InDesign Server (rendition time) a non-issue, as we render everything in the client. We have gotten better and better at working with InDesign Server, and our Silicon Designer implementations are now about 50% Scene7, 50% InDesign Server. Hard to tell whether that will change over time.
We already had an XML model for documents that supported round-tripping InDesign and Flash, now we extended this same model to accommodate Scene7. 2010 was interesting, just when we had gotten Scene7 figured out, it became clear that the HTML/SVG work of our past was going to come back into relevance, thanks to the lack of momentum of Flash on mobile devices. HTML5 is still behind Flash in many ways, yet it has reached a level of maturity as a spec and support from WebKit, that we are adding it to the set of rendition translations from our core XML model.
If that were not enough work, we have recently been extending Silicon Designer into an email editor, and it really works well, far better than the direct HTML editor approach (along the lines of HTMLArea, FCKEdit, TinyMCE) that we used to take for such things. With HTML email, constraints are essential, and keeping the details of the HTML out of the hands of editors can make such a system bulletproof. It helps to work from a core model of rendition that is independent of the UI and the final output.
The future of Silicon Designer is HTML5-based in two ways… it is fast becoming an HTML5 editor, i.e. an editor that produces HTML5 as one form of output, while we are also building a version of Silicon Designer that itself is coded in HTML5. We don’t see Flash going away, it is pretty much a philosophy of “Flash where Flash goes, HTML5 where HTML5 goes” with common models for document rendition and other things that keep the document setup process and print rendition the same with the different UIs. Our core XML model for rendition is the reason for our success, and we have benefited from having to render diverse outputs over the years. It is a fun time for this technology.
We have been working hard at Scene7 Web to Print for quite some time now, seeing it come of age and deploying some serious solutions. While we started out with full-blown Silicon Designer on top of Scene7, and that remains our primary form of development, we are getting more and more opportunities for which a simple, html-based interface makes sense.
Don’t get me wrong, we love the robust online design interface of traditional Silicon Designer implementations: it is very cool to work in the browser in real time as you design things, without having to wait for updates from the server, and to work from the web in ways that used to be possible only in desktop applications. Along these lines, we continue to extend our HTML5 work, and are seeing some amazing results. But here are some reasons for simple form-based entry:
It is also true that we can, even with a form-based experience, render HTML5-based imaging on the client… yet there are numerous challenges in making this as robust as what a server-based renderer such as Scene7 can offer. And serious print from HTML5 is still a ways off.
Then when we look at server-based rendition… Scene7 is far ahead of its competition: high-quality print output with very fast composition speed, results returned to the browser fast enough to be very close to direct editing. And the fact that it is coming from the composition server, literally, ensures perfect fidelity between web and print.
With the release of Scene7 5.0 and its Web-to-print features, there are now two extremely powerful server-side rendition technologies from Adobe. Unless you are intimately familiar with these two technologies and their corresponding branches of the Adobe organization, you might assume that Adobe would develop these technologies with some concept of integration, but in truth they really are two distinct and disconnected offerings that just happen to come from the same parent company.
When Adobe bought Scene7 in May of 2007, Scene7 was a leading provider of imaging for retail web sites, known for feeding up images on demand so users could zoom in on a purse, rotate a watch with pseudo-3D technology, or see a furnished room as it would look with various selections of colors and materials in a photo-realistic way. The scalable, hosted application would serve up images in different raster formats at different resolutions based on the parameters of a URL. While it was possible to produce raster images of sufficient quality for print, they did not produce vector-based output, nor did they have a strong text engine, so Scene7 at the time was unsuitable as a complete solution for web-to-print. Rather, it would typically serve up images that would be used by other tools (server software with robust PDF output such as InDesign Server or Quark DDS) to the extent that Scene7 images became part of print output.
Meanwhile, InDesign Server was a very different sort of application, available as software that users would put on their own servers (not a hosted solution: initially the license even prohibited use within a Software as a Service or SaaS model). There was very little “server” in InDesign Server, instead the core rendition part of the desktop application was split out from the UI and handed off to the developer community with a simple SOAP interface and no job queuing: it was up to us developers to figure out how to spawn instances, queue jobs and make it produce output as fast as was possible given the slow nature of the rendition engine. In the five years of desktop product evolution, emphasis had been on attaining ultimate rendition capability more than speed of composition. InDesign Server went exponentially slower than earlier server-based composition engines, because it offered very robust features that were computation-intensive. Using the InDesign Paragraph Composer to lay out text, for example, involves analyzing the entire paragraph before deciding where to place the second character. The complexity of rendition, coupled with a lack of initial high-throughput focus, means that InDesign Server offers the ultimate in quality of output, at the expense of throughput.
Soon after Adobe bought Scene7, they embarked on adding web-to-print functionality to the product. There was some interaction with the InDesign Server group, even some involvement in Scene7 Professional Services in InDesign Server deployments, but fundamentally Scene7 went down the path of building their own web-to-print by pulling Adobe core technology into their server-based application infrastructure. They opted to base web-to-print on a new XML format that was brewing at Adobe since the Macromedia acquisition: FXG. FXG was a graphic format being built into Flash and Flex, which could be exported and imported from Illustrator; the primary motivation/use case for FXG was Flash Catalyst, which uses this model to enable powerful designer/developer workflows. The XML nature of the graphics and the integration of this XML into Flex MXML as a “native” format provide a good foundation for defining relationships between graphic objects and their behaviors in Flash applications. Notably, Flash Catalyst didn’t really require print-related functionality, so FXG did not (and still does not) include much that supports print: the color model is exclusively RGB, for example.
The first Scene7 Web-to-print release, in September of 2009, used FXG 1.0. In order to provide capabilities essential to print output that were not part of the FXG 1.0 specification, FXG was extended by a Scene7 namespace, thus “Scene7 FXG” is the core XML used to describe the high-quality print output from Scene7 Web-to-print. FXG 1.0 was put out concurrent with a wonderful new text markup language, the Text Layout Framework (TLF). Unfortunately, at the time of FXG 1.0, the TLF spec was not yet final. The text possible with the first Scene7 Web-to-print, even with S7-namespace enhancements, offered only rather crude text features. This made the first Web-to-print offering from Scene7 less than stunning for text: it was clear, however, that the core rendition functionality was solid, and there were some exciting aspects of the system from a Web-to-print standpoint:
With the first, FXG 1.0-based release, there was a core infrastructure for Web-to-print, but the application was clearly brand new, and the text capabilities were sorely lacking. Knowing that TLF 1.0, an extremely robust typographic capability, would be part of FXG 2.0, most of us in the development/partner community decided to wait for the release based on FXG 2.0. This wait turned out to be longer than expected, because FXG 2.0 itself suffered from delays in Flex 4 and what became a desire/policy of synchronizing Flex 4 with the CS5 release. Once FXG 2.0 was final, though, Scene7 was quick to make it work with the system: in parallel, what had been the Solution Accelerator was divided into an SDK and a sample application, and improvements were made to document setup and other aspects of Web-to-print based on experience with 1.0 and beta 2.0 implementations. In October 2010, the Scene7 5.0 / FXG 2.0 Web-to-print went live on all Scene7 production servers.
Now that there is a truly robust Web-to-print offering from the Scene7 group, the comparison with InDesign Server, which is at this point a well-proven rendition back end to Web-to-print, can be made. And it should be made… already in our work at Silicon Publishing, we have been in the middle of decisions over which technology to use several times. At a very high level, there is a high degree of overlapping capability, and the buzzword popular at Adobe the past couple years, “disruptive” is well-suited. Adobe is definitely competing with itself, and it is not as trivial as the PageMaker/InDesign “disruption” when you know one technology is slated for extinction: it is likely that both Scene7 and InDesign Server will continue as Adobe offerings indefinitely, and both products will continue to grow and mature. In the overall industry, these two are the leaders from a functional standpoint, as Adobe has such a huge advantage over their competition in this space. So let’s look at the differences, first in a side-by-side comparison:
|Feature||Adobe Scene7 Web-to-print||Adobe InDesign Server|
|Hosting model||Software as a Service (SaaS)||Off the Shelf Software|
|Speed||Very fast at generating PDFs and previews, suitable for real-time response to edits||Latency to generate previews, not generally suitable for real-time response to edits. Our solution with Silicon Designer is to render all edits directly in Flash, though there are challenges with this and some limitations.|
|Composition capability||Robust text, not quite as robust as InDesign but functionally quite amazing, see the core text features at the Adobe Labs TLF Demo. Still limited to core text something like InDesign 1.0: no bullets/lists built in, no tables, primitive span across pages. However, these features are also current limits of the Flash player, yet are on the roadmap for the Flash player, and there are ways to accomplish these with custom development.||Completely robust composition capability. The state of the art, with absolute fine-grained control over anything you might ever do with composition. Yet in a web-to-print context, it is difficult to round-trip those features that don’t exist in Flash.|
|Appropriate document types||Small page count, without heavy flow across pages: Business cards, brochures, letterhead, stationary, greeting cards. The scope of document type is expected to extend over time, though there has not been a clear statement from Adobe Scene7 that they have an aim for long documents.||Any type of document, though the speed of rendition can be a negative factor with very-fast throughput documents such as statements.|
|Web-enablement||Designed from the ground up to be part of a web solution: scalable, flexible, and easy to connect with other Scene7 core imaging capabilities.||This is the desktop InDesign application, put on a server, with minimal server-like features. It can work in a web context and is proven in numerous systems, yet it can mainly be considered a headless InDesign exposed to SOAP and CORBA interfaces.|
|Maturity||Brand new – only in October 2010 is there a version out with truly robust text. Indications are that it will generally work, and the Scene7 development team is the best/most responsive in the world, but there will be some inevitable iteration to reach maturity.||Completely proven: released on October 2005, numerous deployment churning out many documents worldwide. Based on the ubiquitous InDesign engine.|
|Integration with the Creative Suite||It is a one-way street into FXG from the CS application (InDesign, Illustrator, or Photoshop) in which you author your templates. There are some document features that won’t make it into FXG with fidelity, and there is no lossless round-trip back to the CS format: Illustrator imports straight FXG, with some caveats and without the S7 namespace features. Once it is in Scene7, you would generally work in Scene7 for all edits and post-processing, unless you want the ugly prospect of opening up a PDF in Illustrator or the limited straight FXG import happens to meet your needs.||Complete round-trip with InDesign desktop. Integration with other CS tools works well in terms of referenced .ai or .psd assets, but unfortunately there is no Illustrator or Photoshop server with which to accomplish robust online edits to these assets.|
|Print-centric features||“Just enough” print features, this is likely to extend as it is used in real world situations. CMYK color, PDF job options, trim and bleed settings, are all available, yet there are still some limits.||All of the robust print-centric features of InDesign.|
|Sample Application||Basic Web-to-print sample available with the Solution Accelerator SDK/Sample application: most true implementations will still require extensive development. The system is flexible and open, Scene7 chose not to prescribe much as it will be used for diverse workflows/document types.||No real example full solution: samples such as the Distributed Copy Editor have some full-scope Web-to-print implications but are outliers compared to typical web-to-print scenarios. Emphasis in the samples is on the server side of things.|
|Core rendition approach||Scene7 expects you to know in advance the structure of pages and blocks on those pages: automation is accomplished via passing FXG to the server describing a complete graphics tree for each page||InDesign Server offers complete control over the rendition, passing a script to the server which can include scripts that deal with pagination, how things flowed, etc.|
We can also look at the areas where Adobe Scene7 is ideal, or where InDesign Server is ideal. Constraints such as availability to host yourself vs. availability in a SaaS model may eliminate one or the other off the bat.
assuming that your document types are relatively small and straightforward, i.e. business cards, stationary, signage, brochures, multi-page documents in the low page-count range or where the design is not flow-intensive.
Those are the strong indicators that would push it one way or another, although there are requirements driven by workflow/UI and or document characteristics that can push it one way or another.
I will try to keep this updated, please provide feedback based on your experience, or questions that might help make this more clear. In general, both tools are very powerful, and there is something like a 70% overlap, whereby in 70% of the Web-to-print solutions we’ve encountered, either one would work, so it is likely we will work with both for the foreseeable future. Our Silicon Designer product is built to run with either Scene7 Web-to-print or InDesign Server (optionally with XMPie on top of it), and we are planning to continue to support this.
One thing to contemplate that also keeps coming up in our work: could they be combined? Yes, they definitely could… this will inevitably happen for some large organizations, but a formal connection is not currently on Adobe’s roadmap as far as we can tell. We would like to see InDesign Server offered as a SaaS component of Scene7, but have no indication this is in the cards. There is nothing like an obvious combination, you would probably see one or the other at the center of such a combined solution: Scene7 just for previews from FXG, or InDesign Server just for long documents or specific document features, that sort of thing. It really depends on what you want to accomplish. Combining the two will probably be very rare unless/until Adobe offers some appropriate bundled pricing.
We worked with Adobe a bit on their Scene7 product, and I have to say that it is some of the most promising technology out there for Web to Print. There are two big gotchas that I hope are overcome soon:
Also, it appears in their early concepts of how the app would be used, they imagined one would hit the server for the Flash renditions! I think the whole beauty of sharing the XML model between PDF and Flash is leveraging what the client can do…
Anyway, in all my years of working with great programmers, including many at Adobe, I have never seen a group as great as those working on Scene7 web to print. I am very optimistic about its future.
The fundamental beauty of the Scene7 model for web to print is that it uses the same XML to describe the web document and the print document. It also extends the XML used in Flash (FXG) to support requirements of print such as CMYK color. Tricky, as this would ideally not be done in a separate namespace, but would be part of the core FXG spec itself. In general it is awkward how the different groups at Adobe work together: they are all focused on their own short-term deliverables and can’t often reconcile or coordinate the overlapping parts of their efforts.
Which brings us to… InDesign Server. One might have guessed that Scene7 would use InDesign Server rather than build their own form of PDF generation totally independent, with a different text engine (common with Illustrator/Flash, not InDesign) and different XML model (FXG vs. IDML). Sadly, the InDesign project does represent the ultimate in text engines, the ultimate in document feature sets for long documents, etc., but there has not been a desire to use it from the Scene7 group. They didn’t find it much of a true server product, apparently, which is quite understandable. The “server” dimension of IDS is minimalist, it is essentially the rendition half of the desktop product with a few hooks and enough “build it yourself” aspects that solution providers like us have a fairly endless stream of opportunity.
So Scene7 will hopefully become a big part of our work next year, assuming the 2 issues above are handled, yet InDesign Server will remain, especially for longer documents and those cases where extending a desktop InDesign workflow to the server is easier when avoiding issues around reconciling text and layout engines. We don’t really mind two systems, but some day I’m sure we’ll hit a hybrid case where we use both, and in some long-term road map (CS7?) they should actually get reconciled.
Adobe product managers have managed to calm down my early complaints about non-reconciliation of these two engines. One pointed out the incredible backwards compatibility responsibilities of IDS: they can’t just start over… one tiny bug in one tiny dot release can screw up a million documents for a client, they are not as agile as a SaaS shop.
In terms of SaaS; as of now, Scene7 is almost only SaaS and IDS is almost only self-hosted. It is likely that both products will cross over the other direction. We can host IDS in an EC2 environment just fine, with great scalability, yet the licensing is not SaaS friendly. In similar fashion, Scene7 can install just fine as a self-hosted software, yet they only allow this in “special” situations and tend to push for SaaS at all costs.