Improving Support for Creative Activities within the JDF Framework

By Thad McIlroy

This article appeared in the February, 2007 edition of PrintAction. Subscriptions are available here http://www.printaction.com/default.php/shop/subscribe/subscribe.

The printing industry is in a life-and-death struggle. The challenge of the Web is forcing printers to make dramatic changes in the way they do business. The industry has accepted the move from craft to manufacturing, but doesn’t have the background to know exactly what to do to become the kind of efficient manufacturers who can compete with Web publishers.

CIP4’s JDF standard is perhaps the most promising move the industry has embarked on to enable a degree of automation that will drive waste out of manufacturing, and reduce labour costs. But there’s something missing from the JDF equation: the creatives and document originators who dominate so much of the full manufacturing process. JDF is built on the old idea that customers “toss their files over the fence” to prepress and print service providers, who then do the real work of making the files ready for print. Yet this leaves an enormous opportunity on the table, the opportunity to truly unify the manufacturing process that is print!

As with all activities initiated by human beings, the graphic arts industry has fallen into a number of holes from which it is finding a great challenge to climb out of. We are all creatures of habit — there are solid evolutionary reasons why this serves us well. We find safe ways to negotiate our place in the world, and change them only when dire necessity forces us to.

The past two decades have been a time of extraordinary change in the world — graphic arts occupies a modest niche against the much larger forces influencing business, politics, medicine — you name it. We tend naturally to focus on our part of the universe as if it was representative of the whole, and then find, to our dismay, that the broader changes are wresting control from our diligent efforts.

The Internet and the Web: so much a part of our lives today; not even on the radar for most of us when the graphic arts began its transition to full digitization in 1985. They have changed the equation for print. The Web seems to offer a far more compelling communications medium than print can counter. What is to be done?

Some print-based industries are finding it all but impossible to counter the Web juggernaut. Newspapers come quickly to mind – the last twelve months have brought a sea change to investor’s view of the industry. The prevailing sense today is that the newspaper business is in a pronounced decline and unless they get their act together vis a vis the Web, they will be challenged to survive.

What about commercial print? After some very tough years earlier in this decade, the economics of commercial print have improved. But does this represent a new status quo, or a lull before the next storm? The Web challenges all forms of print, and the printing industry must engage in some fundamental restructuring to maintains its position, or perhaps even to survive.

Some of what makes the Web compelling cannot be addressed by print. It is instant, it is interactive, and it is accountable. Print cannot be truly instant (despite “instant printers”). It is not interactive in the immediate way that the Web is. It is very difficult to make print accountable against cookies, click-through ads and page counts.

And so print must be more efficient. It must be lower cost. It must be fully digital. It must be fully automated. It must take advantage of all of the standards-based technologies that make the Web so compelling. And it must learn to live comfortably alongside the Web.

In the last two decades, we have recognized these realities, however there continues to be a disconnect between vital components of today’s print workflow: integrating creatives in our quest for true end-to-end automation.

The Big Silo

One of the largest holes that the graphic arts industry has fallen into is the gap between those who plan, design and execute documents, and those who print and distribute them. Historically it made sense. Designers were paying the bill, and printers were making sure the job printed to the designers’ satisfaction. As full digitization became the norm, the norm remained: designers were paying the bills, and printers were making sure the job printed to the designers’ satisfaction. The problems in designers’ submissions were now digital problems, but the basic value equation remained the same. Preflight became an essential part of the overall production process and too many designers said, “I pay you to make sure my file prints.” It sounded right, as the printer generally bore the brunt of the responsibility.

Or so we have all thought.

But we also know it is true that the majority of the digital data that determines the final printed output of a file is created and controlled by the designer. Preflight has become the “lazy designers’ safeguard,” and the printers’ insurance policy. Yet it introduces an extraordinary inefficiency into the overall process. Designers are allowed to continue to be sloppy, while printers charge them to catch their repetitive and largely avoidable errors. Costs increase, and turnaround is often significantly reduced. Waste increases, and the cost of this waste affects everyone in the food chain.

Full Automation

I have argued repeatedly in these pages and in my seminars that this workflow must change. Full automation is the only way to bring maximum efficiency to the print process. We have achieved “islands of automation” — parts of the process work extremely well. But until we unify the process towards full automation we remain victims of the weakest link. The newest presses are a wonder to behold: full colour control, modest makeready, and digital operation. But before a job reaches one of these multi-million dollar presses, as often as not, it bogs down in prepress, where operators painstakingly examine files to uncover problems that can make a state-of-the-art printing press operate as if it was a reconditioned model from the 1960s!

Enter JDF

JDF — the Job Definition Format — is now roughly 15 years old. While the first version of the specification was published in 2001, a decade of hard work led to its publication. As you will read elsewhere in this issue, the 300 + vendors behind have made great strides against huge challenges, creating a format and a methodology enabling substantial automation in the prepress, print and post-press portion of the graphic arts production process. JDF is a big bear (the current spec is nearly 900 pages), but it is being supporting by the players that matter, and they are determined to make it work.

This brings me to my original point. As I contemplated my view of full automation, it struck me that the designers and other document originators are the players that truly drive all of the processes that JDF currently supports.

For the last several years I have been working with the IPA (www.ipa.org), the Association of Graphic Solutions Providers, to address joining these silos. IPA was for years the International Prepress Association, “home for prepress companies who focused their businesses on the processes between creative and delivery.” They have morphed into a broader group, now including many printers, but not many creatives. I have lobbied successfully to have the IPA pay closer attention to integrating the work of creatives into their broader workflow. It was only natural that the IPA would support my approach to CIP4, the organization that manages the JDF effort, to see if we could work constructively to assist CIP4 to ensure that the JDF specification reached as far back as possible into the creative/document originator sphere. A specification as important as JDF will influence the direction of our industry for many years to come. CIP4 was immediately receptive.

The Challenge

There was an obvious question to be answered: What exactly is missing from JDF 1.3 that addresses the “creative” side of the process?

The problem is in the methodology. JDF is largely concerned with “handoffs.” One device sends data to the next device in the production stream, with instructions on how to handle the next production step. Through the JMF (Job Messaging Format), that second device can respond and confirm that certain actions have been taken.

This metaphor is more challenging in the creative workplace. Prepress/press/post-press tends naturally to be more sequential: the “hand-off” is a suitably descriptive term. Creative/document production tends to be more “iterative” — repetitive and cyclical. The JDF metaphor is challenged.

A Creative Workflow

I believe that one of the great mistakes made by workflow analysts is their attempts to capture and describe all potential instances of a process. I readily acknowledge that most organizations work differently and that there are significant differences to be recognized. But by focusing on the detail, we quickly lose sight of the larger picture.

To examine the creative workflow I find it most helpful to take the most basic of print pieces: the two-sided, 8-1/2″ x 11″, full colour spec sheet.

The essential creative workflow for this product comprises these steps:

1. Product specification — intent, audience, print-run, etc.
2. Text writer — commission from someone who can write it, presumably in Microsoft Word.
3. Illustration — commission an illustrator, as required, or draw upon existing illustration(s)
4. Photography — commission a photographer, as required, or draw upon existing photography
5. Design — commission a designer, always required
6. Composition — if the designer will not be handling composition, than a compositor will be required
7. Quality control/approval/proofing — establish a quality control/approval/proofing cycle

In current workflows, as mentioned, this process is iterative. Any one of the steps may undergo adjustment as the process revolves. At any time, any of the players may be asked for changes or revisions, particularly during the quality control/approval/proofing stage. But even before that, the text writer, who may have the best command of the exact nature of the project, could challenge the illustrator or photographer on his or her work. The designer is also likely to have questions of the compositor.

There is really nothing, in the JDF metaphor, to benefit this process. What data can the illustrator pass through to the compositor to inform his or her work, other than what is inherently available by an examination of the readily-available detail of the illustration, easily deduced from any graphics software?

What about the photographer? Yes, a page assembly program like QuarkXPress or Adobe InDesign can easily spot incorrect colour spaces or insufficient resolution. But this is not a JDF task. The problem can be caught during page assembly, during a QC phase, or by the printer during preflight.

The Other Side of the Equation

There is an enormous other world in this scenario that begins to fit into a JDF-enabled workflow – it has to do with taking this kind of production out of its current silo and moving it into a cross-media, content-managed workflow.

We have moved beyond the time where the creation of a spec sheet was a singular event. For a manufacturer of any size, spec sheets are part of a fundamental arsenal of product information. They are no longer produced annually and warehoused. They are constantly updated, as the products they describe are constantly updated, and the information they contain must be accurately available in print, and always available on the Web. Because of the Web, customers no longer accept the notion that the information they obtained when making a purchase decision was out of date, and there is nothing they can do about it. They will return the product.

Manufacturers must keep spec sheets accurate, to the minute (and print on demand, if necessary), and they must feed this information simultaneously to their Websites. Hence cross media. They must manage this data carefully and under closely-controlled technology, hence content management.

According to the study, Multi-Channel Communications: The Content Publishing Workflow Challenge, published by InfoTrends Dynamic Content Software Solutions Consulting Service (September 25, 2006):

• Over 50 percent of ALL content must be delivered through multiple channels today.
• Over 50 percent of all content is initially developed for electronic delivery first
• Over 60 percent of respondents indicated that XML will be used in their multi-channel solutions

It is important to absorb these claims and most printers remain isolated from this reality. It fundamentally changes the nature of the printing business. It changes the equation!

Content Management

Content management is the new reality for most document producers, certainly those who consider communication to be a mission-critical application. There are so many reasons to manage content, whether it is the simple economics of reuse, or the far more important task of controlling what messages a corporation (or other publisher) sends out to the world.

Both cross-media workflows and content management depend upon the robust application and reuse of metadata. Some of that metadata has to do with permissions and approvals. A lot of it has to do with production issues — the two are intertwined.

Perhaps the most significant and most controversial aspect of my work with CIP4 is my contention that metadata, broadly speaking, is undergoing an enormous change, and that this change must alter CIP4/JDF’s view of what it means to incorporate the creative/document originator community into the JDF fold.

In virtually all of the work I have done with the creative community throughout my consulting career, Microsoft Word has been a key software tool. With few exceptions, it is the tool whereby text enters a document, whether that document is built in QuarkXPress, Adobe InDesign, or in one of the several less popular page composition engines. Text is generally the most important element of documents, regardless of the often very important role of illustrations and page design generally. Without text, we rarely have a document of value. Microsoft Word is generally the application that generates that text.

Microsoft Word 2003 had a number of interesting features in terms both of metadata and XML support, but they were insufficient for most users (whether they were aware of those features or not — most were not).

The just-launched Microsoft Word 2007 is an enormous leap forward over previous versions. Its support for XML is extremely robust, but and far more importantly, Microsoft have introduced an important new output format, XPS, which plays brilliantly into JDF. Besides being an XML-based file format, it offers in-depth support for metadata — the kind of metadata that can effectively and efficiently inform a JDF workflow. The file format defaults to 100 defined production-oriented metadata definitions. But this is not because Microsoft believes that 100 definitions are nearly sufficient, but only to illustrate that the format is extremely extensible. At the same time, Word 2007 supports any and all existing metadata schema. Therefore a tremendous amount of information can now be carried forward from a Microsoft Word document.

So the question becomes: what will happen to this data? Clearly QuarkXPress and Adobe InDesign need to find a method to carry this data through the production process, and pass along that which is relevant into a PDF/JDF workflow and through to various post-production functions. I have absolutely no doubt that this will happen. And this is where tying JDF back into the creative production workflow becomes meaningful, essential and real.

At the same time, the work that Quark is doing with Job Tickets in QuarkXPress 7 is innately supportive of the same type of effort, even if not yet fully realized. We can reasonably expect that Adobe will move in much the same direction with InDesign in CS3, to be announced this spring. Significantly, Adobe is also pushing hard on its Mars project, quite analogous to XPS, although the impact of this effort remains to be seen.

Other Formats

While the formats discussed above are important and indicative of the issues to be addressed here, it is important to acknowledge that the graphic communications industry is beset with a range of alternate formats that significantly impact current and future workflows. PDF remains the industry-standard for file transmission, and the PDF format continues to evolve as a standard. Through the efforts of ISO and the Ghent Work Group not only will PDF become a standard, but so will it’s “children,” such as PDF-X and PDF-A. But there are other standards that remain wild cards, including the Open Document Format, which enjoys important industry support.

The point is that to support creative workflows, CIP4/JDF must be open to the changes in standards as they evolve — any meaningful solution that supports the creative community must be agnostic to specific workflows, but supportive of all key file formats that are themselves supportive of the goals of JDF.

The best strategy is not to make bets on winners, but to find a methodology to support the broad range of formats that are popular today, or will certainly emerge tomorrow.

Sidebar: XPS PrintTicket Specifications

As described above, I think that Microsoft’s XPS specification will be gaining widespread usage throughout the creative and document origination communities. So by way of example, I have included a list of all the PrintTicket parameters that are currently part of XPS. How will these be carried forward into Adobe InDesign and QuarkXPress, or taken directly to output where a Microsoft Office file is the only source for document output? In speaking with Rainer Prose, who heads CIP4’s technical committee, he said that in fact the codes featured within XPS are pretty much the same as those within JDF.

• DocumentBannerSheet
• DocumentBannerSheetSource
• DocumentBinding
• DocumentCollate
• DocumentCopiesAllPages
• DocumentCoverBack
• DocumentCoverBackSource
• DocumentCoverFront
• DocumentCoverFrontSource
• DocumentDuplex
• DocumentHolePunch
• DocumentID
• DocumentName
• DocumentNUp
• DocumentPageRanges
• DocumentRollCut
• DocumentSeparatorSheet
• DocumentStaple
• DocumentURI
• JobAccountingSheet
• JobAccountUsername
• JobPrimaryBannerSheet
• JobPrimaryBannerSheetSource
• JobBindAllDocuments
• JobBindAllDocumentsGutter
• JobCollateAllDocuments
• JobComment
• JobCopiesAllDocuments
• JobPrimaryCoverBack
• JobPrimaryCoverBackSource
• JobPrimaryCoverFront
• JobPrimaryCoverFrontSource
• JobDatatype
• JobDeviceLanguage
• JobDuplexAllDocumentsContiguously
• JobErrorSheet
• JobErrorSheetSource
• JobHolePunch
• JobID
• JobInputBin
• JobName
• JobNUpAllDocumentsContiguously
• JobOptimalDestinationColorProfile
• JobOutputBin
• JobOutputOptimization
• JobOwnerUsername
• JobPageOrder
• JobPageProtection
• JobPageStreaming
• JobPageStreamingPagesPerSubset
• JobPriority
• JobRollCutAtEndOfJob
• JobStapleAllDocuments
• JobURI
• PageBorderless
• PageCompression
• PageCopies
• PageDeviceFontSubstitution
• PageForceFrontSide
• PageImageableSize
• PageMediaColor
• PageMediaColorCIELabA
• PageMediaColorCIELabB
• PageMediaColorCIELabL
• PageMediaSize
• PageMediaSizeMediaSizeHeight
• PageMediaSizeMediaSizeWidth
• PageMediaSizePSHeight
• PageMediaSizePSHeightOffset
• PageMediaSizePSOrientation
• PageMediaSizePSWidth
• PageMediaSizePSWidthOffset
• PageMediaType
• PageMirrorImage
• PageNegativeImage
• PageOrientation
• PageOutputColor
• PageOutputQuality
• PagePhotoPrintingIntent
• PagePoster
• PageResolution
• PageScaling
• PageScalingOffsetHeight
• PageScalingOffsetWidth
• PageScalingScale
• PageScalingScaleHeight
• PageScalingScaleWidth
• PageTrueTypeFontMode
• PageWatermark
• PageWatermarkOriginHeight
• PageWatermarkOriginWidth
• PageWatermarkSizeX
• PageWatermarkSizeY
• PageWatermarkTextAngle
• PageWatermarkTextText

Copyright 2007 by PrintAction and Thad McIlroy.