Q: When I create pdftron::PDF::PDFDocInfo I don't know will it be
stored in the XMP format (as PDF/A spec requires) or not. Therefore I
don't know if I can use high level API to set up document information
properties and still get correct PDF/A output.
A: PDFNet allows processing and generation of any PDF document, and it
does not prevent the user from creating a valid document that includes
features that are not listed in one of the PDF subsets. To make your
application PDF/A compliant, you need to make sure that you are using
only features allowed by a given subset (e.g. you shouldn't embed
http://www.pdftron.com/net/faq.html#pdfnet_pdfx for more info. We do
have many clients that implemented PDF/A and PDF/X workflows, however
restricting the entire API to a given subset of PDF is not something
that would benefit most of our clients.
PDFDocInfo doesn't set required XMP descriptor stream which should be
present in PDF/A compliant documents. Still you could embed the XMP
metadata stream as follows :
// Using C# - Add XMP metadata to document catalog
StdFile xmp_file = new StdFile("myxmp.xml",
FilterReader reader = new FilterReader(xmp_file);
Obj xmp_stm = pdfdoc.CreateIndirectStream(reader));
You could also embed a XML memory string/buffer instead of loading a
separate file on the disk.
when I open existing PDF document (which contains document
information dictionary but does NOT contain respective XMP
properties), do NOT edit it's properties (via PDFDoc::GetD
ocInfo()) then save it to another file will the output file
contain XMP document information?
Unless you create XMP information, the modified file will not contain
XMP properties. In general, XMP metadata stream in not required in
generic PDF documents. Document information dictionary is the
traditional way to store document metadata. Sometimes this dual way of
representing the same information can produce some ambiguities. Still,
using PDFNet API you should be able to read/write and edit both
document information dictionary as well as XMP metadata.
I could experiment about each of the suspicious moments, but
I can just miss something.
Some of our customers that implemented PDF/A and PDF/X compliant
solutions found that validation/verification utilities (we still didn't
have a chance to test PDF/A validation functions in Acrobat 8; but
there are also other options) are very useful in automatically
diagnosing and pinpointing compatibility issues. One of the advantages
of PDFNet is that once a compatibility problem is encountered, there is
always a way to work around it (so you are never stuck). Also we do
plan to provide extra utility methods and documentation/tutorials
specifically addressing generation of PDF/A and PDF/X documents.