pdf document library c# : Extract pdf form data to xml software SDK dll winforms wpf .net web forms pdfx_faq_english_nov051-part1953

PDF/X Frequently Asked Questions (Oct 2005)
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved 
Page 9 
your business partners can’t work with, though. 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 (see “What’s PDF/X Plus?”). 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, you should send a PDF/X-1a file if you specifically wish to send a file 
that contains only CMYK and/or spot color data (but see “Who’s taking PDF/X-3?”). Examples where that 
would be necessary include a requirement to trap all data before submission, or a perceived need for a specific 
black generation in all images in a job.  
For ad delivery and catalog work in North America PDF/X-1a:2001 is the obvious choice.  
The same ads or catalog entries in Europe might be sent as either PDF/X-1a:2001 or PDF/X-3:2002 – 
check with your publisher. Unless a publisher specifically requests PDF/X-3 it’s probably safer to supply 
Commercial print jobs intended for offset lithography, especially for quick print, will use the same 
selections as ad delivery – PDF/X-1a:2001 in North America, and either PDF/X-1a:2001 or 
PDF/X-3:2002 in Europe. 
Commercial print jobs intended for digital print tend to benefit more from submission as PDF/X-3 than 
those for offset presses. This is partly because of the lack of widely accepted print characterizations 
designed specifically for digital presses. More importantly digital press front ends very commonly 
include relatively sophisticated color management capabilities when compared with plate-setter RIPs for 
conventional print work. 
Other print technologies and industry sectors are less clear-cut at this time. A number of groups around 
packaging etc are developing their requirements and solutions, such as the packaging committee in the Ghent 
PDF Work Group. 
The preceding recommendations do not include comments for areas outside of Western Europe and North 
America because I don’t have the data necessary to make such recommendations. Input for other areas would 
be welcome. 
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, that it is easier to standardize on an 
appropriate conformance level of PDF/X 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. 
18. 2003 revisions 
New versions of PDF/X-1a and PDF/X-3, based on PDF 1.4 were published as ISO standards in 2003. At this 
point it should become clear why I’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 versions and the new ones, which are “PDF/X-1a:2003” and “PDF/X-3:2003” 
(published as ISO 15930-4:2003 and 15930-6:2003 respectively). 
After much debate the decision was taken to prohibit the use of One of the most obvious new features in PDF 
1.4, PDF 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? 
Extract pdf form data to xml - extract form data from PDF in C#.net, ASP.NET, MVC, Ajax, WPF
Help to Read and Extract Field Data from PDF with a Convenient C# Solution
how to save filled out pdf form in reader; can reader edit pdf forms
Extract pdf form data to xml - VB.NET PDF Form Data Read library: extract form data from PDF in vb.net, ASP.NET, MVC, Ajax, WPF
Convenient VB.NET Solution to Read and Extract Field Data from PDF
how to fill pdf form in reader; saving pdf forms in acrobat reader
PDF/X Frequently Asked Questions (Oct 2005) 
Page 10 
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved. 
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 PDF/X task forces have no intention that the prohibition of live transparency in PDF/X will continue 
forever; see “Future plans” for more on this. 
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.  
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 (see “Obsolete PDF/X standards”). 
19. Should I start using the 2003 revisions? 
It was extremely useful for the standards community to develop the 2003 versions of the PDF/X-1a and 
PDF/X-3 standards. In many ways the new versions are improvements over their predecessors as they 
encapsulate a lot of clarifications in response to developer and user queries. On the other hand, widespread use 
of the 2003 versions complicates the marketplace at a time when many users are still learning their way 
through constructing PDF/X workflows. 
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 2001/2002 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 
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. You can 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 explicitly say they can 
accept them. Do not assume that “PDF/X-1a” implies both the 2001 and 2003 versions, for instance. 
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. 
As a general rule, the benefits to a user of creating or receiving files using the 2003 standards are outweighed 
by the disadvantage of the extra confusion that supporting them may cause. For both senders and receivers of 
files the default selection should therefore be PDF/X-1a:2001 or PDF/X-3:2002, rather than the 2003 variants. 
This matches the decision made by the Ghent PDF Work Group for their 2005 specifications. 
C# PDF Convert to SVG SDK: Convert PDF to SVG files in C#.net, ASP
to convert PDF document into SVG image format. Here is a brief introduction to SVG image. SVG, short for scalable vector graphics, is a XML-based file format
how to fill out pdf forms in reader; make pdf form editable in reader
C# Word - MailMerge Processing in C#.NET
DOCXDocument document = DOCXDocument.Open(); //Create data from xml file DataSet ds = new DataSet(); ds.ReadXml(xmlFilePath); DataTable dt = ds.Tables[0]; int
change font size pdf form reader; extract data from pdf form to excel
PDF/X Frequently Asked Questions (Oct 2005)
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved 
Page 11 
20. Future plans 
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 tools. 
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. 
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. If the standard 
falls into the kind of pitfalls described above for people creating and receiving files then 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 consistently worked on the premise that the standards should be placed ahead of 
the “comfort zone” but within the capabilities of the average prepress shop, in order to help the industry to 
move forward. On the other hand, they must be behind the cutting edge of technology, so that they can actually 
be implemented in practical workflows. Over time both the comfort zone and the cutting edge move forward; 
what was viewed as difficult or impossible a few years ago is commonplace today. Something that seems too 
complex today is likely to become relatively easy by the end of this decade. 
Printer capabilities
Asecond difficult question is how often the standard should be revised. If that’s too often, so that the standards 
become moving targets, it really doesn’t help anyone. On the other hand, standards that fall behind common 
usage have also failed. 
PDF itself doesn’t stand still; the full specification for version 1.6 has been released, but the PDF/X-1a:2001 
and PDF/X-3:2002 standards in widespread use 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 the interval between 
revisions of PDF/X should not be too long. 
At the moment, the most pressing piece of new functionality that is not supported in PDF/X is live 
transparency. It’s slowly becoming common for designers and print buyers to complain that they “can’t use 
PDF/X” because they need to use transparency. While it is possible to use PDF/X after flattening transparency, 
that raises the possibility of unwanted artifacts and color conversions. On the other hand, it’s also common for 
printers and publishers to demand that transparency be kept out of PDF/X because they can’t print it reliably. 
Those points of view obviously reflect the current state of the industry. The rather slow speed of development 
of ISO standards, plus the time required to bring out applications supporting the standard once it has been 
finished, means that the standards committees need to be looking several years into the future. Prepress 
VB.NET Image: VB Tutorial to View Document Online with Imaging Web
files, including png, jpeg, gif, tiff, bmp, PDF, Microsoft Word from your MS Visual Studio and drop to your form; will demonstrate how to use a data-bound drop
how to save a filled out pdf form in reader; export pdf data to excel
C# Image: Tutorial for Document Viewing & Displaying in ASP.NET
list's designer and change the Data Source to HTML buttons, btnFitToWidth and btnViewFullSize to your form; & profession imaging controls, PDF document, tiff
how to save fillable pdf form in reader; how to extract data from pdf file using java
PDF/X Frequently Asked Questions (Oct 2005) 
Page 12 
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved. 
equipment has developed significantly since the decision was taken to prohibit the use of live transparency in 
the 2003 PDF/X standards. Amongst other things, RIPs capable of processing PDF files containing 
transparency on-the-fly are now much more widespread in the market. That trend is expected to continue over 
the next year or so. In addition, the transparency rendering engines in modern RIPs from different vendors (and 
the flattening engines in design tools) are now producing output that is much more similar to each other than 
was the case a few years ago. 
The decision has therefore been taken to develop a new PDF/X standard that allows live transparency, with 
appropriate restrictions to minimize variation between different rendering engines. It will be based on PDF 1.6. 
At the same time, the committees have recognized that the existing PDF/X-1a and PDF/X-3 standards have 
significant value which will not decrease for a considerable time. In order to avoid confusion, therefore, the 
new PDF/X standard will not be a revision of PDF/X-1a and/or PDF/X-3, but will be known as PDF/X-4. It 
will be a superset of PDF/X-3, in that it will allow the same kinds of usage of device independent color spaces. 
There will also be a new PDF/X standard based on the idea of OPI-like workflows, in a similar way to 
PDF/X-2. It’s likely that this standard will go further than PDF/X-2 in that it will also allow the metadata 
describing the characterized printing condition for which the job was created to reference an ICC color profile 
that is not embedded in the PDF/X file. This standard will be known as PDF/X-5. 
Both PDF/X-4 and PDF/X-5 are likely to be published in 2007. 
21. 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 persuaded 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; even current versions of the Harlequin RIP do not support 
PDF/X-1:1999 was based on PDF version 1.2. When the PDF/X work transitioned from the American national 
standards bodies to the International Standards Organization (ISO) a new version, based on PDF 1.3, was 
developed. This was published as PDF/X-1:2001 in April 2001 in 2001 (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.  
ISO 15930-1:2001 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. 
22. Which characterized printing condition should I label files as using? 
APDF/X file is always labeled with the name of the characterized printing condition that was assumed when 
the file was created. It’s intended to provide early warning for the print service provider if a customer sends a 
file that is not suitable for his presses. It also ensures that the supplier and the receiver can set up their proofing 
environments in a compatible way so that they see the same results. 
While the label is just a flag that describes how the file has been created, you must be careful to ensure that the 
label you apply matches how the file was made. If it includes CMYK images separated from RGB or Lab, the 
label in the resulting PDF/X file must match the profile that you used to do the separation. It would be 
extremely difficult for preflight software to validate your selection of a label after the event (most don’t even 
try) so you must use care in assigning the correct value. 
C# Image: Tutorial for Collaborating, Marking & Annotating
To save drawn annotations separately from image data as XML a server button) onto your form and name powerful & profession imaging controls, PDF document, image
export pdf form data to excel spreadsheet; online form pdf output
XDoc.HTML5 Viewer for .NET, All Mature Features Introductions
to search text-based documents, like PDF, Microsoft Office separately from original document as xml files. freehand signature, text signature and data signature
fill in pdf form reader; pdf form data extraction
PDF/X Frequently Asked Questions (Oct 2005)
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved 
Page 13 
The best choice of PDF/X-1a vs PDF/X-3 is made as a result of discussions with the print service provider or 
publisher that you plan to send the job to, and exactly the same is true of selecting a characterized print 
condition. Unfortunately, it’s rather common to find that printers and publishers are not (yet?) in a position to 
supply the appropriate data. In these cases, you could do worse than to select an entry from the following table, 
based on the geographical location of the printer, the print technology and the paper that will be used: 
North America 
Dependent on paper stock: 
Types 1 & 2 (coated): FOGRA27 
Type 3 (LWC): FOGRA28 
Type 4 (uncoated): FOGRA29 
Dependent on paper stock: 
Grades 1 and 2 (premium coated): FOGRA27 
Grade 5: CGATS TR 001 (SWOP) 
Uncoated: FOGRA29 
Dependent on paper stock: 
Type 1 & 2 (coated): FOGRA28 
Type 4 (uncoated, white): FOGRA29 
Type 5 (uncoated, yellowish): FOGRA30 
Dependent on paper stock: 
Grade 5: CGATS TR 001 (SWOP) 
Uncoated (white): FOGRA29 
Uncoated (yellowish): FOGRA30 
The designations in this table (“FOGRA27”, “IFRA30”, “CGATS TR 001” etc) are all taken from the registry 
of characterized printing conditions maintained by the ICC at www.color.org/drsection1.html
.The descriptions 
available at that web site provide more detail on the conditions under which the characterization data was 
measured, and the standards and printing conditions that it is intended to represent. That registry is subject to 
change as improved characterization measurements are made, the recommendations above are based on the 
characterizations registered at the time of writing. 
All of the FOGRA characterizations are based on the ISO 12647 standards. The full text of those standards is 
available from the same sources as the ISO standards for PDF/X (see “Where can I get more information?”). 
There are efforts currently underway to generate characterizations for printing to GRACoL  recommendations. 
Once that work is published the new characterizations should probably become the recommended selection for 
sheet-fed work to be printed in North America. They are expected to become available as “CGATS TR 004”.  
This section does not include comments for areas outside of Western Europe and North America because I 
don’t have the data necessary to make such recommendations. Input for other areas would be welcome.  
Once you’ve selected the characterization for which you will prepare a file, you may also be asked to fill in a 
couple of fields in the PDF/X file itself. Some creation applications, such as Adobe Acrobat 7 and Jaws PDF 
Creator, handle this semi-automatically for you; you select a characterization, or a profile based on that 
characterization, and the tool will fill in the fields for you.  
Other applications, such as Adobe Acrobat 6, require that you manually enter the data yourself. In order to 
enable automated pre-flight checking at the publisher or print service provider the “OutputConditionIdentifier” 
field must be filled in exactly correctly: 
If you’re following the recommendations in the table above enter the designations used in the table above 
(note that SWOP should be entered as “CGATS TR 001”).  
If you’re using another characterization from the ICC registry, enter the “Reference name” from the 
If you’re using a non-standard characterization, enter the name supplied by your print service provider (if 
there is one). If not, use a very short description of the characterization.  
Some software will default to using “Custom” for this field. Some print service providers and publishers 
now treat any file set to “Custom” as suspect; it means that the file creator didn’t really know how they 
should create the file, and that the CMYK data may need adjustment. If that’s truly what you mean, then 
VB.NET Excel: Use VB.NET Code to Convert Excel Doc to SVG Vector
short for Scalable Vector Graphics) is an XML-based vector of stream which contains the image data of the For instance, you can convert Excel to PDF and render
how to fill in a pdf form in reader; filling out pdf forms with reader
DocImage SDK for .NET: Document Imaging Features
types, including EXIF tags, IIM(IPTC), XMP data, and TIFF users to add metadata in the form of EXIF TIFF Type 6 (OJPEG) encoding Image only PDF encoding support.
export excel to pdf form; extract data from pdf to excel
PDF/X Frequently Asked Questions (Oct 2005) 
Page 14 
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved. 
by all means leave it as “Custom”; if you don’t want your data re-separated you would do better to change 
the value to something more meaningful. 
The second field that you may be asked to fill in will normally be referred to either as “OutputCondition” or 
“Info”. The value you use here should be a more complete description of the print condition, if you feel that the 
recipient of the file will benefit from the additional information. It may be useful to include anything special 
about the embedded profile (if there is one), such as the maximum total ink coverage, or the fact that it’s 
intended especially for high- or low-key images. If there’s nothing specific that you want to convey, you don’t 
need to fill in this field at all. Note that the prepress workflow used by the recipient of the file may not display 
this data to the operator, so if it’s vital that they know the information you should also include it as a comment 
on your order. 
23. How do I get an ICC profile for use with PDF/X? 
In order to use the characterizations recommended above, you’ll have to obtain an ICC color profile. In some 
cases that must be embedded within the PDF/X file itself, but even when that’s not necessary you’ll probably 
need a suitable profile for separation to CMYK, or for hard- or soft-proofing. (See “What do the PDF/X 
standards restrict?” for notes on when the profile must be embedded). 
The registry at color.org includes measurement data for print characterizations (or a description of how the 
measurement data may be obtained). It does not currently include any downloadable ICC profiles for use in 
setting up proofing devices, or for embedding within PDF/X files. At the time of writing there is no centralized 
repository for ICC profiles, although discussions are under way to try to pull that together.  
In the mean-time, profiles are available from the following locations: 
FOGRA up to 37: 
FOGRA 33-38 
IFRA characterizations: 
CGATS TR 001 (SWOP)  Neither CGATS nor SWOP have made an official ICC profile for this 
characterization. A number of applications come bundled with a suitable profile, 
usually labeled as “SWOP” or something along the lines of “US web-printing”. 
The quality of these profiles varies somewhat, but almost all are good enough at 
least for less demanding work. Be careful to read the license agreement for these 
profiles before using them with applications other than the ones with which they 
were supplied. 
Wherever you obtain a profile from, you should make your own evaluation of the results it provides with your 
own equipment before using it in production. Profiles from ECI, FOGRA and IFRA are generally regarded as 
being of high quality. 
24. 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’, see “Obsolete PDF/X standards”) 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. 
25. Can PDF/X do duotones? 
The original ANSI PDF/X-1:1999 standard (see “Obsolete PDF/X standards”) 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. 
26. 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.  
PDF/X Frequently Asked Questions (Oct 2005)
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved 
Page 15 
In simplistic terms a creation tool is compliant if the files it makes match the specification, but testing the 
compliance of a receiving workflow is somewhat more complex. 
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. 
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. The purpose of all of these is to ensure that PDF/X files process reliably and 
predictably, and that the final printed piece can match the proof generated by the customer before submission. 
You would therefore need to examine your workflow in a very similar way in order to handle baseline PDF 
files. The major difference between PDF and PDF/X in this respect is that some of the most difficult PDF 
issues to resolve in a prepress workflow are circumvented by the restrictions of the PDF/X standards.  
In other words, it looks like hard work to set up a prepress workflow to handle PDF/X files properly, but that’s 
only because it’s very rare to see all of these steps set out fully for PDF files in general. 
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 newsprint, for instance); 
the trim and bleed are appropriate for the job. Unfortunately this is one area where it is very easy for files to 
be badly constructed. The PDF/X standards require that all files have the trim box marked in the file, but 
it’s virtually impossible for an automated pre-flight tool to verify that the trim box is marked in the right 
position relative to the graphical elements that should appear on the printed piece. Manual/visual inspection 
is therefore advised. Some products can mark the position of the PDF TrimBox on hard- or soft-copy 
proofs, allowing relatively rapid assessments to be made; 
the resolution of images is appropriate. 
You may want to apply your own extra tests as well, or to use a PDF/X Plus specification designed for the 
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, or contact the sender if you’re not set up to perform trapping. 
When rendering the file, the fonts embedded within the file 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. 
When you proof files you should do so using a proofing system set up to match the characterized printing 
condition for which the file was created. In many cases that could be a standard configuration on your site, 
because all jobs are printed to the same condition. If you’re proofing PDF/X-3 files, however, it is advisable 
to use the ICC profile embedded within the supplied file as an emulation profile in order to ensure that the 
gamut and tone-scale compression, and black generation, match what was intended by the designer. 
When creating plates from individual PDF/X-3 files that contain device independent color data, the ICC 
profile embedded within the file should be used, again to ensure that the output matches the designer’s 
In many cases, it will not be the PDF/X file as supplied by the buyer that is submitted to the proofing or 
plate-setter RIP; it will have been re-constructed as it passes through stand-alone trapping or imposition 
tools, or aggregated with other files in an advertising or catalog workflow. When processing PDF/X-3 files, 
these steps must be able to maintain the information about the intended printing condition and any 
embedded ICC profiles so that the data is acted on appropriately. It may be necessary to apply the 
PDF/X Frequently Asked Questions (Oct 2005) 
Page 16 
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved. 
embedded color management to individual files, effectively converting them all to CMYK, early in your 
There may be application data sheets available for the components of your prepress workflow, which can make 
configuration for reliable PDF/X handling much simpler (see “What tools should I use for creating and 
processing PDF/X?”). 
Anumber 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
(note that this suite goes beyond 
testing PDF/X-3 compliance). 
The Global Graphics PDF/X overprint test strip is available from www.globalgraphics.com
The first of these is a fairly complete physical for your implementation and may take some time and expertise 
to evaluate completely. The second is a simple patch intended for inclusion on all jobs to allow the overprinting 
applied on proofs and prepress work to be easily evaluated. 
In addition, a suite is being developed by the Ghent PDF Work Group under the code name “Kensington 
Suite”. This is designed specifically for testing complete workflows, rather than RIPs, which are targeted by 
Altona. This suite was originally started by an ad-hoc group associated with CGATS SC6, but has now been 
formally transferred to the Ghent PDF Work Group. Beta patches developed for the suite have already been 
used in an IPA workflow shootout in 2005, and the whole suite should become available at www.gwg.org
some stage. 
27. 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
It is hoped that application vendors will develop and publish application data sheets (ADSs) describing how 
their products can be configured to be PDF/X-compliant. As an example, the ADS for the Harlequin RIP is 
available at www.globalgraphics.com
28. 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 few 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 
some of these products will 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 
PDF/X Frequently Asked Questions (Oct 2005)
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved 
Page 17 
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 checks are obviously very useful at times, but should be disabled if all you care about is 
whether a file complies with the standard. 
29. How and when should I proof my files? 
As a submitter 
If you’re creating files for submission as PDF/X, you probably output several proofs for various purposes as 
the job is designed and prepared. Once you have the job ready to go, and you’ve converted to PDF/X you 
should always proof that PDF/X file, rather than relying on proofs output direct from your design application. 
That means that any unexpected alterations that occur during the conversion to PDF/X will show up in the 
proof. It doesn’t matter if the final proof is on hard copy or a soft-proof on a monitor, as long as it meets your 
internal requirements. 
If your PDF/X file contains an embedded ICC color profile, you should proof using that profile as the 
emulation target. If it does not, then proof using a suitable non-embedded profile for the intended print 
characterization as the emulation target. If you proof without an emulation target you will not be able to make 
any valid assessment of the quality of the color data in the file. 
If your job includes any spot colors it’s usually worth proofing color breaks (separations) at this stage as well, 
to ensure that spot areas have not be converted to CMYK. This isn’t specific to PDF/X, of course; it’s just good 
practice for any file format. 
As a receiver 
Print service providers and publishers follow a variety of policies for proofing files received from customers. 
Some proof all files received, and retain those as file copies in case of a later dispute. This can be particularly 
useful if it is tied into a preflight process in such a way that the preflight report can be filed with the proof. On 
the other hand, producing hard-copy of all customer-supplied files can be too expensive or too slow for some 
Whether a job is proofed on receipt, or only in retrospect in the event of a customer complaint, there are two 
ways in which the proof can be performed. Both can be useful in different ways: 
A.  If the PDF/X file contains an embedded ICC color profile, a proof may be generated using that profile as 
the emulation target. This should give you a representation of what the customer produced in any proof 
that they created immediately before sending the job to you.  
First compare that with any hard-copy proof sent by the customer, any significant differences will show 
that at least one of the two proofing systems is not correctly configured; you’d then have to determine 
whether it’s the customer’s or yours that’s wrong. 
Next compare the appearance of any device-independent color data on this proof with what appeared on 
your press. If that does not match, but the appearance of page elements in CMYK does match, then it’s 
probable that your prepress workflow did not honor the embedded profile within the PDF/X file. 
B.  Create a proof using your usual profile for the print characterization that your press is running to as the 
emulation target, ignoring any embedded profile within the PDF/X file.  
The color of any CMYK data in the file should match what appeared on your press; if it does not, then 
either your press is not running to the characterization intended, or your proofing system is not configured 
correctly. Don’t worry about page elements defined in device-independent color spaces here, they should 
be checked on proof A, above.  
PDF/X Frequently Asked Questions (Oct 2005) 
Page 18 
Copyright © Global Graphics Software Limited, 1999-2005. All Rights Reserved. 
30. How can I persuade my customers to send me PDF/X files? 
At first glance it may appear that all the benefits of PDF/X accrue to the publisher or print service provider, 
while all of the work and expense involved in preparing them falls on the designer or print buyer. This leads to 
some receivers finding it difficult to persuade their customers to make the effort to create PDF/X. 
This is not, of course, the whole story. As a general rule, regardless of whether you submit PDF/X or not, the 
old adage that an ounce of prevention is worth a pound of cure applies; a little time double-checking a job 
immediately before transmission can save many panicked phone calls and considerable expense. 
It’s not uncommon to find people who prepare all of their PDF files that will be submitted for print as PDF/X, 
even when the print service provider or publisher does not require that (and even occasionally when the 
recipient explicitly says that they “can only accept PDF and not PDF/X”). The reason behind this is that 
creation as PDF/X is an easy way to enforce the self-discipline required to ensure that your jobs are sent as 
high-quality, print-ready files, at least in those areas that are covered by the standards. The mind-set that 
validates and proofs a job before transmission is also likely to pick up other quality issues, such as low-
resolution images. 
On the receiver’s side, if PDF/X fulfils its promise, then having clients who submit jobs as PDF/X should 
reduce your customer education, prepress and CSR (customer service representative) costs. You might want to 
consider sharing some of that saving with them to encourage such submissions. It’s common at the moment for 
print companies to swallow the costs for correcting bad files from customers for fear of losing sales to 
competitors. For that reason it’s unlikely that you’ll want to add a penalty fee for non-PDF/X files. On the 
other hand, if your regular pricing review happens to lead to higher prices than before for non-PDF/X files but 
slightly lower for good PDF/X …  
There will probably always be customers that you won’t trust to create print-ready files and you know you’ll 
have to do a lot of corrective work on them before printing, so much that you can do it more easily if the files 
are supplied as native application files. In these cases the best approach is not to push for PDF/X. You can 
either bite the bullet, and just ensure that your pricing structure allows you to continue to make a profit, or you 
could investigate supplying those clients with improved submission tools (see “Is PDF/X better than electronic 
delivery software?”). 
In any event, as you work with customers transitioning from submission of application documents to sending 
PDF/X, it’s worthwhile to have them send both formats in parallel for a few jobs. That will give you immediate 
access to a known fall-back position in case anything goes wrong. 
31. 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 you should take the time to 
investigate PDF/X fully. Depending on your target market sector you should seriously consider developing 
support for PDF/X-1a:2001 or PDF/X-3:2002.  
If you’re already supporting one or more of those, keep an eye on market acceptance of the new revisions – 
PDF/X-1a:2003 and PDF/X-3:2003 (see “2003 revisions”). 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 would be unwise to develop only for the new revisions at 
this time. 
On the other hand, if you’re developing for PDF/X-1a:2001 or PDF/X-3:2002, you may find it useful to read 
the 2003 version as well. Several important clarifications are included in the later releases that could help you 
in development of products for the earlier standards. 
Developing to PDF/X-1:1999 or PDF/X-1:2001 (without an “a”) is extremely unlikely to be useful (see 
“Obsolete PDF/X standards”).  
Please also consider developing an application data sheet for your products, showing how they can be 
configured to process PDF/X files correctly (see “What tools should I use for creating and processing 
PDF/X?”). Writing this kind of document in parallel with product definition can also be useful in helping to 
identify any oversights or awkward user interfaces at an early stage of development. 
One important aspect of the user interface for PDF/X creation tools is that it should be enable the operator to 
enter accurate details about the print characterization for which the file was prepared as easily as possible; see 
“Which characterized printing condition should I label files as using?” for more detail. 
Documents you may be interested
Documents you may be interested