On May 9, I was one of several speakers at an Innodata-Isogen event, “Future Tense – Emerging Trends in Publishing Workflow Management.” They have now posted the presentations and accompanying podcasts. Registration is required, but there are a number of interesting presentations and case studies, including ones from The New Yorker, Houghton Mifflin, Time Out New York, and Harvard Business School Publishing.
Day: May 25, 2006
(Full disclosure: I’ve consulted many times with Quark and with Adobe, and was specifically hired by Quark to prepare a brochure called QuarkXPress 7 for Output Service Providers.)
I think that QuarkXPress 7 is an important release for Quark, its customers, Adobe and the publishing industry. We’re well past the days of “feature wars,” so, for example, the addition of OpenType support, something first offered in InDesign 1.5 five years ago, is not shaking my world. There is also new support for transparency, improved color management and PDF support, and various other goodies that you’d expect to find in your Christmas stocking, but none of these are anything much more than “overdue.”
What’s most important from my perspective is Quark’s forward strides in supporting improved publishing workflows, the last frontier for the electronic publishing industry. Two new features stand out in this respect. One is “Job Jackets” and the other is JDF (Job Definition Format) support.
According to CIP4 (www.cip4.org) the non-profit industry association pushing JDF, “JDF is a comprehensive XML-based file format and proposed industry standard for end-to-end job ticket specifications combined with a message description standard and message interchange protocol.” Along with its earlier incarnations, JDF has been in the making for more than 15 years now. It has very broad industry support – hundreds of vendors have added JDF functionality to hundreds of hardware and software products. That being said, it’s still a challenge to find a robust JDF-based publishing installation in the field. The main reasons for this are the complexity of the standard and the need for all of the players in a broad publishing workflow to be in the game – if one key component lacks support the JDF flow grinds to a halt.
Adobe have added JDF support to Acrobat, which is to some extent accessible from InDesign, but Quark has moved ahead of Adobe by building JDF support directly into the page layout application, independently from PDF. No doubt Adobe will follow suit in the next version of InDesign, expected early next year, so the issue is not so much who got there first. But having what is still the mostly widely-used page layout application in the world throw its support behind JDF is of key importance at this time when broad-based JDF adoption by the publishing industry is still in question.
Quark uses JDF also in its Job Jackets feature. A Quark Job Jackets file contains all of the rules and specifications necessary to describe a QuarkXPress project. A Quark Job Jackets file can include specifications for colors, style sheets, trapping, and color management as well as picture color space, format, and resolution. The file can also include information such as the page size, number of pages, and contact information for the people involved with a job. And the file can include rules that specify configurations for font sizes, line thicknesses, box backgrounds, and other project elements. Workgroups can obtain consistent output by using Quark Job Jackets to share specifications across workstations.
For me the most intriguing benefit of Quark Job Jackets is that it re-invents the concept of preflighting. Preflighting has always been a post-process step: create your file, and then find out where you screwed up. With Job Jackets users can ensure that a print job adheres to its specifications from the moment it’s created, and that it continues to adhere to those specifications all the way through the production process until it rolls off the press. I’ve long maintained that page designers would not be able to perfect their process until it was possible to prevent errors, rather than to correct them after the fact. I’m certain this approach will fast become the production norm.
It’s interesting to me that searching through Google News the day after the Quark 7.0 launch in New York, there’s nary a mention in the mainstream press. Neither the New York Times nor the Wall Street Journal seem to have found it worthy of coverage. To me this reflects the new prevailing “wisdom”: Adobe has won the page-layout wars (and every other war for that matter), so Quark’s announcement isn’t newsworthy. I think they are underestimating the importance of QuarkXPress 7.0. Only time will tell.
