PDF/A and PDF/X at the Same Time

How do you create files that comply with both PDF/X and PDF/A?

In an increasing number of inquiries that we are receiving not only one PDF-based ISO standard is required. In many cases compliance with PDF/A and PDF/X should be achieved. But always one of these standards is more important in the respective environment: An organization may want to generate print output which at the same time should be archived, or a print shop may want provide archive ready files to its customers. In both cases PDF/X compliant files should be created which at the same time comply with the PDF/A standard. Or in an archival project it may be important that the archival PDFs do comply also with PDF/X in order to make sure that they can be output on a high end printing device – today or in the future. In many such projects questions arise about what are the differences between the two PDF based ISO standards and the following brief overview should shed some light on this. (Whoever is interested in more details may just want to try our pdfaPilot solution that has predefined profiles for converting into more than just one standard.)

First of all from a high level perspective there are not many differences in the two standards. This is actually no surprise because some “design goals” for both standards are the same: Reliability, paper like appearance and completeness.

On a more detailed level both standards require that all fonts need to be embedded and prohibit the presence of dynamic actions or java script.

The most important difference is that PDF/A allows for comments and forms which is not the case in PDF/X. That makes sense because these objects are usually not printed. But in workflows that should support both standards this may be the only real problem. The only way to convert both into PDF/X would be to flatten them into the page content, which would actually mean that they cannot be used as annotations or form fields anymore.

Everything that is by nature not visible on the page like structure information or unicode which are covered by the PDF/A conformance level “a” does simply not have the same importance in PDF/X as in PDF/A. However, there is no rule that would say that both may not be used in a PDF/X file.

Metadata plays a major role in PDF/A because it helps to understand the purpose of a PDF or to retrieve it from the archive. In PDF/X only in the newest part of the standard, PDF/X-4, there are rules for XMP Metadata. The requirements are similar to PDF/A.

An other important difference between both standards is in the field of color. That is due to the fact that many print workflows are based on the print color space, CMYK, while in PDF/A nearly always the standard monitor color space sRGB is used. As said before there are three different parts of PDF/X that are practically used: PDF/X-1a, PDF/X-3 and PDF/X-4. In the newer flavors, PDF/X-3 and PDF/X-4, both color spaces, CMYK and/or sRGB may be used. One of the most important decisions that has to be made in such projects is in which way color spaces should be converted in order to meet the requirements in the respective project in the best possible way. Both standards are flexible enough to cover concrete requirements, it may just be required to adjust the conversion settings accordingly.

In general PDF/A and PDF/X are technically close and in most cases it should be easy to convert a PDF file into one that complies with both standards at the same time. The only important exception to that rule are PDF files with annotations or form fields. Practically it will be required to make a decision on the color space approach which will be based on whether it is more a PDF/A or a PDF/X project.

About callas software GmbH

callas software finds simple ways to handle complex PDF challenges. As a technology innovator, callas software develops and markets PDF technology for publishing, print production, document exchange and document archiving.

Leave a Reply