Publishing with Silicon

Today Steve Jobs called Adobe “Lazy.”

Flash has dramatically improved since Adobe bought Macromedia. Papervision 3D is a 3D engine that runs on Actionscript, this sort of capability was unheard of back when Macromedia ran Flash. 

Flash is spreading all over the place: set top boxes, TVs, phones, everywhere except the iPhone. It is ubiquitous for ads and video on the web. No wonder Steve is jealous. What is the install base of Quicktime?

Flash runs fine on every other phone. Is the iPhone buggy? no, it is intentionally dumbed down in the interest of rabid monopolistic tendencies of one eccentric genius.

Steve should remember that Apple would have died save for its use as a graphics platform running Adobe technology for a long stretch of time.

The iPhone will be a better device when it supports Flash.

It will be great when Steve retires… as much as he has done for the company and the world, he really has conquered everything that needed conquering; the world needs a little less conquering and fewer dumbed-down, closed-source, “no VM allowed” systems like the iPhone and iPad.

With the iPad we witness the first case in history of computing where the limitations of a small device float upwards into a bigger device, instead of the opposite (remember when Moore’s law was a good thing?): who is lazy???

Frustrating that the iPad seems to inherit more from the iPod than from laptops… I really think that’s less than desirable and I will probably not bother with it. I spent years lugging around 17″ laptops… my 15″ macbook pro feels portable enough. As far as Apple innovation, I am hoping for a Mac Pro that is smaller than a tank.

I would hope that big computing would flow into smaller devices, rather than the limitations of small devices flow up into larger ones, as seems to be the case with the iPad.

Of course I am unhappy that they would not support Flash on the iPad, if that is the case (a bit unclear from news today). There could be no performance excuse, as they had with the iPhone initially. It is funny how Adobe and Apple have oscillated between being friends and rivals: at several points Adobe software seemed to keep the Mac afloat. Now that Flash is a very powerful VM, and AIR can function almost like an OS, it is no wonder there is some rivalry. But kicking Flash out of the iPod was short-sighted, kicking it (and other laptop-level features) out of tablets would be self-destructive.

I was on the phone with a prospective client today, who shall remain nameless and unidentifiable. This could be any company, as they face the essential predicament of anyone trying to get the same content to go to both web and print effectively.

On the one hand, there is so much commonality and re-use of their content across the web and print media, it is absurd to have two entirely different workflows. On the other hand, the tools that lend themselves to a real multi-channel workflow, such as real XML content management, take extreme effort and time to implement and often have expensive associated software. Even after that effort, authors or content sources may not fit in with the required content process at all. Beyond that, moving content over from an unstructured to a structured format can be really difficult.

Inevitably, XML demonstrations make business users underestimate the challenge. “If you show us something, show us with our content!,” he said; evidently they were shown a rosy picture where perfectly marked up XML flowed easily out into web, print, braille, video, whatever. It is true; if you have rich semantic markup the publishing capabilities are amazing.

The challenge is getting that richly marked up content. It is hardly automatic. The extreme best case for authoring such content is the world of technical documentation, where the authors are typically really technical, and highly-evolved schemas/toolchains like DITA give them guidance on how to structure content. But at the other extreme, with writers who are non-technical, it is hard to get them to work with tools that are too constraining, or to get them to follow rigorous guidelines. No pain, no gain:  without the rich markup, publishing becomes more of a channel-by-channel basis.

I believe over time things will get easier, with standards like DITA, greater support for XML authoring in tools, and better example workflows for organizations smaller than the Department of Defense. But the pace of such improvement is slow.

We have built solutions using InDesign Server since it came out, and before that we were building solutions based on InDesign desktop for 5 years. So we know the XMPie space pretty well.

XMPie is a really well-built program, that to me has three main benefits:

1. It lets you easily define a data source for variable content (using uPlan) and reference that data source directly in InDesign (via uCreate)
2. It manages XMPie jobs (via the uProduce server), with functionality exposed as Web Services
3. It optimizes print output, producing VPS (which has been known to work), PPML, “VIPP” (which is known not to work; it is not VIPP but a VIPP wrapper around PostScript), etc.

XMPie is salvation for the designer at a mail house: they can bypass Programming entirely and set up their own “campaign” based on new InDesign/data input from a client.

Yet these days, we never meet such a designer. We meet enterprise clients, who consider themselves very special and do things a very special way. XMPie invariably meets their needs 40-80% of the way, but the other 20-60% can take a supreme effort. So we need to request extensibility from XMPie, and in many case fuse together an XMPie workflow with a very non-XMPie workflow. They may be sick of my requests, but they have given us more and more extensibility over time.

InDesign Server has to its advantage complete flexibility, but if you use InDesign Server alone you have to build several features that are pre-existing with XMPie. It really depends on specific workflows/document types/staff whether XMPie is the right fit.

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:

1. The text that is possible with Flash 10 is not fully functional: this stands to improve once FXG 2.0 is available, the hope is that FXG 2.0 will be fully supported. As of now the text is more like FXG 1+, it isn’t quite robust enough for our typical clients.
2. The pricing model is crazy. I think they priced it so high that they would make sure not to get slammed with too many initial implementations. $50K/year as a base price with multiple forms of transaction/bandwidth costs on top of that is hardly a SaaS model. You either pay as you go or you pay up front, they can’t ask for both…

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…

Demonstration of the Scene7 web-to-print solution

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.

I just set up a basic WordPress blog for Paris Tompkins. This took only a few minutes’ spare time, including the hosting, DNS, customization. She chose the theme herself; I just made the side look OK and added the vital “Add to Any” plugin.

I still barely know WordPress, but I have had almost no trouble with any aspect of it recently: I played around with various blogging software about 8 years ago, and it was nowhere near this easy. I have only had to do something with PHP within a WordPress site once, and probably because of the nature of the template.

I am an impatient person and I will never be content with the pace of publishing technology, but I have to say that when you look back to where the web was in 1996 and where it is today, it has generally gone the right direction. Well, that is after starting out with a fairly complete misinterpretation.

Proposal for the World Wide Web

The original concept was of course brilliant, and you should check out the proposal for the web if you haven’t already. Basically, the intent of the web was to facilitate two-way communication, but of course the mindset of a Television-soaked population at first thought of it more like a single-direction, one-to-many, broadcast medium. We only understand things in relation to what we’ve seen before, at least at first.

So the Web started out with much knee-jerk reproduction of the Television model, and only with the gradual evolution of blogging and social networking (and concurrent evolution of tools for this) has it become really easy for a person like Paris to get out there and express herself. Now even the large corporations are hyping Facebook and Twitter, with their own YouTube channels and real estate in SecondLife. I think Paris will fare better than most corporations, because the playing field is leveled.

Adobe has finally defined an XML format for Flash, something those of us in the SVG World have long waited for. Well, we weren’t waiting for Flash, it was an XML server-based description of interactive graphics, but who’s counting?

Now that we have XFL and FLA renaming it, can we get a server? I really look forward to this but it remains completely unannounced.

I was wondering why a dirt-simple InDesign file packaged to 6 Meg… and I discovered that the images were about 1 Meg each. I had created very simple images, colored rectangles in Illustrator CS4 and saved as straight .ai files with default settings.

Amazing, what valuable info is it persisting that makes this the right size for a primitive image? When I export as SVG I get 6 lines of code, which look verbose already, but way tiny by compare…

Does anyone remember the quote attributed to Bill Gates that PCs would never need more than 640k of memory? Poor Bill could only see the lower 2/3rds of this rectangle with the dream computer of his age. The only thing more amazing than the continuous exponential increases in memory, disk space, and bandwidth is the way such improvements are consumed by new applications the moment they are available.

At the Adobe MAX 2009 conference, one of the coolest sessions I attended was “Creating an eBook for Distribution on Sony Reader Digital Book, Amazon Kindle, and Apple iPhone” by Colin Fleming. The recording is online, among the many sessions available through the MAX 2009 Conference Scheduler. Colin’s blog post on the subject includes sample files.

Now this is quite cool, given a manual workflow. Just one problem… our company never wants to do anything manually, we want to automate everything. So on the surface, it appeared that we could probably just do this using InDesign Server, at least the export to Digital Editions. However, no such luck.

It turns out that the feature to export to Digital Editions, which does most of the work, is implemented via JavaScript. This piece of InDesign is in the Scripts > XHTML For Digital Editions folder, and it is compiled JavaScript, the wonderful jsxbin format that lets one distribute scripts without letting users view source or know what parameters the script expects.

Therefore, in order to automate this, one would have to guess the parameters to pass to the scripts. No documentation, and no source for the scripts, is yet available from Adobe. Why did they even put these scripts into the InDesign Server application? It is only usable from the desktop application, and only from the UI.

Olav Kvern was quick to tell me that he will help correct this problem. I look forward to seeing either source for the scripts or at least documentation on how to run them from code. Then we will be half way there in fully automating conversion to Kindle: of course the setup of source InDesign documents is important, too.

The other half is figuring out how to automate the step that Calibre takes care of in the process. At least that is open source.

I am thrilled that Adobe builds parts of InDesign with scripting: we have long maintained that scripting should be a first-class citizen with C++, and this proves our point. But they should not abandon the extensibility and complete exposure to automation that make InDesign and InDesign Server the first-class tools that they are.

I noticed that the draft FXG 2.0 Specification is finally online. It appears that this will be the form of FXG implemented in CS5.

I have been interested in, and somewhat connected to, Adobe’s approach to XML for quite some time. In the mid 1990s, FrameMaker supported SGML prior to the birth of XML. In 2000, Silicon Publishing worked with Adobe in publicizing FrameMaker 6.5 as an XML-capable tool, though FrameMaker+SGML only worked with XML in a very cumbersome, awkward way.

I will never forget our first project for Adobe, which was one of the very first Silicon Publishing projects. One Friday in 2000 I went to meet Doug Yagaloff, the publishing genius that led Caxton, and he gave me a copy of Frame+SGML and said I just had to do one simple thing. Import an XML document, and export it back out. That was a long weekend! I felt like I must be very stupid, it took me forever to get anywhere at all. Thankfully, Sunday night I found a “quick guide” online which exemplifies the great patience that is generally characteristic of those working with SGML and document-centric XML. I was able to show Doug an example the following Monday – “it’s hard, isn’t it?” he smiled.

We worked with Adobe on the FrameMaker 7.0 release, which dramatically improved the XML support. Later we put DITA support into FrameMaker for Adobe, which now gives a real head start when working with document-centric XML. I am a strong believer in DITA.

That is the core, semantic XML that SGML was oriented around at its foundation. InDesign got some bare-bones support for semantic XML with 2.0, but it goes nowhere as deep as the support of real XML authoring tools. Probably more interesting in terms of Adobe technology (they bought FrameMaker but it stands outside of their main product offerings) is rendition XML, and here was an area more exciting to us at Silicon Publishing.

Rendition XML

In 1998, when I was still at Bertelsmann, one of our former employees who had moved on to Adobe told me about a very exciting new XML specification: PGML. This made great sense to me, and I was an early enthusiast. It was not long before the PGML effort was subsumed under SVG, and Adobe was a major participant the SVG spec development effort, with their representative, Jon Ferraiolo, serving as lead editor of the spec itself. The Adobe SVG Viewer became the primary way SVG was viewed on the web, while tools like Batik evolved steadily and browsers (with one huge notable exception) gradually evolved support for it. Adobe Illustrator supported and still supports SVG round trip, while InDesign offered SVG export but has since deprecated it.

On another front, rendition of documents, Adobe also participated in the most significant standard: XSL-FO. Here was a document description language highly similar to FrameMaker’s MIF, and again an Adobe expert, Stephen Deach, led the specification definition. FrameMaker never directly supported XSL-FO, but a short-lived server application, Adobe Document Server, offered XSL-FO support via its underlying FrameMaker engine. This was a great XSL-FO implementation, actually, but was not well supported by Adobe and it is now extinct.

On the surface you could consider Adobe a leader in standards-based XML for graphic and document formats. However, as I discussed earlier, there is an interesting mix of motives in the involvement of such companies in web and XML standards. When Macromedia Flash was a competitor, an “open standard” like SVG made sense, but after the Macromedia acquisition, it made less sense.

Adobe has gone down the path of proprietary XML namespaces, not unlike their competitor Microsoft. And like Microsoft, whose XAML is highly derivative of SVG, they have not found a reason to re-invent the wheel.

Three XML Namespaces

There are three XML namespaces that appear critical to the future of document and graphic description at Adobe. These are IDML (InDesign Markup Language), FLA (formerly XFL, the description of Flash, and FXG (the graphic model supported by Flex 4 and central to the designer/developer workflow of Flash Catalyst): FLA handles the complete, interactive Flash model (literally replacing the binary .fla format) while FXG is more about static graphic representation. Theoretically, FXG is open source, as is the Flex SDK, but these remain extremely Adobe-centric efforts.

FXG and FLA have some strong similarities to SVG. In fact Adobe acknowledges the partially derivative nature in the specs. Of course there are differences between what was specified in SVG and what is natural to the graphic model underlying Flash; it appears that SVG would have been difficult to implement across the board, given how Flash was built and the goals of Flex yet they used SVG tags directly where it did fit the Flash model.

FXG is becoming a very powerful specification, now that the Text Layout Framework is built into it. Flash is able to render FXG and Illustrator is able to import/export FXG. With CS5 the designer/developer workflows and the general interaction between print-centric and web-centric work should become much better.

IDML is not derivative from XSL-FO. It represents a very general similarity, especially compared to the earlier INX XML format for InDesign: it is at least a complete document object model. INX was merely instructions to the scripting DOM as to how to create the document. It is too bad that Adobe has not managed to reconcile the text engine of InDesign with that of Flash: it appears that IDML will for the near term stay quite separate from the other Adobe namespaces.

To me, FLA is the most exciting new XML namespace coming from Adobe, but it won’t really be exciting until we have an FLA server that can compile FLA to SWF quickly. Dynamic content is possible with Flash in many ways already, but the possibility of making the entire SWF dynamic and manipulating that content in arbitrary ways with XML tools should bring the form of publishing power we envisioned with SVG to life once and for all.

As they have tended to miss the boat on any server application of their technology, Adobe appears to be slow to perceive the value of such a thing (I once asked Kevin Lynch for a Photoshop server – he questioned whether anyone would want it, citing experience with Macromedia Generator). It is an interesting question which group an XFL server may come out of; such a product could be conceived as natural to InDesign Server, to Flash Media Server (or some other work of the Flash Platform group), or to Scene7 (which has very powerful SaaS rendition capabilities, some of which are based on FXG). We are lobbying…

Adobe has finally built some XML foundation under their rendition models, and we are able to attain many of the things we dreamed of back in the SVG/XSL-FO days, via XML if not via open XML standards. I don’t have big hopes for Adobe integrating semantic XML in their core products (FrameMaker being a black sheep outlier), beyond simple metadata (XMP is good enough here, but document-level metadata is trivial compared to true semantic XML). Hopefully the power of their rendition technology with its new XML underpinnings (and consequent greater extensibility) will provide a foundation that enables other companies and open source efforts to make tools that bring the deeper vision of XML publishing to life.