Published Articles by Chuck Gehman

Article Archives: It's less of a blog, and more of a compendium.

The subject matter of the articles primarily falls into the area of Internet-related technologies for document and printing applications. These include B2B ecommerce, integration topics like XML (W3C) and JDF (Job Definition Format, from the CIP4 Organization), Web-to-Print (W2P), Job Submission, online document customization and Variable Data Printing (VDP), Soft/Screen and Remote Proofing, and more recently topics related to Cloud Printing and Rich Internet Applications (RIA).

There are also quite a few articles about more basic topics related to printing, such as Print Production Workflow (which is also the subject my most popular book (Print Production Workflow: A Practical Guide) which, published in 2003, continues to be used in several University graphic arts programs as a textbook), Print MIS systems (as well as their integration to W2P, the subject of my second book), Computer Integrated Manufacturing (CIM - the subject of my third book), and other areas.

These articles originally appeared in printed magazines, or in "online publications" (i.e., not blog posts, but straight editorial). I'm using this blog as an online archive. The date of the posting that appears on the blog is the date of the original publication of the article.

I'm leaving commenting open here, and looking forward to any comments or questions.

I'm posting them one by one, as I discover them in my offline archives. They are scattered around old computers and backup hard drives, CDs and DVDs. I'm also looking for artifacts around them. Some of the publications they appeared in have gone out of business. In some cases I have the hard copy of the magazine as well as the digital manuscript, so I will publish an image of the cover when possible and/or appropriate.

This is fun for me, and I hope you enjoy the content. I've already been surprised by what I've found looking back!

Chuck

Printing from Rich Internet Applications (RIAs): A Standardized Approach

Originally appeared in TAGA 2009 Proceedings, Technical Association of the Graphic Arts, publisher

By David Uyttendaele* and Chuck Gehman*

Abstract

Until fairly recently, most web applications employed a client-server architecture in which the browser acted as the client, and a web or application server performed substantially all processing. This approach is not unlike the old days of "terminal and mainframe", although web applications are often simpler and easier to use by design.

RIAs (Rich Internet Applications) and their HTML/AJAX counterparts change this by downloading software into a web browser on the client machine, which handles rendering the application's user interface, and communication with the server. This provides the ability for developers to offer “rich” user-interface functionality which is not possible with only HTML and standard browser-based Web applications. The result is the RIA approaches the sophisticated look and feel of desktop software. This, along with the benefits associated with Software as a Service (Saas) and Web 2.0 applications, has resulted in growing popularity of this development paradigm.

Technology giants Adobe and Microsoft are leading the pure RIA charge with their respective Flash (and its Flex development technology) and Silverlight technologies, followed closely by a global cadre of developers, independently and in standards bodies, enhancing HTML and adding AJAX (Asynchronous Javascript and XML) to create such apps without the need to embed proprietary software. With the focus inarguably on the computer screen, and on multi-media applications (think YouTube), little priority has been given by developers to generating hard copy output. At this writing, there is no ability to print application-controlled, formatted content contained in RIAs anywhere but from the desktop computer.

The challenge is that all three of the aforementioned technologies can print to a local printer in a rudimentary way, with basic controls, but cannot print with any sophistication from a server. As these technologies gain in popularity, they will contain large volumes of the world’s information, much of it suitable and desirable for print output. As individuals and employees in corporations inevitably adopt “Web 2.0 technologies” to replace applications that are today done with desktop software, solutions must be created to enable Rich Internet Printing (RIP).

The opportunity is to allow the developer of an internet application, whether they are using HTML/AJAX, Flash or Silverlight, to print in a graphically rich way, based on standards, from/to the “cloud”. One solution would be to create a new kind of “print driver,” that uses a standardized way to model the print stream, taking advantage of the richness of the platform it is installed on, but directing the stream out of the app/platform.

* Mimeo.com, Inc.

Introduction

Web 2.0 applications are generally characterized as a second generation of Internet-based services—and include things like blogs, social networking sites (MySpace, Facebook, LinkedIn), wikis, communication tools and more. These applications are as much about user generated content (UGC) as they are about creating community. Blogs and Wikis, exciting new collaboration technologies, and emerging “value-added storage” where you can “park” your digital assets (documents, graphics, music, etc.) for use by individuals and workgroups, colleagues, employees and business partners are changing the way business is done. Some content is created in the Web 2.0 application natively, while other content is posted in native document formats. Much of the content that users put into Web 2.0 applications is suitable for high quality, complex document printing and subsequent distribution.

Web 2.0 applications use new Web technologies that provide richer user experiences from within a standard web browser. Older web sites with static HTML pages, or even dynamic pages driven by content management systems, appear obviously limited when compared to the new ideas and rich functionality of Web 2.0 applications. While it might be theoretically possible to create something that might be considered a Web 2.0 application using plain old HTML, and other more “traditional” web development techniques, they almost always are developed today using a selection of one or more Rich Internet Application (RIA) technologies.

Technologies employed in the development of RIAs include AJAX (Asynchronous JavaScript and XML), and ubiquitous proprietary technologies Adobe Flex and Microsoft Silverlight. In addition, RIAs often employ CSS (Cascading Style Sheets), RSS (Really Simple Syndication), Mashups (combined content from more than one source in an integrated experience), and Web Services of one sort or another.

In general, RIAs require modern web browsers in order to function. Some RIA platforms depend on advanced JavaScript engines in the browser for client-server communication, and DOM (Document Object Model) Scripting and advanced CSS techniques to enable the rich user interface. Other RIA platforms require the installation and maintenance of plug-ins, which decrease browser-compatibility issues, but introduce additional challenges.

All of this leads to difficulty in producing professional quality, formatted output from RIAs. This paper will briefly outline the history of graphically rich printing in computing, the current internet printing situation, and the challenges it presents; then will provide an inventory of currently employed strategies for printing from RIAs, and finally explore some directions that could be taken to improve the situation.

Background

In many ways, printing from RIAs can be equated to printing before Windows and Macintosh platforms were developed. Over time, display and printing technologies were “rationalized” and it became easier for developers to support high quality, professional printing in addition to formatting output for the display. Today, Quartz on Macintosh computers, and Windows Presentation Foundation on PC create a desirable environment for printing. The software development technologies, and the delivery environments that provide the end-user experience are the platforms for future applications.

In the early days of the World Wide Web (WWW), web pages were very simple. In many ways, they could be compared to Character Mode (i.e., DOS) applications. In that environment, printing was less of an issue. You simply dumped the content of the browser, which contained little formatting, to the printer. There is a relatively obvious parallel between the evolution of OS-based printing capabilities, as well as to the evolution of the Web platform and the printing capabilities (or, perhaps more to the point, printing needs.) To understand this evolution, let’s briefly look back at how Macintosh and PC platform printing developed over time.

In the earliest days of personal computers (late 70s, early 80s), printers were directly connect to the computer from which output would be generated, usually via an interface defined by an electrical specification, for example Serial (EIA RS-232) or Parallel (IEEE 1284). These interfaces actually started out serving the same purpose on mainframe and mini computers, and assumed close computer-printer proximity. They were so unspecific that in many cases, cables had to be made for specific computer-printer combinations. In terms of software, there was no platform-defined printing capability. The only thing the platform defined was the architecture via which data would be sent to the specific hardware interface. So to print a document, applications themselves had to build in support for the specific output devices (printers) they would support. Every time a new printer was manufactured, every single application provider had to build support for it.

Then, as networks (specifically TCP/IP- Internet Protocol) began to arrive on the scene, LPR printing (which began on Unix machines) became a good way to “separate” the hardware from the software, while adding necessary features to support printing in multi-user, multi-application environments. Although it began to address the requirement that printers be in direct proximity to a workstation, applications still had to be “printer-aware” to create any sophisticated print output.

In the early 1980s, Adobe created the PostScript language and a variety of technologies to support its use. At the time, PostScript was a major change in the way printing was approached, because instead of specifying how an already rendered image should appear, it specified how the image should be rendered. Although the difference might seem subtle, it would soon revolutionize the printing industry and eventually be applied to on-screen imaging.

In 1985, Apple's LaserWriter became the first laser printer on the market to ship with PostScript, and along with Aldus Pagemaker on the Macintosh, and the soon to follow Adobe Illustrator application, it spawned the desktop publishing revolution.

Not long after, Steve Jobs founded NeXT Computer. The computer scientists at NeXT realized PostScript's power could be extended to the computer screen, and worked closely with Adobe to produce a variant of PostScript called Display PostScript for on-screen display. This was a revolutionary step, the unification of the screen and hardcopy, both from the end-user perspective, and from the application developers standpoint. This became an integral part of the NeXT Computer’s operating system, NeXTStep.

After Apple acquired NeXT in 1996, the “digital paper” metaphor played a paramount role in the development of Mac OS X. But while the abstraction remained the same, Adobe's PDF specification (an enhanced subset of PostScript) was chosen as the model, instead of PostScript itself. Apple created a technology they called Quartz. This was the foundation for MacOS X's graphics capabilities.

The real win is the ability to write one chunk of code that can draw on the screen or printer. OS X has such a unified imaging model. Quartz is the text and graphics rendering library: It supports the user interface, including on-the-fly rendering and anti-aliasing. Quartz's internal imaging model is not PDF exactly, but is very similar to the PDF imaging model, making it easy to output PDF to multiple devices. The result is very robust professional printing capabilities, made easily available to the platform’s software and application developers.

In the “non-Apple & Adobe” evolution of modern digital printing, (hesitate to call it the “Microsoft” world, because so many companies drove the development), Hewlett-Packard came out with the HP Laserjet in 1984, also featuring what has now become known as a PDL (Page Description Language, of which Postscript is also one): PCL – Printer Command Language version 3. There are also numerous other PDLs, like AFP and IPDS (from IBM.) These PDLs, including Postscript, created much necessary rich-feature sets for printing, and abstracted the logic of printing from the actual device itself.

PCL 6 was introduced in late 1995, as a major upgrade, providing a stack-based, object-oriented protocol, similar to PostScript. PCL 6 was designed to match the drawing model of Microsoft Windows Graphics Device Interface (GDI). In this way, the Windows printer driver simply passes through GDI commands with very little modification, leading to faster return-to-application times. Prior to this, GDI printers (almost all other printers) almost universally sent a compressed bitmap to the output device.

But until Windows Vista, no one had come close to the model that NeXT had envisioned in the 80s, and that Apple brought to the “mass market” with OSX. With Vista, Microsoft introduced XPS (XML Paper Specification) and the Microsoft Windows Presentation Foundation, to enable rich end-to-end color document and photo printing and address many limitations of the existing GDI-based print path.

Windows Vista printing brings an advanced set of document services to the Windows platform. Enhanced color support enables high-end printing by supporting printing with more than four colorants, which is required for customers with prepress applications. The new print architecture can communicate application-generated extended color information to wide-gamut color printers. Device drivers can access and control color information from within the print pipeline.

When printing from applications built on the Windows Presentation Framework or when directing output to XPS Document–based printers or drivers, the XPS print path reduces or eliminates image data conversions and color space conversions wherever possible, enabling high-fidelity print output. XPS printing provides more faithful rendering of graphics attributes such as gradients and transparency though native support of these attributes in the XPS spool file format. The XAML in the XPS Document format is compatible with Windows Presentation Foundation XAML. When printing from a Windows Presentation Foundation application, Windows removes animations and converts video and three-dimensional (3-D) elements to images. All other graphics data is represented in compatible graphics primitives that are ideal for device consumption. The device or driver directly consumes the printing version of Windows Presentation Foundation output.

In many ways, printing from RIAs can be equated to printing before Windows and Macintosh platforms achieved their current level of sophistication. On those platforms, over time, display and printing technologies were brilliantly “rationalized” and it became easier for developers to support high quality, professional printing. Today, Quartz on the Mac, and Windows Presentation Foundation on PC create a desirable environment for printing. Sophisticated printing became a cornerstone of the success of the OS, having an enormous impact on the usability of applications. This is what is missing today in the Web 2.0 world, and is a necessary part of the evolution of this next generation computing platform.

When web pages were simpler, printing was less of an issue. You simply dumped the content of the browser, which contained little formatting, to the printer. Now, we need a print solution for RIAs that achieves parity or surpasses the Macintosh Quart/Windows Presentation Foundation solution for the desktop. But there’s still one other major hurdle to overcome: Today’s computing model has shifted from local data and processing on the desktop to many devices, including mobile phones, sharing processing and data in the internet cloud. As described earlier RIAs becoming the user interface (UI) to this new OS in the cloud. Since the OS is now in the cloud it should be logical to conclude that in addition to printing from the desktop (or in this case, the browser/application platform) to a locally attached device, we also need to “print to the cloud.”

Challenges

As we have discussed, much printing today still assumes computer-printer proximity. This has always been obvious challenge for professional Print Service Providers (PSP), even in the absence of RIAs. It necessitates a workflow that involves first creating a document (in the “traditional desktop computing model”, in a desktop application), and then “saving it” in an output format (e.g., PDF), or using another software package to convert it to the output format, then sending it (using a variety of methods) to a PSP.

What is happening now is that the web has changed expectations of printing overall. In the past, a user may have been satisfied to simply acquire pages from an application. Once you printed those pages, you would assemble them yourself (i.e., binding=stapling), or you employ an “offline” methodology involving sending them to a printing company (as in the desktop software example above) to perform “traditional” print production workflow, involving graphic arts processing to create a finished product. But emerging online applications (like Photo sites, as a prime example) provide the user with “invisible” manufacture on demand capabilities, so the expectation is no longer to just get pages from a printer, but a final product.

While much content is now being generated natively on the web, Web 2.0 developers (whether platform or application) view even desktop printing as an “afterthought” at best. Documents built natively in Web 2.0 applications cannot be easily printed, in professional quality. Printing from workstations using certain RIA technologies, specifically Flash, is rather sophisticated in taking advantage of the OS printing platform, but printing “to the cloud” (e.g., to a PSP) presents bigger obstacles. The challenge is that today’s popular RIA platforms can often print to a local printer in at least a rudimentary way, with basic controls, but cannot print with any sophistication from the applications server or workstation to a print service provider (i.e., in the cloud), without separately installed software (proprietary print driver) or very involved, specific proprietary printing code (create a PDF and send).

If you are a print service provider today, there are few direct benefits from anything happening in this Web 2.0/RIA world. If the Print community doesn’t address this lack of printing capabilities, it will lead to us having to spend time handling technology challenges in printing, and quite possibly help to accelerate the movement of content to non-print digital delivery. However, it is inevitable that people will want to take content from RIAs and have it printed professionally. This is clear from millions of dollars generated by Photo sites like Kodak Gallery and Snapfish. But document workflows are much more complicated. In either case, professional printing operations today must create their own print production workflows to support RIA-resident content. The technical challenges include the mechanisms by which print-ready files are generated, as well how to actually send, and receive them. Technically capable printing operations will win the new customer’s business, while others will not be capable of participating.

The table below provides a short inventory of examples of some popular Web and RIA applications and services. This by no means is meant to be exhaustive or complete, but rather intended to supply the reader some context. To see an overwhelmingly comprehensive list of Web 2.0 companies, visit http://www.go2web20.net. Each of the examples has deployed a system that is “collecting” user generated content, much of which can be considered appropriate for professional printing. The level to which the individual application provider currently supports printing, whether to a locally attached printer, or to a PSP, is briefly described.

Web 2.0 Application	Description	UGC in the app that is appropriate for printing	Support for printing
Blogspot, Blogger, Wordpress, Movable Type, TypePad	Blog sites	Blog articles and photos	local printing (from browser), download and print (PDF ), PSP (third parties sites)
Disney.com PBSkids.org, Noggin.com, kids sites	Kids media and activity sites	Characters, coloring books, activities	Local printing (from browser and flash) some products use a PSP
Facebook	Social Networking Site with more than 220 million global users	Photos	None, but has an application architecture allowing third parties to add functionality (Blurb, Hotprints)
Flickr, Kodak Gallery, Snapfish, Photobucket, Picasa, Shutterfly.	Photo Sharing sites	Photos, posters, photobooks, more…	Some local printing (from browser), primarily PSP
GoogleDocs	Office Productivity Suite	Office Documents of all types	local printing (from the browser)
MS Office 14 Web Applications	Office Productivity Suite	Office Documents of all types	Unknown, still in development
PPTShare, Slide Share, SlideRocket, 280 Slides	Online Presentation creation and/or sharing offered as Software-as-a-Service	Presentations	local printing (from Flash), Download and print (from PDF or PPT) or a PSP
Salesforce.com	Salesforce automation, and application platform	Reports	local printing from the browser or export to excel for printing
Scribd, docstoc, Issuu, edocr	Document Sharing	Documents of all types	local printing (from Flash), download and print (PDF, native file)
Wikipedia	Wiki encyclopedia	articles	Local printing (from browser), download PDF, or PSP (pediaPress)
ZOHO	Office Productivity Suite	Office Documents of all types	download and print (pdf) locally

Table 1: Examples of some Web 2.0/RIA applications, denoting their ability to support professional printing

In very high level summary, these providers can be broken down into two groups based on the how they handle or create UGC. First, there is content that originates in the RIA (i.e., documents built on the web). Second, there is content from non-web applications (e.g., PDF files or Word documents) that is being “posted” into Web 2.0 repositories. Some applications take that content and convert to a “native” format for the application (like Scribd, and its iPaper format), while others keep it in its native format. Some providers who convert also keep around the native document so that it can be retrieved later. Others do a “roundtrip” when the user wants to get the document back in its original form.

Until this problem is solved in a robust way (discussed in the next section of this paper), we’re going to see only highly motivated companies with niche professional printing applications knitting them into RIA/UGC applications and services. One timely example is Hotprints (www.hotprints.com), which has created an application used within the phenomenally popular social network Facebook. This new UK company, whose product are books called “HotBooks”, is in public beta now. A Hotbook is a 25cm x 20cm color photo book with 8 sheets and 16 total printed pages, 6 photos per page. It’s an exciting application because the books are completely “cookie cutter”. The company constrains the size of the photos that will appear in the book, so that almost any image that looks good on the screen in Facebook will also look good in the “Hotbook” you order. The company sells the books for $2.99 plus shipping, which is about $.75 to the United States. They will likely sell millions of books because they are embedded in Facebook, which at this writing has the richest collection of photos on the web, already-tagged and ready to be turned into printed books.

Another example is the collaboration between my company, Mimeo.com, and SlideRocket. In this case, our two companies had to work together to invent a way that Sliderocket presentations could be professionally printed by Mimeo. SlideRocket is part of this new generation of RIAs. It is a Web 2.0 online presentation application that allows users to produce slideshows that have some key advantages over creating presentations in desktop applications like Microsoft PowerPoint. SlideRocket runs in a web browser, instead of requiring the installation of software on your computer. It features collaboration tools that let users share slides and other assets (like graphics and movies) between presentations. Because the application is Internet-based, these users can be geographically dispersed and still share nicely. This collaboration, and user-generated content sharing, is what makes SlideRocket a unique and powerful Web 2.0 application.

The SlideRocket relationship with Mimeo involved the use of the MimeoConnect SOAP API technology. This is a set of Web Services that let partners submit files, define product intent, get quotes and proofs, and submit orders, recipient addresses, shipping methods and payments. This technology solves the problem of delivering content files and placing orders; primarily the communication between our two applications in the cloud (i.e., cloud to cloud).

With that connectivity in hand, we then needed to solve how SlideRocket would take their rich content (screen-based Flash presentations) and turn it into PDF files to send to Mimeo (this was a Mimeo requirement, due to our automated PDF-based production workflow). Finally, we needed to create a way to let the non-technical SlideRocket user to specify the product intent to communicate to Mimeo for manufacturing.

To solve the former problem, SlideRocket created a server-based application that “printed” the “slide deck” to a PDF file. To solve the latter problem, Mimeo created a special interface designed to reside within the SlideRocket Flash application. When the user chooses “Print” from the SlideRocket menu, they can either choose to print on their local printer, or print “high quality with finishing options” via Mimeo.

The interface we built incorporates a subset of Mimeo’s new photo-realistic document viewer. We call it MimeoProof, because it is about as close as one can get to holding a print product in their hands by viewing it as an image on the screen. The Sliderocket version lets the user see their presentation, visually depicting paper stocks, covers and binding choices. This is an important part of helping the non-technical user specify product intent, it gives them the confidence they need to proceed with the order.

Once the user places their order on the SlideRocket site, e-commerce and print-specific transactions flow: we are sent a PDF file containing the slides, and an XML transaction containing the order information (desired quantity of books, destination, shipping method, etc.) The next day, or at some point in the near future depending on the user’s choice, a beautiful bound version of the Sliderocket slides shows up on the user’s doorstep in whatever quantity they specified.

Both of these examples demonstrate the difficulty of printing from RIAs. In each case, much effort by software developers was required to get the content into the printing operation in a usable way. They also demonstrate how powerful solutions to these challenges can be, for the professional PSP.

Investigation

We previously discussed the fact that developers of Web 2.0 applications address printing as an “afterthought”. But in the overall scheme of global media, Web 2.0 should be viewed in the context of “channels of engagement”, which include PCs, Mobile, Consumer Electronics (i.e, gaming platforms), and print channels. In terms of print itself, these channels incorporate traditional print publishing, electronic documents, interactive media, websites, and RIAs. While the audience is present and receptive, and the content in many cases is suitable, there are a couple of technical obstacles that make it less likely Web 2.0 developers will incorporate professional printing into their applications, even if they desire to do so. Today, only the most motivated developers will do this. Hotprints, as an example, has business model that is centered on the creation of a printed product, so they needed to solve these problems. ZoHo (see Table 1) similarly had to do so, in order to compete with Microsoft Office. But most of these websites and RIA apps are motivated by online user experience, not print, and we believe will never even attempt to address these challenges, without it being much easier.

The reason it is difficult is that RIAs are built using new technologies like Flash, Microsoft Silverlight, Ajax/HTML, or one (or more) of dozens of other emerging technologies. At the desktop Flash does offer WYSIWYG printing, but does not provide the ability to “print to the cloud”. Silverlight does neither effectively. HTML/CSS is only as good as what the combination of HTML/CSS and each browser allows. So a big part of the adoption limitation for print is that even the platform developers are not focused on print. A notable reason for this is that the platform developers are instead consumed by a focus on interactive. Microsoft had a great opportunity to solve these printing problems with Silverlight, using XPS and XAML, but it appears that was de-emphasized in their market-focused desire to achieve technical parity with Adobe and Flash- specifically in the video area, in the interest of recovering market share.

Most technical readers of this paper are familiar with the technologies mentioned above. Flash, for example, is from one of print’s favorite vendors: Adobe. Further, most are aware of Google Chrome, which is being touted as an “application platform”, not a browser. No doubt we’ve heard about the success of salesforce.com, too. Applications are moving to the web. Increasingly, we will see graphically rich applications moving to the web. The user can print to their local printer by doing “File-Print”, from the web browser—but, only in limited circumstances will the resulting output be professional quality.

So there clearly is a need to create a standardized solution to printing from these applications, both to local output devices and “in the cloud”. Let’s examine some of the ways developers have solved this problem to date.

Technology	Platform	Printing Capability
Pure RIA	Flash	Client OS printing to local printer (high quality, easiest to implement)
		Control HTML/CSS in browser from flash and print via browser. (good enough output, some challenges to implement)
		Cloud Generated PDF downloaded to local printer via browser (most portable, involves coding and support of 2 applications, RIA and server)
		** Cloud Generated PDF to Cloud print provider (Truly professional quality product possible, involves coding and support of 2 applications and working with a proprietary PSP API)
	Silverlight	Control HTML/CSS in browser from silverlight and print via browser to local printer (good enough output, some challenges to implement)
		Cloud Generated PDF/XPS downloaded to local printer via browser (most portable, involves coding and support of 2 applications, RIA and server)
		** Cloud Generated PDF to Cloud print provider (Truly professional quality product possible, involves coding and support of 2 applications and working with a proprietary PSP API)
DHTML/AJAX		HTML/CSS in browser print via Client OS to local printer (rudimentary output, easy to implement)
		Cloud Generated PDF downloaded to local printer via browser (most portable, involves coding and support of 2 applications, RIA and server)
		** Cloud Generated PDF to Cloud print provider (Truly professional quality product possible if assets are high res, involves coding and support of 2 applications and working with a proprietary PSP API)

Table 2: Printing destinations/capabilities of popular Web 2.0 platforms

Without exception, with any of these platforms, if you are trying to create completely controlled output to the Cloud today, you are constrained to building a separate application that interprets your front-end content in a different way and then generates a print stream.

The result is a major software development burden to support the printing subsystem on an ongoing basis, with all the maintenance issues and divergent application issues associated with supporting two platforms, one for the screen and one for hardcopy. More complex documents and formatting necessitate more difficult development and arduous ongoing maintenance tasks.

Once the developer has solved this basic problem of creating a document model within the application, then the choice has to be made as to how to create something that is compatible with a PSP’s production workflow. Choices might include generating PDF or XPS files, or creating high resolution images.

Furthermore, since Web 2.0 applications are characterized by providing the user with much more control of their overall experience, in an ideal world print should be able to be controlled in the same unique and wonderful way. It becomes a question of whether the output is under the control of the content owner (or RIA developer) versus the content user. However, the amount of “control”, actual or perceived, varies from one application to another.

For example, a German company called PediaPress recently launched an application that lets you choose pages from the popular Wikipedia, and through a user-friendly interface, create a 8" x 5.5" perfect bound book with a color cover and black & white interior. The finished book includes a table of contents and index, which are automatically generated. The company is currently selling the books start at US$8.90 for 100 pages, and they are printed and shipped worldwide within 2–15 business days. We ordered a book, and it was produced and shipped by LightningSource,

There are a couple of important things to study in this implementation. First, Wikipedia’s content is uniformly structured. This makes it easier to manipulate in general, than systems that accept freeform content in native application file formats. Second, PediaPress also created and licenses as Open Source some of the technology they use to access the content in WikiPedia. This was, according to new reports, apparently required under their contract with the non-profit Wikimedia foundation. The goal is to ease the reuse of wiki content in other media or applications, so other developers can use their software to build an application to print books from content stored in WikiPedia, too. PediaPress’ tools include a Python (programming language) library for parsing MediaWiki (the technology underlying WikiPedia, and now other systems) articles, and a library for writing PDF documents from MediaWiki articles, as well as parts of the interface to WikiPedia itself, a “Collection extension” for MediaWikis that would let a developer collect articles and output them in various formats (PDF, ODF, XML,etc.)

In this case, the resulting printed product matches the fidelity of what the content looks like on the screen very well. This is important, because there is an expectation that the same level of rich tools the user has to control the experience in on the screen, should be available to control printing, resulting in a high fidelity printable document.

As described earlier, a developer seeking to create professional output today by printing to the cloud from an RIA application has one basic option: to write a duplicate proprietary server based application (custom built and/or leveraging licensed software) to:

1. Generate a PDF from their natively generated, or stored front-end content

2. Write proprietary software to submit their PDF content

3. Collect intent and generate job ticket information and order details

4. Send this all to a web enabled PSP in a way that PSP can accept, which may also require additional coding

We believe it is worthy of additional investigation to print directly from each of the three RIA platforms discussed earlier; since it is not commonly employed and could provide a valuable, easier alternative. Some of the following discussion requires at least limited knowledge of the development platforms discussed. It’s out of scope of this paper to go into depth on these how these technologies work, or to provide a tutorial on object oriented programming, but you can readily find the deep background of what is described on the web.

An efficient and powerful (as well as simplified) way to print from the Flash/Flex platform would be to enable the developer to use the same mechanism and code path to print to the cloud as they can use to print locally today. In Flex 3 (at this writing, the latest iteration of the technology), the developer simply uses an instance of a PrintJob class, to start(), then uses addObject() one or more times, and finally employs send() print output to the OS for local printing.

To address printing in the cloud, a more universal (or web service) version of the PrintJob class would be created, perhaps called UniversalPrintJob that inherits it interface and capabilities from PrintJob but that adds the capabilities necessary for formatting and redirection of the output to the PSP. This class could provide an alternate implementation of PrintJob that would directly create a PDF or some other portable format from any Flex object added to the print job through the addObject method providing a great solution to the problem of creating an appropriate printable format.

Continuing this idea there could be additional properties, methods or parameters that could provide the additional information needed when the Send method is invoked to submit the content to a RESTful webservice. By simply providing a URL, additional job information and order data formatted as XML or JSON the send method could use the internal Flex HTTPService and/or WebService classes to seamlessly send this print job to a web enabled PSP.

Microsoft had an amazing opportunity for Silverlight to solve all these problems with their XAML and XPS technologies, but unfortunately there isn’t even an ability to robustly support local printing in Silverlight 2. At this writing, you will find many references to incomplete and/or cumbersome point solutions to this problem on the web. This does mean, however, there is still a great opportunity to define a universal printing model from scratch, taking advantage of what could be possible in Silverlight.

Since Silverlight basically uses XAML as its imaging model and XPS is a subset of XAML it would seem to make sense that one could create methods for converting Silverlight content to XPS, then send this data to the Cloud for printing in much the same way we described doing this with Flex, only this time using XPS instead of PDF. XPS is not (yet) universally accepted, but then again neither is Silverlight. That said, it is just as feasible to generate PDF from Silverlight as it is from Flex.

The pure HTML/CSS/AJAX world can also find a similar model, although depending on where the content is located it may not be as universal. CSS already has support for media types “screen” and “print.” By setting a Stylesheet’s media attribute to “print” you can customize HTML content specifically for printing. Often the developer defines an entirely separate Div, invisible to the user, styled for print. This same model might work for printing to the Cloud. One could simply post that special Div’s content directly to a RESTful API (a popular Web 2.0 inter-application, inter-site, communication method), which is handled by software that would have to be built or acquired by the PSP. This would only work for content that is either entirely HTML text or that has an absolute path URLs to any CSS or images. Then, of course, the PSP would have to possess software that can support HTML as a valid print format, or convert the incoming HTML to PDF or another format for output, via conversion service (which would also have to be built or bought).

Another approach could involve a JavaScript library or jQuery plugin that would walk the Document Object Model (DOM) of this aforementioned Div, and would appropriately resolve any src uris and css so it would convert easily to a printable format. In this case, the software might also incorporate the capability to generate PDF or XPS directly, greatly simplify the number of steps necessary on either side to complete a job submission.

The goal we would look forward to would be for the three platforms to support a standardized way to model the print stream and handle the submission metadata.

Conclusion

A creative and industrious few professional Print Service Providers, with vision and technical expertise, are beginning to reap the benefits of the growing body of user generated content in Web 2.0/RIA applications, but many others cannot participate with the current status quo.

The likelihood of these challenges being address by an industry standards body is relatively low, because of the fast moving nature of the RIA development world. There may be major developments from the platform vendors which do address at least some of these challenges in the future.

In an ideal world, the three platforms would employ a standardized way to model the print stream and the submission metadata. The authors wish that, as a result of our investigation, we could name a single solution to all of the problems articulated here. But we aren’t there yet. The biggest beneficiary of a standardized approach, in our analysis, would be the Print Service Provider, because it would free us from having to build and support multiple technologies to manufacture professional print from RIA content.

It is very possible that the best way for us to achieve that goal might be via a collaborative approach, similar to Open Source efforts. A community that forms around this need should involve major industry software vendors, content owners, Web 2.0 service providers, and print service providers, among others. The Open Source model is a pragmatic way of evolving software in a rapidly changing environment, and could benefit many of the constituencies in this ecosystem. We will continue in our quest to address these challenges, and we invite anyone interested to contribute to an emerging community.

Literature Cited/Selected Bibliography

Ferrailolo, John, 2008. Good News for AJAX – The Browser Wars are Back!, Ajax World Magazine, http://ajax.sys-con.com/node/547209

Russell, Matthew 2005. What Is Quartz (or Why Can't Windows Do That?), O’Reilly Media

Apple Computer 2007. Graphics & Imaging Overview

Paquette, Mike 2006. Why Apple didn't use X for the window system?, Apple Computer

Microsoft Corporation 2007. XPS and Color Printing Enhancements in Microsoft Windows Vista

Thricovil, Raghunath Rao and Lambda, Prabhdeep Singh 2008. Introduction to RIA, Adobe Systems

Sylvester, Carrie 2009, A picture may be worth a thousand words… but it costs only $2.99!, InfoTrends InfoBlog

Follesoe, Jonas 2008. Printing in Silverlight 2 using CSS and ASP.NET AJAX4, http://jonas.follesoe.no

Bernius, Matthew 2009. Taking Open Source Publishing Further: Tools from the Open Publish Lab at the Rochester Institute of Technology, presentation from the O’Reilly Tools of Change for Publishing Conference

Wauters, Robin 2009. Print Your Favorite Articles as Books, Courtesy of PediaPress, http://www.techcrunch.com

The Digital Smart Factory 2008: The Direction to Take NOW

A moderately edited version of this piece originally appeared in the NAPL's Special Report "Path to Progress, a Workflow Special Report", published October 2008, beginning on Page 3.

This is the original manuscript.

By Chuck Gehman

"Long gone are the days when people believed ideas such as Computer-Integrated Manufacturing were not applicable to printing."

The concept of the Digital Smart Factory has become mainstream. As we rapidly approach 2009, it is a good time to take a quick look back, take stock of where we are now, and think about where we are headed. For those not well acquainted with the DSF concept, it’s about applying computers and software in an integrated, end-to-end solution, to address problems facing the printing operation; with the specific goal of making printing companies more efficient: customer-facing web applications, business systems and manufacturing systems. There is a broad range of technology, as well as process methodology, that fall under the umbrella of the Digital Smart Factory.

Long gone, thankfully, are the days when people actually believed that ideas like Computer Integrated Manufacturing (CIM) weren’t applicable to printing. Instead, we now have venerable industry associations leading the charge for Lean manufacturing, embracing “green” concepts, and advocating high-tech solutions like VDP, ERP systems and Web-To-Print. Clearly, the R+E Council of the NAPL and its role in establishing the importance of the Digital Smart Factory, has had a major impact on the industry.

More than a handful of very successful printing companies have proven that there is a business case for making the transition from craft-oriented job shop to efficient, high tech, well-run, and scalable print manufacturing enterprise. This Digital Smart Factory idea—¬that was so foreign for so long— is¬ the direction leaders want to take their printing companies today.

As a reminder, Digital Printing is not the entire focus of the Digital Smart Factory. Adopters often employ multiple printing technologies, today including toner-based, inkjet and, of course, both sheetfed and web offset. Virtually any shape and size of printing operation can benefit from DSF concepts and the application of its technologies.

When we first began the DSF, print-on-demand was a far-out idea. Makereadies took 45 minutes. There was no E-Bay or Craig’s List. Energy costs were low. Phone companies charged by the minute for long distance. A mobile phone cost $800 and had a battery that weighed more than your laptop does now. You had to buy two Indigos for $1 million and have a technician on-site to fix them. A lot of printers still used film! Today? Print-on-demand is ubiquitous. Makereadies can take under 2 minutes! Craig’s list dominates classified advertising. Gas is $5.00 per gallon. Long distance is “free”, and so are mobile phones. You only have to buy one Indigo now, and it is reliable! Film? What’s Film?

Between then and now, those printers who are still around discovered that the way to cope with the changing business environment was to adopt new business and production processes. The industry has embraced the transformation from “Job Shop” to “Manufacturing”. Mass Customization can legitimately be used to describe the type of manufacturing being done in our industry

Today, there are many printers using manufacturing techniques, CIM (Computer Integrated Manufacturing) processes, in conjunction with automated equipment and technologies like JDF (Job Definition Format) that can deliver immediate and recognizable benefits from streamlined operation for companies that produce a wide variety of jobs.

The transition to manufacturing discipline helps printers to identify opportunities for optimization and understand which product types they can most efficiently produce. They can then focus business assets on developing sales and marketing strategies that target specific customers with more attractive offerings.

There are still many hurdles to overcome, and many challenges that still exist. Although many printers have adopted CIM techniques, there are many unique attributes that characterize print production that are absent from many other types of manufacturing operations. To a large extent, this explains the necessity of CIP4’s JDF format. But it also requires even more discipline in applying CIM techniques of any type, to maximize the benefits that can be gained.

Whither Specialization?
The idea of specialization has been a path to success for many printers, and isn’t new. But the drumbeat we hear today is more about “diversification” and adding services: becoming a “marketing communication service provider.” But whether you choose to focus on a particular market, or go “horizontal”, you can benefit from specialization in manufacturing. Specialization can remove a lot of complexity from an operation. Single-use machines require fewer changeovers and less or no wrench-turning, for example. It can decrease requirements for staff training, or even for temporary labor to fill peaks and valleys, and for unique, expensive skill sets. A great example of the benefits of specialization is that you may not need new JDF-enabled equipment and software if your company only produces a limited range of products — in other words, you operate a specialized manufacturing environment.

Specialization can help you sell more effectively. Once you’ve determined what your optimal product mix is from a manufacturing perspective, you can target specific vertical markets. You can more easily sell value-added services by creating a product portfolio across one or more client industries. Implementing this kind of product strategy will, however, require that you put other resources in place beyond an efficient manufacturing operation. These may include sales and marketing staffers, Web-To-Print systems and enhanced customer service capabilities, or adding services like fulfillment to round out the offering. This leads you into deploying programs that can be sold at higher margins than “bid to win” jobs, and may be replicated across multiple clients.

Roadmap to DSF
Automating inefficient processes simply solidifies them and makes them more difficult to improve and change. This is what happens when you drop a new piece of equipment or computer system into an existing operation without a carefully crafted strategy. Before you can benefit from equipment, computers and software, you first need take a number of steps to make your company ready for CIM:

• Identify and eliminate bottlenecks in production.
• Identify and eliminate issues that impact quality, put processes in place to achieve the highest quality possible
• Standardize all steps from job intake through delivery
• Begin to automate certain operations, move toward “global” automation

There are a number of ways you can approach this streamlining exercise, with the key thing to remember being that you don’t have to do everything at once. Look for the most obviously cumbersome process. Ask a lot of questions, and get some quick wins under your belt. Don’t try to “boil the ocean.”

Quality Systems
ISO, TQM, Six Sigma are all methodologies from which you can choose to implement the steps described above. Which one you choose is dependent on a number of factors that could be unique to your operation, so it’s important to understand the strengths and weaknesses of each.
ISO 9000 (International Standards for Quality Management Systems) is a family of standards that is acknowledged worldwide. More than 90 countries have adopted ISO 9000 as their national standards. Many printing companies, of all shapes and sizes, have adopted various “flavors” of ISO.

Total Quality Management (TQM) was pioneered by manufacturing guru W. Edwards Deming as a way of improving the production quality of goods and services. This has become less popular with printing companies today, but there are still many practitioners.

Six Sigma is a quality improvement and business strategy that began in the 1980's at Motorola and is perhaps best known for its application at General Electric, where legendary CEO Jack Welch was a key proponent. The primary goal is to improve quality to the point that “defects” occur only 3.4 times out of a million. Six Sigma is viewed by many as overwhelmingly complicated and expensive, requiring specialized staff, but it can work for printing companies.

There is also a combination of Lean manufacturing and Six Sigma that some printing companies have implemented, called Lean Six.

Each of these methodologies, in addition to having direct benefits, provides marketing benefits for printing companies that deploy them. If you have large corporate enterprise customers, your choice of which to implement may be based (in part) on what they are using, because those customers tend to gravitate toward suppliers who are “compatible” in this area.

Just in Time and Lean Manufacturing
There are several manufacturing “philosophies” that can provide improvements. Lean is arguably the most popular, and in some ways easier to implement. Lean manufacturing’s primary goal is to identify and eliminate non-value added activities in design, production, supply chain management and customer interaction. It is one of the easiest ways to see immediate benefits in a printing operation. Its application in printing can be summarized as a critical view of the following areas, and the reduction, elimination or replacement by automation, of unnecessary activities or results in those areas:

• Material Waiting
• Movement of Inventory
• Movement of Personnel
• Equipment Waiting
• Personnel Waiting
• Overproduction
• Underproduction
• Performing extra steps
• Waste or Spoilage

The term “lean” was first coined by an MIT team, to describe the principles of the Toyota Production system (TPS). There are many books that discuss all the aspects of lean manufacturing and TPS, including Value-Stream Mapping, the concept of the 5S Method, Visual Control. Pull, Equipment Changeover (setup reduction), Mistake Proofing, and Total Productive Maintenance (TPM) are also important concepts. My own book, Computer Integrated Manufacturing: Realizing the Benefits, published by the NAPL, can give you an overview of all of these topics.

If there were one reason to turn your own plant into a Digital Smart Factory and embrace CIM concepts, it might just be to eliminate mistakes that cause costly production errors. The cause of poor performance (in the view of lean), is wasteful activity. Lean is a time-based strategy and uses a narrow definition of waste activity as that which does not produce value from the perspective of the customer. An example often sited is moving work-in-progress from one side of the plant, to another (instead of situating production equipment in adjacencies that make sense for the workflow). Efficiency (and lower costs, and competitive advantage) is improved by focusing on converting raw materials into finished product as quickly as possible.

Waste, as described in the Lean view of the world is:
• Production errors
• Internal and external delays
• Unnecessary duplication of effort
• Unnecessary movement of digital information or physical materials
• Unclear and confusing internal and external communications
• Incorrect inventory of digital information or physical supplies

Customers become part of the manufacturing process
In today’s competitive environment, it isn’t enough anymore to focus solely on streamlining what happens inside the plant. Understanding that a lot of the problems in the print manufacturing process are caused by the customer participation in the process, because of customers delivering bad files in a variety of cumbersome digital file formats, Digital Smart Factory printers also focus technology efforts on reducing or eliminating these problems.
One approach to this problem is to limit customers’ selection of product types, and offer a limited selection of customizable attributes for those products. Using a Web-To-Print storefront, it is possible to provide a graphically rich, appealing set of choices that fit their specific needs and/or the vertical print-buying market that your company targets. This approach almost guarantees success, because you are completely controlling the input to manufacturing. However, it may be too rigid a structure for many customer relationships.

For relationships in which a large number of one-off projects take place, another approach to facilitating quality input from customers is to mandate the use of PDF and to provide templates and instructions for customers on how to produce a PDF file that the plant can use to drive manufacturing processes. PDF is still the best file format for printing, and provides great benefits. It lets many of the manual processes of preparing files for production be automated through software. Most printing company customers now know how to create a usable PDF file.

In the digital output world, many systems are either converting “office”-type documents into PDF at the entry to the workflow, or are helping customers to create usable PDF files with desktop print drivers or Acrobat Plug-ins. Similarly, offset workflow has moved to PDF, with native files from high-end designer applications being converted to PDF as they enter the workflow.

Deploying a Web-To-Print workflow has additional benefits for both the printing company and customers. Customers are impatient, and like the instant gratification that self-service on the web offers. They can also come back to the site to obtain job status, and shipping information once the job is completed. For printers, the obvious benefit of Web-To-Print is its ability to increase order flow, positively impacting top line revenue. But the ability to offload sales and customer service personnel to higher value activities beyond order-taking is also a key benefit. Web-based e-commerce can make getting paid easier, too, by accepting credit cards and/or by interfacing with customer e-procurement systems. Once the ready-to-print order has been paid for by the customer (another great advantage—getting paid before the job is even printed), it can be automatically scheduled for production. Like jobs can be optimized into print runs, and targeted at specific machines for the most efficient processing. In an ideal world, there’s no prepress or prep work necessary, especially for digital jobs.

Summary
The big difference between the Digital Smart Factory now, and many years ago at its inception, is that we’ve solved many of the problems that led to its ideation. But new challenges have arisen, and new solutions continue to evolve.
Join the many thousands of printing companies who have embraced the Digital Smart Factory, and you, too, can immediately start reaping the benefits. If you don’t know where to start, call the NAPL, or attending one of their many events throughout the year.