What's the aim?
The aim for designers is to provide a digital content file that they can be confident will be printed predictably and correctly by the service provider, whether it's a commercial print job printed on one site, or a magazine ad placed in many publications and printed across the world.
The aim for service providers and publishers is to receive robust digital content files that they can be confident will run through prepress without requiring rework or causing errors and will allow them to meet (or exceed) customer expectations on press.
In both cases the key term is "process control."
Bad files, errors in prepress, unprintable data and untrustworthy proofs lead to human intervention, which in turn increases costs, errors and delay; Reliable content file delivery is an integral part of process control, every bit as important as waste management and automation (in fact it's a key pre-requisite for automation).
The immediately measurable goals are:
- To improve matches proof to proof, proof to press, and press to press
- To reduce processing errors in proofing and prepress
- To reduce the complexity and cost of customer education
Even when the files are handled on multiple sites, using different equipment, from many vendors
Oh ... and have it print well too!
What can I do in PDF/X that I can't do in PDF?
Nothing. The important point is that you can do a lot of things in PDF that are not appropriate for graphic arts use, and that can cause problems when outputting for high quality reproduction.
"PDF/X" can be thought of as a shorthand way of specifying most of what you need to tell somebody in order for them to create a file that's likely to print correctly when they send it to you, even if they don't understand the details of what it's doing for them.
Phrased slightly differently, think of all file formats used for file transfers as being compromises between flexibility and reliability (where reliability is defined as the final printed piece looking like your own proof).
At one end of the scale are application files like QuarkXPress documents. You can change those in whatever way you like if you have the application.
Unfortunately the receiver of a file can also change them accidentally rather too easily, and the results you get when printing are dependent on many factors in the environment in which that copy of XPress is running, such as fonts, PPDs and printer drivers.
At the other end of the scale you have copydot scans. Those will print absolutely as you expect, given the necessary provisos about having been prepared for the correct resolution and calibration -- that's part of why they are inflexible.
In between, in order of decreasing flexibility and increasing reliability, other options at other positions on the scale include PostScript, EPS, PDF, PDF/X and TIFF/IT. When I use a name like 'PostScript' in that list I mean the format in an otherwise unspecified way. It's always possible to push such a format towards the reliable end of the scale by using appropriate software to create it. In northern Europe many people have used ProScript, for example, which limits the options used in EPS files. A 'ProScript EPS' file might be placed on the scale somewhere between PDF and PDF/X.
Appropriate use of pre-flight tools on PDF can give you a 'reliable PDF' much closer to where PDF/X is on that scale. The point of PDF/X is that it gives you a convenient and well specified label to use when asking for such a 'reliable PDF' file.
So when should PDF/X be used?
Every transfer of files from one place to another, whether it's between designers sitting at adjacent desks, or from an ad agency to a magazine publisher, has an optimal position on this compromise scale, and there's a file format and workflow appropriate to that optimal compromise.
In some cases there will be additional selection pressure for a specific format, e.g. for compatibility with other processes, but as a general rule the optimal compromise for the supply of print-ready files between organizations will be toward the reliable and less flexible end of the scale. On the other hand, those two designers at desks next to each other would be crazy to use anything but native application documents.
That doesn't mean ads and other print ready files should be sent as copydot files -- that's too inflexible for most general transfers, although there are some instances where it's the right thing to do (typically between publishers and print sites).
For most inter-company print-ready transfers where the sender and receiver do not have a strong relationship in place, or where there's no intention of holding planning meetings for each job submission, either TIFF/IT-P1 or PDF/X will probably fit the bill best. That's why the 2001 edition of the SWOP specification recommends the use of those formats for digital delivery.
Why is PDF/X better than a job options file?
Over the last few years a number of people who receive PDF files have developed an approach that can work well under some circumstances. They save a set of job options in Acrobat Distiller, and send that to their clients. When files are created by relatively unsophisticated users it's far more likely that they will meet the receiver's quality requirements using such job options than they would otherwise.
The main drawback of this approach is that it requires all files to be created using Acrobat Distiller, and cannot help those people who want to use the increasing number of desktop applications that can export directly to PDF (Adobe Illustrator, PhotoShop and InDesign, QuarkXPress, MacroMedia FreeHand, etc.), or alternative PostScript to PDF conversion tools, such as Agfa Apogee Create, Apago Piktor or Jaws PDF Creator.
It also cannot be applied to the high-end graphic arts tools that can generate PDF directly, like Creo Brisque, Dalim TWiST, or OneVision Solvero. You might expect that the users of such equipment should understand the process well enough not to need such help, but everyone makes mistakes occasionally!
More importantly Distiller can only make a good PDF file if supplied with good PostScript to start with. It won't for instance, convert RGB images in PostScript into CMYK in the PDF. If you want to supply CMYK data for print, a job options file won't help you -- you need to control the creation of the PostScript as well.
A third, and rather minor, consideration is that a new job options file probably needs to be developed for every new version of Distiller.
It's also worth noting that the implications of some of the options available in Acrobat Distiller can be quite subtle, making it rather difficult for an individual company to develop the best possible configuration. On the other hand PDF/X has been developed over a period of several years by a broad-based team of users and vendors.
Why is PDF/X better than pre-flighting?
An alternative approach that has also been used successfully by some companies receiving PDF files is to work with their customers to encourage them to apply appropriate pre-flight checks before sending files. When the sender and receiver both use the same pre-flight tool it is sometimes possible for the receiver to supply a configuration file (e.g. a ground control for Markzware FlightCheck or a profile for Enfocus PitStop) -- with care this can eliminate a large proportion of problem files.
If the two parties involved are using different pre-flight tools, however, an explanation of the checks that should be made by the sender can be very complex. As more and more pre-flight tools are released with pre-built PDF/X configurations already available these explanations can be significantly simplified.
Note that PDF/X files should still be checked before transmission for all of those issues that cannot be addressed in a standard, such as the trim area and CT and LW image resolutions (see also "What's PDF/X Plus, below").
Why is PDF/X better than TIFF/IT?
TITT/IT-P1 has been held up as an example of a bullet-proof delivery format for some time, but results from at least one large prepress company show that PDF/X and TIFF/IT-P1 have very similar failure rates, both significantly better than those for generic PDF files.
PDF/X has a number of advantages over TIFF/IT-P1, such as:
- Better compression, including ZIP and JPEG for CTs, leading to much smaller files
- Mechanisms for marking trim and bleed areas, at least theoretically allowing automatic placement when compositing or imposing pages.
- Support for spot colors
- A free and widely used file viewer
- A mechanism for identifying the printing condition that the file was prepared for (e.g. SWOP)
- A flag to state whether the file has been trapped already
- The opportunity to make small last minute corrections when absolutely necessary (without it being so easy to make changes that they can be made accidentally)
- Generally cheaper tool sets with wider availability
Note that a new revision of TIFF/IT has been approved, and is expected to be published in late 2003, introducing a new conformance level -- TIFF/IT-P2. While this addresses several of the issues above, adopting it will require upgrades or replacement of existing TIFF/IT-P1 tools. If you're going to switch format for that, why not go the whole way and switch to PDF/X?
Unfortunately, encoding CT/LW data into a PDF or PDF/X file is likely to produce a file that RIPs and traps extremely slowly, and can show unwanted imaging artifacts if output at a different resolution to what it was produced for. Such files are sometimes referred to as "raster/raster" files, as opposed to the "raster/vector" files created by more normal desktop tools. The most recent position papers from the DDAP therefore recommend that ads created in tools that create a CT/LW format be transmitted as TIFF/IT-P1 rather than converted to PDF/X if possible, and the same advice is probably appropriate for non-advertising workflows too. Where a job does not start off as CT/LW, PDF/X is recommended instead.
Is PDF/X better than electronic delivery software?
Several vendors have brought out software that can create PDF files and transmit them to a print service provider in one step, with all creation parameters under the control of the file recipient.
In many ways such products are an attempt to address the same issues that PDF/X does, and in many ways they are just as successful in doing so. The main difference is that electronic delivery software requires the file submitter to obtain specific software matching that used by the recipient, although the matching is often achieved by the print service provider supplying the appropriate software to the print buyer. Where the required client software is expensive that's likely to occur only where there's an expectation of a long-term relationship between the two parties, while PDF/X is designed to be applicable even in one-off exchanges.
Where such software scores over PDF/X, however, is that at least some such products require less investment of money, and education by the file creator than a PDF/X workflow would. PDF/X is designed to be easy and cheap to create, but most products creating it still require the user to set several configuration items, often on several different screens. When the client software is inexpensive and a print service provider's customer base is unsophisticated, electronic delivery software may be a better choice.
Remember, however, that PDF/X and electronic delivery software are not necessarily mutually exclusive; the print service provider configuring the client software to supply to his customers may well choose to build his settings on PDF/X rather than to develop his own from scratch.
Is there just one PDF/X?
The PDF/X standards are designed to be very broadly applicable across as many sectors and geographical areas of the print industry as possible. They therefore form a very strong foundation for the development of specifications tailored more exactly for a particular sector (see "PDF/X Plus" below).
Even so, in the development of the standard it was found that there were two issues that divided requirements so deeply that a single PDF/X standard would not address the needs.
CMYK vs. Device Independent
In some print sectors it is expected that the supplier of digital content files to a publisher or print service provider will retain absolute control over the final appearance of the piece on the printed sheet; the printer will simply follow instructions. Over the years this expectation has led to the exchange of data in CMYK (and/or spot color data).
In other print sectors responsibility for the printed piece looking right is taken by the print service provider. Many working in these sectors are creating files in device independent color spaces (usually CIELab or RGB tagged with an ICC (International Color Consortium) profile). Several advantages accrue from this approach, including reduced file size and more flexibility for re-purposing of jobs. These advantages, especially the ease of cross publication of jobs between multiple print formats (newsprint, magazine, commercial print and digital print) and also to the web, are encouraging a number of people who currently transfer files entirely in CMYK to investigate the use of device independent data as well.
Those who work in the CMYK world felt that they required an absolute assurance that they would not be accidentally provided with device independent color data. It was therefore decided to produce PDF/X standards for both use cases.
Blind vs. Open Exchange
Some print jobs are ideally submitted to a print service provider with little or no technical discussion -- all negotiations being restricted to business matters. In the PDF/X standards this is referred to as "blind exchange". It's an important model when a single print buyer is sending work to many service providers, and where a single service provider is accepting files from very large numbers of buyers. The archetypal example is the transmission of publication ads, where the same ad may be placed in many magazines, and every magazine obviously includes ads from many sources. Detailed, individual discussions around every placement would be a significant barrier to increasing efficiency on both sides of the submission.
There are, however, situations where it's necessary to for the sender and receiver of a file (or file set) to have more discussion about how data should be prepared and exchanged, and in many of these cases there can be a requirement that the content of a single job is contained within multiple content files, possibly residing at different sites.
The combination of these two divisions led to a decision to create three PDF/X standards -- no standard for CMYK-only open exchange was needed because the two parties are in technical discussion anyway, and may therefore add their own further restrictions as to the construction of the files.
Note that this section is a summary of the rational behind the split into three standards. Unfortunately the groups involved were not in a position to set out that rationale in advance of PDF/X standards development work, and achieving worldwide consensus was not, initially, an easy task.
The PDF/X-1a standard addresses blind exchanges where all files should be delivered in CMYK (and/or spot colors), with no RGB or device independent (color-managed) data. This is a common requirement in many areas around the world and in many print sectors -- usually tied to an environment where the file supplier wants to retain maximum control of the print job. It's very hard to transmit data as RGB or Lab and still to include your own trap definitions, for instance.
The first PDF/X-1a standard, better referred to as PDF/X-1a:2001 is published as ISO standard 15930-1:2001. See below for details of how to obtain a copy, and for new revisions.
While some market sectors require exchanges with all color data already converted to CMYK, others are better served by transferring data in other spaces, such as CIELab or RGB with a profile attached. A number of publishers and ad agencies in Switzerland and Germany, for instance, have joined together to form the European Color Initiative (ECI) to develop workflows for delivering ads in RGB or Lab.
Pre-conversion to CMYK works best where there is a clearly defined CMYK color space to convert into. Remember that a set of CMYK values do not specify a particular color until you also define what device it's being printed on – the same CMYK values printed on gravure, flexo, or offset litho presses, or on a laser or ink jet printer are likely to look quite different. In the US publication market most printers are attempting to standardize on the SWOP specifications, and the US newsprint market is converging on SNAP. Thus an ad prepared for SWOP or SNAP is likely to produce the expected colors in most magazines or newspapers. Specifications like SWOP or SNAP are described as "characterized printing conditions".
Other sectors of the print market are more difficult to characterize – many commercial printers, for instance, claim to squeeze a larger gamut or better print contrast out of their presses than their local competitors. A wide range of paper stocks, in different colors, textures and coatings, obviously adds to the kind of color variation you'd see from the same CMYK values.
Several groups such as GRACoL and CGATS SC3, are cooperating to determine whether it's possible to generate characterizations for commercial print. In the meantime it's a little difficult to provide a file in CMYK to many commercial printers and have your proof match the final printed piece off their press without significant discussion or on-press adjustments.
The rise of non-impact digital presses, based on either ink jet or laser technology, also makes it difficult to send CMYK data without knowing exactly what press it will be run on, because presses from the different manufacturers may print the same CMYK values as very different colors. CGATS is investigating the possibility of standardized characterizations in this area too (CGATS SC6 TF2).
The same PDF/X-3 file may contain data in color-managed color spaces (such as Lab, CalRGB or using an embedded ICC profile), and other data in grayscale, CMYK and spot colors. The combination means that images can be included in a defined RGB space (for instance), while solid black text can be guaranteed to print in solid black without unexpected color fringing caused by color management spreading the black data to all the process separations.
The PDF/X-3 standard is a superset of PDF/X-1a (a PDF/X-1a file meets all of the requirements of PDF/X-3 except for the label that actually says "I'm a PDF/X-3 file"), and ISO has recommended that all tools designed to read PDF/X-3 should also be able to read PDF/X-1a files. The primary difference between the two is that a PDF/X-3 file can also contain color managed data.
A PDF/X-3 file may also be made explicitly for monochrome and RGB characterized print conditions, although RGB is likely to be very rare in practice. A PDF/X-1a file may only be made for CMYK characterizations.
The first PDF/X-3 standard, better referred to as PDF/X-3:2002 is published as ISO standard 15930-3:2002. See below for details of how to obtain a copy, and for new revisions.
Both PDF/X-1a and PDF/X-3 define file formats for blind exchange. There are many workflows where that's not required, and where a single file per job is not appropriate, but where some additional control over file formatting would be desirable to increase reliability.
The PDF/X-2:2003 standard meets this need, by enabling an "OPI-like" workflow. The OPI specification is not actually used, instead the "reference XObject" mechanism defined in PDF version 1.4 has been extended slightly to provide greater confidence that the correct subsidiary files have been located.
PDF/X-2 is designed to address exchanges where there is more discussion between the supplier and receiver of the file. Maybe the receiver already holds high resolution images to replace proxy images (low-resolution previews) in the supplied file.
There are a number of situations where it is envisaged that PDF/X-2 may prove useful. The only common theme between these is the use of a single 'master' file referring to others that will be rendered in the final output -- the business reasons that provide the value in that separation vary from case to case.
There are many occasions where an "OPI-like" workflow can provide value (e.g. to increase the response speed of design workstations), but which do not automatically lead to a requirement for PDF/X-2. If an OPI workflow is resolved entirely within a single company (or a division within a larger company) then PDF/X-2 is not necessary.
PDF/X-2 adds value where a set of several files should be exchanged between companies or divisions. It can also add value where the company running a purely internal OPI workflow has little control over the names of files used in that workflow, and where the ability to resolve conclusively between files from different sources but with the same name can help to avoid the use of the wrong image.
It is a superset of PDF/X-3, and will therefore allow device independent color spaces, like Lab and those base on ICC profiles, to be used, just like PDF/X-3. The rather confusing hierarchy running from PDF/X-1a through PDF/X-3 to PDF/X-2 is a historical accident caused by the development process in CGATS and ISO.
At the time of writing PDF/X-2:2003 has not yet been published -- that's expected to happen very soon, and the standard will be issued as ISO 15930-2:2003.
Developing and maintaining standards like PDF/X is always a bit of a balancing act. If the standard is based on too old a version of the PDF specification there will be complaints from users at the creation end of a PDF/X exchange that they can't include use the wonderful new features of the latest revision.
On the other hand, if it's kept right up with the leading edge of new PDF versions there will quite rightly be complaints from prepress companies at the receiving end of a PDF/X exchange that they can't handle the files without constantly upgrading to the most recent versions of their tools ... or even that the tools they need are simply not available yet.
Most vendors will support PDF/X in products that also support 'baseline' PDF. If the standard is based on too old a version of PDF it becomes hard for those vendors to maintain a code base that can simultaneously support the most recent versions of PDF and the one required for PDF/X.
If it isn't reasonably easy for vendors to support the standard there won't be any tools available. Falling into the kind of pitfalls described above for people creating and receiving files the standard means it wouldn't get used anyway, especially as the details of the file format you're working with tend to affect the whole of your prepress workflow.
The PDF/X task forces have worked on the premise that the standards should be placed ahead of the "comfort zone" of the average prepress shop, in order to help the industry to move forward, but behind the cutting edge of technology, so that they can actually be implemented in practical workflows.
A second difficult question is how often the standard should be revised. If that's too often and the standards becomes a moving target really doesn't help anyone, but one that falls behind common usage has also failed.
PDF itself doesn't stand still -- the full specification for version 1.5 has recently been released, but the current PDF/X-1a:2001 and PDF/X-3:2002 standards are based on PDF 1.3, published way back in 1999. If the industry can survive the PDF specification being updated roughly every two years, then that's probably roughly the right kind of interval between revisions of PDF/X as well.
New versions of PDF/X-1a and PDF/X-3, based on PDF 1.4 were approved as ISO standards in May 2003, and are expected to be published soon after this revision of the PDF/X FAQ.
At this point it should become clear why we've been recommending that the existing PDF/X standards be referred to as "PDF/X-1a:2001" and "PDF/X-3:2002" instead of just "PDF/X-1a" and "PDF/X-3." It gives a clear way to differentiate between those current versions and the new ones, which will be "PDF/X-1a:2003" and "PDF/X-3:2003."
One of the most obvious new features in PDF 1.4 was transparency. After much debate the decision was taken to prohibit the use of partial transparency in the 2003 revisions of PDF/X. That was mainly because of very significant differences between the results from different transparency flattening engines in different products; you can flatten a file in different design programs and RIPs and get very different results -- all of them apparently correct according to the PDF specification. In that situation, how on earth can you expect a proof that the creator of a PDF/X file makes before transmitting it to be a reasonable prediction of the final printed piece?
This doesn't stop designers using the transparency functions in their design applications -- it just means that the transparency must be flattened before making the PDF/X file for transmission. That also means the flattening must be done before making the final pre-transmission proof, because that should always be printed from the PDF/X file you're about to send.
The other big issue in PDF 1.4 was JBIG2 compression, which can be quite effective for copydot scans. JBIG2 is also prohibited in PDF/X -- not for philosophical reasons, but because of ongoing difficulties with access to intellectual property. All the patents flagged by the JBIG2 standardization group are theoretically available for free licensing, but getting those licenses signed can be very difficult and slow.
Of course PDF 1.4 also added some new security options, but the PDF/X standards all prohibit encryption, so those new security options are also prohibited.
For historical reasons there's a PDF/X-1:2001 (without an 'a') conformance level as well as PDF/X-1a:2001 in the existing standards. In the 2003 revision that conformance level has been removed. It is strongly recommended that PDF/X-1:2001 should not be used.
How and when should I start using the new revisions?
The 2003 versions of the standards require a conforming reader to read all files that comply with either the 2003 or the previous version. Thus a PDF/X-1a:2003 reader must be able to read both PDF/X-1a:2003 and PDF/X-1a:2001 files. On the creation side it's unlikely that you'll see any tools that only make 2003 files and not the currently published ones for some time to come.
If you're receiving files:
- Clarify your guidelines that describe what files you accept to state exactly which revisions of PDF/X you mean. If all you say is that you take "PDF/X-1a" don't be too surprised if some enterprising person sends you a PDF/X-1a:2003 file before you're ready for it. Make sure your sales people know this information too.
- It's safe for you to upgrade your tools as new versions become available to support the 2003 revisions, because they'll still be able to read the older files. You'll then be able to handle whatever your clients send to you. Start planning those upgrades as soon as suitable and trusted products are shipping.
- Don't forget to review your whole workflow before you say you accept 2003 files. Remember, you're opening the door to PDF 1.4 files (although most PDF/X files will continue to be PDF 1.3 compatible because of the prohibition of transparency and JBIG2 compression).
If you're sending the files:
- Don't start sending 2003 files until the printers and publishers that you work with say they can accept them.
- Keep an eye on new versions of the tools you use to create PDF/X files, and consider upgrading when you're happy with them. You don't need to rush into upgrading, though. Your printer or publisher will also be able to read the older files too, even after they've started to accept 2003 files.
Obsolete PDF/X standards
The first PDF/X standard published was PDF/X-1:1999, approved by ANSI as an American National standard in October 1999 (ANSI/CGATS.12). It was intended for blind exchange and, like PDF/X-1a, PDF/X-1:1999 was restricted to CMYK and spot color data.
The developers of the PDF/X-1 (without an 'a') standard were lead to believe at the time that there was a need to provide a mechanism to integrate 'legacy' file formats such as DCS and TIFF/IT into a PDF/X workflow. The standard therefore provides an kind of "internal OPI" mechanism, by which such files could be embedded within the body of the PDF file.
Very few implementations of PDF/X-1:1999 were ever released by vendors, the only known complete reading application being the Harlequin RIP. This standard should now be regarded as obsolete and is not recommended for use in any production workflows.
PDF/X-1:1999 was based on PDF version 1.2, so a new version, based on PDF 1.3, was developed. This was approved as PDF/X-1:2001 in April 2001, and published in December 2001 as an International Standard (ISO 15930-1:2001). As you can see, PDF/X-1 followed the same path as TIFF/IT which was released first as an American standard and then further developed and released as an international one.
This standard defines two specifications, or conformance levels, PDF/X-1:2001 and PDF/X-1a:2001. PDF/X-1:2001 (without an 'a') retained the "internal OPI" mechanism first defined in PDF/X-1:1999. PDF/X-1a:2001 differs in being based purely on PDF objects, and does not allow the use of embedded DCS, TIFF/IT files, etc.
While PDF/X-1a:2001 has been widely adopted, there are no known implementations of PDF/X-1:2001. Vendors are strongly recommended not to implement this conformance level.
What's PDF/X Plus?
The PDF/X standards are each designed to be applicable to broad ranges of the print industry world wide, across many geographical regions, print technologies and sectors. That means it's not possible for them to define all the appropriate limitations for any particular usage of PDF, such as minimum image resolution, minimum type size, bleeds, etc. The values appropriate for high quality magazine production would be completely wrong for newsprint, for instance.
It's therefore entirely appropriate that additional specifications be build by industry associations on top of the PDF/X standards, each constructed for a particular niche. Because these specifications use PDF/X as a foundation they are often called "PDF/X Plus."
One interesting observation made after the PDF/X standards were published was that the issues left to be addressed in PDF/X Plus specifications are the kind of things that people working in the graphic arts are already familiar with – image resolution, type size, bleed size, selection of a print characterization (usually guided by tone value increase (dot gain)). The standards themselves cover all the "propeller head" technical issues that deal more with the details of the PDF file format, and that most professionals in print would not be expected to necessarily think to include in specifications that they'd write themselves.
At the time of writing much of this activity appears to be converging on the Ghent PDF Working Group, originally formed by Enfocus Software. The Ghent Working Group now comprises many industry associations from across northern Europe, more recently joined by the IPA and the DDAP from North America. They have published eleven specifications, all based on PDF/X-1a:2001, and intended for use in advertising delivery to magazines and newspapers and for commercial print. More information on the Ghent Working Group may be found at www.ghentpdfworkgroup.org.
Who's accepting PDF/X-1a files?
Many publishers, pre-press shops and publication, commercial and packaging printers are represented on the CGATS and ISO PDF/X task forces, either directly, or through associations and trade organizations. Their representatives have worked hard to ensure that the standard will be suitable for their use.
Several PDF/X-1a compliant tools are now available -- mainly initially addressed at converting PDF files into PDF/X, and in pre-flighting such files. The DDAP maintains a list of available PDF/X applications at www.pdf-x.com.
The first known complete test-run of a PDF/X-1a ad was in early August 2001, and by the end of August an ad delivered as PDF/X-1a had been printed in a national American magazine (both handled by LTC/Vertis).
In September 2001 the SWOP calibration test kit was issued in PDF/X-1a.
In December 2001 the first known case of PDF/X-1a being used for the whole of a magazine transmission from publisher to printer was recorded (Wizards of the Coast -- Dragon issue 292).
The latest SWOP version recommends that all digital ads are supplied in either TIFF/IT-P1 or PDF/X-1a.
Many publishers across North America are now recommending that ads be supplied in PDF/X-1a, including Time, Inc, who provide a comprehensive guide to creation of good files at direct2.time.com.
Many of the member organizations of the Ghent PDF Working Group (see "PDF/X Plus," above) also indirectly recommend that jobs be submitted as PDF/X, because the current Ghent specifications are all based on PDF/X-1a.
And who's taking PDF/X-3?
A free PDF/X-3 verifier is available from www.pdfx.info.
Several tools for creation and verification of PDF/X-3 files are also available -- see the list at the same web site.
A number of the member companies of the organizations supporting the development of PDF/X-3 are evaluating the advantages of using it in their workflows, and some are already recommending, or even requiring, it for file submission.
Which PDF/X should I use?
That's obviously quite a few different PDF/X standards, but it's expected that any particular market will settle on one, or two at the most, of these.
If you're a print buyer or advertiser, or anyone else who is generating files to send to a print service provider, ask your service providers what they can work with reliably. If they don't suggest PDF/X but you think it would be advantageous to both of you then raise the idea, but there's no point in supplying files that you know your business partners can't work with. The only possible exception to that rule is if they just say that they accept "PDF" -- PDF/X files are perfectly compatible with the PDF specification, so if they take PDF they should also take PDF/X. Creating PDF/X files can be a useful self-discipline on the creation side in helping you construct workflows with appropriate pre-transmission validation steps.
If you're a receiver of files then you should be listening to your customers, but ultimately it's your choice what you accept, and you need to be confident that you can handle any new file format correctly before adding it to your list of acceptable inputs.
On both sides, your local industry associations may have published recommendations, some of which may incorporate PDF/X plus specifications. Each such specification will probably include clear guidance as to which of the PDF/X standards is likely to be best, and your association may also be able to provide assistance with implementation, or at least a forum to discuss issues that arise.
In the absence of this kind of advice:
For ad delivery and catalog work in North America PDF/X-1a is the obvious choice.
The same ads in Europe might be sent as either PDF/X-1a or PDF/X-3 -- check with your publisher.
Simple commercial print jobs, especially for quick print, will use the same selections as ad delivery -- PDF/X-1a in North America, and either PDF/X-1a or PDF/X-3 in Europe.
More complex jobs in commercial print and packaging markets worldwide may be best served by PDF/X-2 -- the standard has yet to be published and commercial implementations have not yet appeared on the market.
Work for output on digital presses, especially in anything approaching a blind exchange environment, would probably be best sent as PDF/X-3, because of the lack of appropriate print characterizations.
If you already have a workflow that's working reliably and efficiently then there is probably no immediately compelling reason to switch to using PDF/X. You may find, however, as new versions of your tool set are released, and especially when you find yourself needing to work with and educate new partners -- clients or service providers -- that it is simply easier to standardize on an appropriate conformance level of PDF/X.
Constructing pre-press workflows with PDF/X
As mentioned before, PDF/X is an application standard as well as a file format -- it defines the correct behavior for applications that read and write the files as well as specifying how the files themselves must be constructed. In simplistic terms a creation tool is compliant if the files it makes match the specification, but reading tools must be a little more careful.
If you're a publisher, printer or pre-press department and considering accepting PDF/X files, you must ensure that your whole workflow, including trapping, compositing partial-page submissions, imposition and RIPing, is PDF/X compliant, for both proofing and final output. That doesn't necessarily mean that every tool you use must be explicitly PDF/X compatible, although, if they are, it can obviously simplify matters.
Stating it like that makes it sound rather difficult to set up to receive PDF/X files, but there are only a few key issues that you need to keep close tabs on.
When files are initially delivered you should pre-flight them to ensure:
- They are compliant with the appropriate version of PDF/X
- They were created for the correct characterized printing condition, or one that you are comfortable transforming into your printing condition (if you asked for SWOP files because you're printing magazines in the US then you don't want files created for SNAP, for instance)
- The trim and bleed are appropriate for the job
- The resolution of images is appropriate
You may want to apply your own extra tests as well, but that's the core set.
For the rest of the workflow:
- If the file is noted as already being trapped you should not re-trap it. If it's marked as requiring trapping you should apply whatever traps are necessary.
- When rendering the file the embedded fonts must be used rather than any that happen to be installed in your RIP, on your print server, etc.
- When rendering the file overprinting should be applied as defined in the PDF specification. Note that many RIPs have switches that allow you to adjust overprinting behavior and the default settings may not produce the required output.
A number of free tools are available to assist in evaluation and tuning of your workflow:
- The Altona suite for PDF/X-3 workflows is available from www.eci.org (but note that this suite goes beyond testing PDF/X-3 compliance).
- The Kensington Suite for PDF/X-1a workflows is expected to be available soon from www.pdf-x.com.
- The Global Graphics PDF/X overprint test strip is available from www.globalgraphics.com.
The first two of these are complete physicals for your implementation and may take some time and expertise to evaluate completely. The last is a simple patch intended for inclusion on all jobs to ensure that proofs and prepress work apply overprinting correctly.
For more details, download the appropriate application note (see the next section).
What tools should I use for creating and processing PDF/X?
This FAQ does not include lists of commercial software for creating and processing PDF/X files. There are two reasons for that:
- It's not updated continually, and would therefore always be incomplete and out of date
- It's written by somebody working for a software vendor, who might therefore be open to accusations of bias in selection of products to include
Lists of appropriate software are maintained on web sites such as www.pdf-x.com and www.pdfx.info.
Compatibility between validation tools
When a number of parties agree to exchange files in any particular format it's obviously important that each file can be independently validated as conforming to that format.
Over the last couple of years a large number of validation and preflight tools have become available from several vendors. Many of those vendors have worked hard to ensure not only that their products correctly validate conformance with the PDF/X standards, but also that they show the same kind of error messages when files are not valid, and similar warnings for additional checks. Software being software, however, it's inevitable that any of these products may very occasionally deliver incorrect results – either accepting a file as correct when it's not, or reporting a file as invalid when it's OK. It's important to use a variety of such tools if any disputes arise over the validity of an individual file.
Perhaps the most likely area to trigger such reports is over the use of standardized print characterizations in the "Output Intent" structures in the file. Without diving into too much technical detail, the standards allow a file that contains only CMYK and spot color data, and which is intended for output matching a print characterization recorded in the registry on the ICC web site, to be created without an ICC profile in the output intent. Many validation tools therefore include an explicit check against a list of characterizations from that registry and will mark a file as non-compliant if no profile is included and if the characterization identifier in the file doesn't match a name in their list.
The ICC registry is not static, however -- new characterizations are added from time to time. In addition, it has recently been re-structured to make it much clearer which name should be used in PDF/X files for each characterizations. If a validation tool is shipped with a single list of characterizations it may report files using the new characterization names as invalid, even though they are not.
If you're creating or receiving PDF/X files you'll know what characterization you should be using, so when a validation tool fails a file purely on the characterization name, and you know that the value in the file is right, you should accept the file anyway.
Note also that many PDF/X validation tools can test for additional issues that are not set out in the PDF/X standards. These are obviously very useful at times, but should be disabled if all you care about is whether a file complies with the standard.
Isn't PDF/X raster only? It's just a wrapper for TIFF/IT isn't it?
It was possible to use PDF/X-1 (without an 'a') as a wrapper for TIFF/IT files, although that was not the intent of the design. PDF/X-1a and PDF/X-3 cannot be used in that way, and it is strongly recommended that you do not use PDF/X-1 (without an 'a') any more.
Can PDF/X do duotones?
The original ANSI PDF/X-1:1999 standard could not comfortably encode duotones in a way that would display correctly in the Acrobat Reader, or proof properly on a CMYK printer because it was based on a very old PDF version (1.2).
All of the PDF/X-1a, PDF/X-3 and PDF/X-2 standards are based on PDF 1.3 and later, which includes support for the DeviceN color space. Thus duotones and other multi-tones and bump plates can now be encoded, viewed and proofed reliably.
Who's developing these standards?
With apologies for the alphabet soup -- the PDF/X standards are being worked on by a number of organizations:
PDF/X-1a and PDF/X-2 were initially developed by Subcommittee 6, Task Force 1 of the Committee for Graphic Arts Technical Standards (CGATS SC6 TF1) at the request of the DDAP Association (Digital Distribution of Advertising for Publications) and NAA (Newspaper Association of America). CGATS has been tasked by ANSI (the American National Standards Institute) to generate national standards for the graphic arts in the USA.
The active members of the CGATS task force have varied slightly over time, but have included the following companies and organizations over the last couple of years of the development: Young & Rubicam, Western Laser Graphics, Webcraft Direct Mail, Vio, Vertis, Time Inc., RR Donnelley, Quebecor World, NPES, Noosh, Newspaper Association of America, Kraft Foods, Iris Graphics, Hewlett Packard, Heidelberg, Graphic Communications Association, Global Graphics (Harlequin), Fuji Photo Film, Enfocus, Eastman Kodak, DuPont Color Proofing, the DDAP Association, Dainippon Screen, Creo, Callas Software, Barco, Apago, Agfa, Adobe Systems.
At the international level PDF/X work is done by the International Standards Organization, Technical Committee 130, Working Group 2, Task Force 2 (ISO/TC130/WG2/TF2). This task force feeds international requirements into, and reviews and amends the work of CGATS, and the other groups working on PDF/X standards.
PDF/X-3 has been largely developed by the Swiss and German representatives to ISO, with additional funding from BvDM (the German printers' association), UGRA/EMPA (the Swiss standards and research institute) and IFRA (the international newspaper organization), and with active support from the ECI (European Color Initiative) and FOGRA (the German printing research institute).
NPES The Association for Suppliers of Printing, Publishing and Converting Technologies provides secretariat and technical support services both to CGATS and to ISO/TC130/WG2. Without their assistance and support it's unlikely that these standards would ever have been completed.
Why don't these standards come out faster?
The latest version of PDF available is 1.5 (Acrobat 6), and both PDF/X-1a and PDF/X-3 are based on PDF 1.3 (Acrobat 4). Even the 'new' revisions being published in 2003 are only based on PDF 1.4 -- why the mismatch?
Two important issues that come into play here are results of the fact that CGATS and ISO are open consensus organizations -- i.e. they operate by allowing everyone with expertise in the relevant area to make contributions.
One consequence of that is that they cannot work under a non-disclosure agreement from a third party, so it's not possible to see, for instance, the specification for a new version of PDF before it's officially published by Adobe. Thus the work to determine which pieces of functionality offered by a new version should be supported cannot start until the PDF specification is made public.
The second is that both organizations have very formal balloting processes to ensure that all interested parties are given the chance to express opinions. From submission of a new revision of PDF/X for the final voting process to publication usually takes of the order of twelve months.
A third consideration is that it's very difficult to determine the real-world implications of a new version of PDF on professional print production without real experience. It took some significant time, for instance, to evaluate the impact of partially transparent objects in PDF 1.4 on processes such as trapping or color management for proofing, and to understand the effects of different implementations of rendering workflows for those objects.
Finally, and most importantly, it's inappropriate to require all users to keep on the cutting edge of technology for all stages in their workflows in order to accept a standardized file format. It usually takes some time after the release of a new version of PDF to generate the tool sets that can handle them, often even longer before those tool sets become stable enough to rely on in a production environment, and longer still before it's reasonable to assume that they should be in common use in prepress and print service providers.
The PDF/X standard was developed as a focussed subset of PDF for the graphic arts industry, but PDF is flexible and powerful enough to provide great value in other markets too. An initiative started by AIIM International (the Association for Information and Image Management, International) and NPES in the USA, and now moved into ISO (under TC171/SC2) is developing a format called PDF/A which is intended to become an equivalent subset for long-term archival of documentation. Depending on the results of decisions made as it is developed into an International Standard, it may also become the format of choice for internal use in enterprise, legal and government document exchange. More information is available from www.aiim.org/pdf_a.
Where can I get more information?
Published and final draft (DIS) ISO standards may be purchased directly from ISO or from national standards bodies around the world (NPES in the USA -- www.npes.org, BSI in the UK, DIN in Germany, etc.)
CGATS information is available at the web site for NPES The Association for Suppliers of Printing, Publishing and Converting Technologies (www.npes.org/standards/cgats.html). Copies of several supporting documents, required for developers to implement PDF/X in their products as well as the standard itself, may also be downloaded from this site.
CGATS SC6 has also created application notes covering some issues which were not appropriate for inclusion within the standards themselves, but which are designed to assist developers and systems integrators. These are available from www.npes.org/standards/workroom.html. Note that this document is revised periodically to keep abreast of new revisions of the standard or simply to convey additional information as it is discovered to be important to the target audience.
More information on PDF/X-1a is available at www.pdf-x.com, www.ipa.org and www.ddap.org.
More information on PDF/X-3 is available at www.eci.org, www.pdfx3.org and www.pdfx.info.
I'm an application developer -- what should I develop for?
If you're developing tools for page design, pre-flight, file conversion or pre-press I'd strongly recommend that you take the time to investigate PDF/X fully. Depending on your target market sector you should consider developing support for PDF/X-1a:2001, PDF/X-3:2002 and/or PDF/X-2:2003.
If you're already supporting one or more of those versions, keep an eye on market acceptance of the new revisions -- PDF/X-1a:2003 and PDF/X-3:2003. If you're starting from scratch you might consider adding both the current and the new revisions together. Given the level of market penetration and understanding of the PDF/X standards as a whole it's probably unwise to develop only for the new revisions at this time.
Developing to PDF/X-1:1999 or PDF/X-1:2001 is extremely unlikely to be useful.
How can I get involved?
CGATS welcomes representatives from vendors, user organizations and users themselves. SC6 works on standards for digital file exchange and therefore covers market segments from ad agencies through pre-press and repro companies as far as printing companies. If you think you can help to build better standards please contact NPES or me (firstname.lastname@example.org, email@example.com). Outside the US, you'd also be welcome in the ISO PDF/X task force. The same contacts apply.
If you wish to contact the Swiss/German group working on PDF/X-3 contact Olaf Drümmer (firstname.lastname@example.org), or Stefan Brües (email@example.com).