While there are tools available to purchase is this regard their use does not ensure that a PDF will work in practice. Each version of PDF has specific features, e.g., transparency, that it enables, has specific features that are replaced with alternate constructs, and so on.
So the first thing you have to figure out is which version are you trying to create. In my experience you always want to check that the PDF is compatible with the oldest version that supports all the features you need. You can check for correctness relative to new versions as well but this limits the usefulness of the PDF. Of course, "A" list companies always want to force your PDFs to be the latest, most complex version - but that's not always the best for you or your customer or your application.
Once you have decided on a PDF version the simplest way to "validate" a PDF is to use a variety applications to process it and see if the results are correct. For RIPs and viewers this basically means processing the PDF and checking the output and logs. We tend to use a spectrum of newer and older tools, RIPs and applications for this. The reasoning is that if it opens and works in older tools as well as newer tools the PDF is much more likely to be right.
Our tools have been in operation and continuous customer use for almost a decade at this point so we only contend with new "features" for the most part.
Backward compatibility is also important and in general we tend not to add features just because we can. Why? Mostly because the customers who use our products have their own set of tools which they have been using a long time and don't want to have to re-verify that any changes we have made to not negatively impact their workflow.
When you think about all of this together you start to see that there really isn't such a thing as "correct PDF" because that depends on the application and usage. I can continually update my PDF output modules but I may break customer workflows by doing so.
No comments:
Post a Comment