How does PDFNet SDK support PDF/A or PDF/X?


How does PDFNet SDK support PDF/A or PDF/X?

Standards such as PDF/A (PDF/E, PDF/X, etc) define a subset of the PDF
specification designed for a specific industry (e.g. publishing,
engineering, etc). These specifications essentially list a number of
feature restrictions that are not supposed to be used in a given
subset (most specifications are also relatively short; <30 pages).

PDFNet SDK allows viewing, processing, and generation of any PDF
document (PDF/A, PDF/E, PDF/X, or generic PDF), and it does not
prevent the user from creating a valid PDF document that includes
features that are not listed in one of the PDF subsets. At the same
time, we made sure that our Cos/SDF (i.e. low-level) serialization of
PDF document is always PDF/A compliant.

Like with other PDF creation libraries, to generate PDF/A compliant
documents the user needs to make sure to use only the features that
are allowed in a given PDF subset. The output from PDFNet SDK can be
dynamically verified or batch-processed in order to determine whether
the output meets PDF/A (or PDFX, PDF/E, etc) restrictions. Unlike some
other PDF generation libraries, PDFNet SDK will not throw a runtime
error if a user creates a feature that is not supported in a given
subset. There are several reasons why it is better to delegate PDF/A
verification to a dedicated verification or pre-fighting tool (such as
the PDF/A verification tool in Acrobat 8):

- The built-in preflight is typically implemented by the same
developers who are generating the output. As a result, the errors and
omissions in PDF generation will most likely not be detected by the
verification code, and the end user will have a false assurance of
being PDF/A compliant. Similar to the idea of 'code review', it is
better to separate PDF compliance task to a completely separate and
independently-developed verification utility.

- Although runtime errors might be a useful indicator during
development and testing, they are usually not acceptable when the
application is running in an unattended environment (e.g. for server-
side use, dynamic PDF generation, etc). Since it is not possible to
cover all possible traces of execution, the runtime errors may appear
at random points and the developers may eventually turn-off the
verification to make sure that the service runs without

- A developer may intentionally want to allow certain features that
are not covered in a given PDF subset (e.g. the user may want to use
JavaScript even though it is not supported in a given subset).
Verification code built into the library does not compare to a
dedicated and user-friendly preflight tool that allows the user to
specify a list of exceptions, custom rules, etc.

- Besides PDF/A, there are many other important PDF subsets (PDF/E,
PDF/X, PDF/H, PDF/UA, etc) and each of these further defines several
variants and revisions (e.g. PDF/A-a, PDF/A-b, PDF/X-1, PDF/X-2, PDF/
X-3, etc). Also there are new subsets that are currently in the
process of being standardized. This may be confusing to the user if
all of the standards are supported in the actual PDF library. As such,
we want our users to be able to create the generic PDF files, which
can conform to any given PDF subset.

There is much hoopla on the internet related to PDF/A and other PDF
Some of this is driven by real user requirements, but for the large
part it is driven by technology companies trying to differentiate and
promote their products.

Using PDFNet SDK it is possible to read, print, and create PDF
documents from any PDF subset (such as PDF/A, PDF/E, PDF/X, PDF/H, PDF/
UA, etc), however the task of verifying whether the PDF output belongs
to a given subset belongs to a professional PDF verification or
preflight tool. PDFTron offers full support and assistance to
developers wishing to make their PDF output compatible with any subset
of PDF Specification. In addition, we will offer PDF verification and
preflight utilities in the future (free to PDFNet SDK customers) to
help them with this task.