IT for creative professionals and cross-channel publishers
      Forgot password?   Auto-login ON? | Register

QuarkXPress 7: Job Jackets

By: Erik Vlietinck - Last Updated: Fri 30 June 2006

Introducing the Brain Friendly Knowledge Library

Learn software with zero effort. Get to know the ins and outs of publishing software and technologies. Quickly learn about the true benefits of a solution.
Wherever you are, whenever you want.

Quark released QuarkXPress Passport only a few weeks ago. QuarkXPress 7 is filled to the rim with new features and improvements, and so we decided to cover each and every one of them. After all, QuarkXPress may have lost some market share to Adobe’s InDesign CS2, but it still is considered the industry standard desktop publishing application by most desktop publishers. With QuarkXPress 7, Quark seems to have a winner on its hand. This first of a series of in-depth reviews of the new QuarkXPress covers a brand new feature that is bound to make some heads turn: Job Jackets.

Based on the Job Definition Format (JDF), Job Jackets is one of the most powerful and interesting novelties in QuarkXPress 7. Job Jackets are a desktop publisher’s dream come true, because they allow a job manager (the client, a prepress professional, or the DTP’er herself) to define the parameters which must be respected throughout the DTP workflow inside QuarkXPress. Job Jackets are sort of a preflighting tool before the work has finished and errors have found their way in the layout and the project.

As Job Jackets are based on JDF job tickets, they are completely open, i.e. they are written and saved in XML, and therefore usable by JDF compatible systems and devices. The fact that Quark dedicated a complete chapter to Job Jackets is proof of their complexity, but the reality is that Job Jackets are not more complex than any other technology used in modern desktop publishing environments. Preflighting applications like Enfocus PitStop Pro or MArkzware FlightCheck Pro are not less complicated, but we’re used to those, and that’s what’s different. Nevertheless, Job Jackets do have many different specifications and rules that can be ‘filled in’.

In QuarkXPress 7, you can start a new project based on an existing Job Jacket. That is nice to know, but where do you get hold of such Jackets? The short answer is that you needn’t bother; in most cases, a job definer will have created such a Jacket for you and you can start working right away. In some cases, the job definer will be you, and you will have to create the Jacket.

Job Jackets have Job Tickets have...

In workgroup environments, the creation of such a Job Jacket is a task with great responsibility. For desktop publishers who work on their own, a Job Jacket may still make life easier because they can be created in QuarkXPress 7 itself. The benefit to workgroups is readily apparent. To individuals it may be less apparent, but there is a benefit nevertheless: you can make sure that you won’t design a layout outside the scope and capabilities of the output device.

Each Job Jacket has ‘Resources’—project settings, layout settings, output sepcifications, etc—and these are organized in Job Tickets. Each Job Ticket can be created first as a template. Later on, the actual Job Tickets—you can have only one for each kind in each project—can be based on the templates. Once the Job Ticket template has been built, you can start new projects using that template without further thinking about it. All you will have to do, is regularly compare what you have been building to the Ticket.

If you do it right, you will find yourself laying out your document within the specifications of the Job Ticket. If you do it wrong, you’re still early in the process to correct things without having to search for the problem and perhaps break more than you intended.

QuarkXPress 7 Job Jackets flexibility

Job Jackets can be embedded and linked in a QuarkXPress file. They can be shared by projects as well. But there’s no live link between a Job Ticket and its template. So, when you change a template, the future Job Tickets will change, but not the existing ones. This actually makes a lot of sense. If you could ‘update’ existing Tickets to comply with a changed template, your running jobs would represent a moving target for the desktop publisher working on the project. And that’s not what we want.

In my opinion, and as far as I have worked with Job Jackets in QuarkXPress 7, this feature is very well thought out, and has been implemented in what seems to be the best way possible. Especially the creation of Job Jackets and Job Ticket templates has been thought out very well. There is a Job Jacket Manager for the purpose and that tool is as intuitive as it can be, although you still need the manual the first time you set up your Job Jacket and Ticket templates.

QuarkXPress 7 Job Jackets

The reason for this is quite simply that Job Jackets include not just resources, but also rules—policies—that you have to set up first. These rules must be embedded in rule sets, and through a hierarchical system of forms and dialogue windows, you’ll end up with a working Job Jacket. The whole process can move very fast if your requirements are simple, but can also take quite some time upfront when the needs are complex and manifold.

Still, the end-result that I came up with in under half an hour, was very impressive. My Job Jacket checked for overset frames, spot colors being used in text frames, the page being of size A4, etc. It wasn’t a complex Jacket as I am alone and not forced to accommodate a workgroup’s requirements, but it still was quite impressive to see how obvious most of the settings were. The most impressive was the evaluation, of course, which closely resembles a preflight with PitStop Pro or FlightCheck.

Flexibility and scalability seem to be the strongest selling points of QuarkXPress’s Job Jackets. Flexibility as there can be three sorts of Job Tickets: the templates, which are ‘master’ tickets; the active ticket which is a copy of a template linked to a project; and the deferred ticket which is a job ticket that was once associated with a project but is no more.

Projects indeed need not start from a Job Jacket with Tickets, but Tickets can be linked to a project when you have already begun working on it. This leaves ample room for situations where you start working (because of deadlines) ahead of the job definer, which in this case could for example be a printer who wants to hand over a ticket to you so he’s certain your file will print correctly on his press.

Scalability is inherent to the system and the fact that the result is a simple XML document. JDF was conceived to be scalable, and the Job Jacket system follows that reasoning. It can serve an individual desktop publisher, but by expanding on Jackets and the Tickets within, it can just as easily serve large workgroups in a newspaper publishing environment, or as a ticketing system in an ad agency.

To cut a long story short: the QuarkXPress 7 Job Jacket system is an elegant solution to a problem that until now lived well outside your average DTP application. I must admit I find the Job Jacket solution a better and more focused answer to workflow problems than Adobe’s XMP solution which is really a Swiss pocket knife. Unfortunately, Adobe relies on third parties to fill in the XMP blanks.

While XMP is perfectly capable of supporting JDF workflows as well, the Job Jacket solution is readily available in QuarkXPress 7, and the XMP solution is waiting for a third party to come up with a structured system to perform the same tricks as QuarkXPress’s Job Jacket system.

No

Share
 

rss feed

  • twitter_48
    Updates on Twitter
end of columns