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.
Here at MAX for the 5th year in a row – I didn’t go to these until Adobe bought Macromedia and it has been very interesting to see the changes over the past 5 years.
Keynote – Kevin Lynch started in with discussion technology trends, then moved into presentation of the Digital Publishing features. Wired magazine was presented, and really didn’t show much different than what we’ve seen already. They seem to have reacted to some of the initial bashing. They showed dynamic text wrapping in HTML, identical to SVG text wrapping demos from 10 years ago. Not exactly thrilling, though they do say they are contributing to WebKit. He presented the Adobe Digital Publishing Suite, starting from InDesign, collaboratively produced and distributed, and of course they want to use Omniture to analyze the results. It is quite a stretch to think they will do the full-cycle at all as well as they have built the low-level tools.
Kevin spoke of video… quite an awesome amount of video going out in Flash, but unlike last year they are not showing the trend towards ubiquity, but rather “most video on the web is still shown in Flash.” Flash 10.1 was very quickly adopted, apparently, yet we know where it did not show up. Internet television keeps advancing, and Flash does have quite a head start there: the streaming is really impressive. AIR for TV is out; first launch partner is Samsung. Marc Goldberg of Epix spoke of multi-screen, saying their subscribers watch on a number of different screens: the demo broke, however.
Flash Media Server is working on on-the-fly encoding. Wowza seems to have made some real inroads, based on discussion with some attendees. P2P-assisted video looks kind of cool.
Kevin showed a number of small apps built targeting the tablet computing environment… it would appear they are rewriting things to be more lightweight. He demo’d a table device / PC wireless app, where the iPad served as a palette for a user in Photoshop.
He spoke of the enterprise… the impact of multi-screen, as well as LiveCycle. He mentioned the Day Software acquisition, which we have been watching with eager anticipation at Silicon Publishing, and brought their CTO David Nüscheler to present.
David Nüscheler from Day spoke of the need for discrete control of how things work across devices: he explained that the communications are truly different, it is not as trivial as spewing forth variants of the same thing entirely, but there is a true need to have some separate content specifically targeted. David demo’d CQ5, showing editing of HTML and mobile content. He did not dwell on the DAM, which has been our primary interest in Day. We are in the midst of a very exciting integration with the Day DAM, and so far we have been extremely impressed with the DAM aspects of Day. Adobe has done several acquisitions really well, and even though it’s the LiveCycle group that they are subsumed into, we are optimistic they will take over appropriate leadership roles. Wouldn’t it be cool if we can connect the rendition power of Adobe to structured information in LiveCycle? We have witnessed a long and pathetic history of the Acrobat monopoly being squandered on silo-based random junk (Central Output Pro? Graphics Server? Document Server? Forms with dirt-crude formatting?…) for rendition, yet there is good security and DRM in LiveCycle, hopefully the Day team will gut it and connect appropriately to the rendition side of Adobe (Flash, After Effects, InDesign desktop and Server, and above all… Scene7).
Day does introduce a real philosophical paradox. After the keynote, they presented content that had probably mainly been presented before, starting with a 45-minute argument for Open Source. LiveCycle has traditionally been the precise opposite of Open Source, and just the day before at the leadership summit we had heard that the “open source” Flex project had approximately 0 contributions from anybody but Adobe: will Day change this? It will be interesting. It was sort of strange to hear conway’s law cited and consider what that would mean as the organization is not the Apache Foundation any more, it is Adobe. We will see some interesting software!
Kevin demo’d medical imaging technology. Flex really does create powerful front ends for enterprise apps. Flex 4.5 beta is out, I am not sure after the year of Flex 4 beta lifestyle how deeply we will want to dive in. Back then we really needed the TLF badly, so it was probably worth the rush, I think with future Flex betas we can build a bit less production code on top of it.
Mike Lazaridis, CEO of RIM, came on and showed the Blackberry Playbook. Adobe and RIM have been working together with Flash/AIR; fairly obvious that Apple motivates them. “Not trying to dumb down the internet for a mobile device” – NICE stab at Apple. That was, as the 2 of you who read this blog know, my big reaction to the iPad.
Kevin showed some cool games, rendition gets faster over time with more use of the GPU, and AIR is evolving. AIR for Android looks good, Apple has some good competition, hopefully. Deploying from Flash to iPhone OS is once again possible, too.
Social gaming has always been one of Kevin’s interests: he showed the work idol worship, a nice-looking virtual reality game that uses old school animation techniques coupled with slightly newer technologies. He showed some very cool GPU-accelerated 3D capabilities of other games. Flash is really getting nice: the virtual reality driving demo was compelling. With the next Flash 3D, code named Molehill, the immersive 3D graphics should be very good for games and general 3D imaging.
Chrysty Wyatt from Motorola came on to speak of Android and the request of Motorola to put Flash on mobile devices – “anyone who fails to put Flash on a mobile device is not giving you the Internet.” And they are not above bribing us – all attendees at MAX are getting a Droid 2.
..Should be a revolution for web-to-print applications. I would imagine that Facebook will further consolidate its control over the Social Media space. A bit scary that such critical mass factors leave MySpace, Friendster, etc. fairly dead in the water…. people want to go to where their friends are. And it appears more and more digital assets will reside in Facebook as well. I imagine that applications like fidipidi will get more popular as the quality of output from Facebook to print gets better.
I saw the feature yesterday, but it seems to have been turned off today. Maybe this has caught on? Today, I uploaded a 1936 × 2592 image, and as usual Facebook reduced it to 538 × 720.
Hardly conducive to high quality print, though I have been impressed that even with resolution along those lines, the cards from fidipidi have looked pretty great.
As soon as Facebook turns this feature back on, I will make a high resolution card using fidipidi and report the results.