PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
Leonard,
I like to think of PDF files as (to borrow from quantum mechanics with apologies) a probability field relative to a workflow. Our universe is the set of all places within a workflow where someone might want to examine or use the PDF file. Everyone thinks the PDF will probably work correctly everywhere until someone actually tries it some where - at which point the probability fields collapses to success or failure (the particle is there or not, the file works or it does not). Then either the PDF will RIP or it won't. Failure to RIP one place doesn't mean the file is bad or that it won't RIP everywhere else. We're trying to construct a test that will pass only those PDF's that are generic enough to work everywhere within a workflow.
We are not concerned about output appearance because that is totally a side effect of the RIP function. So, if the file does not RIP, then the output is undefined and no one cares. If the RIP successfully consumes the file then we presume there is some output - output that passes on in the workflow to some later function that tries to tell if the output is "correct". (I will concede that there is a correlation between RIPing and having correct output.) We might trust a RIP in general, but for commercial work someone always has to check the output.
The goal of the overall workflow is to reliably create PDF content with the greatest probability of RIPing everywhere within the workflow. This tests helps us to determine a PDF file has a high probability of RIPing.
Actualy, you are correct - if it don't open in Acrobat, it fails...RIPing without error is the first step.
I would think that parsing & rendering by desktop applications (Acrobat, Ghostscript, Mac OS X Preview, Xpdf) would be a first step.
If it works there, THEN sending it to SOME RIP would be next....
We need to be able to decide if a problem is related to the PDF file or the RIP. We believe passing the tests below allows us to say to the RIP vendor or application provider that the user has a valid expectation that this PDF file should RIP on a given application.
But if a given PDF renders in all the desktop apps, and then RIPs fine on some modern RIP and you "validate" it. And then it fails on some other RIP/Printer - do you blame the PDF or the RIP?
Depends on the workflow - which will contain some set of applications (RIPs, etc.). So, I guess if the file works everywhere within my workflow I think its valid - using the PDF outside the workflow is invalid. If the file needs to start working somewhere else, then somewhere else becomes part of the workflow and validation has to happen again. Blame may also cause us to throw out an application which is too picky or a file which misbehaves too much.
OR lets look at the InDesign CID font issue as a practical example. InDesign built a PDF that was perfectly valid as per the PDF spec, and would have passed the desktop test (since all of your test apps already handled CID fonts correctly). It may then have failed on the RIP you chose. Whose fault is it - InDesign or the RIP?
If the workflow expects inDesign PDFs to work, then the PDF fails. Otherwise, we may have the user switch to Quark. Again, it depends on the environment. The usual path is one of expedience (job is already late) and pragmatics - too much work was already done in inDesign, so we need to upgrade the RIP.
Failing indicates that the creator of the PDF file has done something wrong and should bear the responsibility of fix the problem - nothing more.
Not convinced, given the above example...
Before we can look at content and output, we need to believe that the file is a valid PDF file.
That the structure of the PDF is valid - such as correct Xrefs, object offsets, line endings, CosNames, etc.
Of course, there are valid PDF's that won't render in Acrobat due to the "limitations" specified in the PDF Ref...
PDFs can be structurally invalid yet still work everywhere, or completely valid structurally and work nowhere. We see both all the time.
Files that RIP non-deterministically, e.g., fail GhostScript but succeed with Acrobat, are not useful commercially
GS is a great tool, but given it's development/distribution system, I am not sure that's a valid criteria unless you also quantify the versions of GS, th device choices, etc.
I do below....
Why 5.0 and not 5.0.5?
Not everyone has 5.0.5 and 5.0 has more bugs and problems than 5.0.5.
True, it has more bugs - but as it has been two years, it is really true that folks don't have the 5.0.5 update yet??!?!
Why both Mac OS 9 and Mac OS X?
Because they can behave differently - though in our experience you could probably accept only OSX (remember we started when OSX was less popular).
They will behave differently for printing, but not for screen render. So if you are only testing 5.0, how are you testing Mac OS X, since 5.0.5 was the first version to be native under Mac OS X.
5.0 on OS 9, 5.0.5 on OSX.
We have found that the versions of Windows is irrelevant - NT 4.0, 2000 and XP are our favorites.
You may wish to include Win98SE in that, since Acrobat does behave different on the 9x series than on the NT/2K series...
Agreed, but going back to '98 brings up other issues. We've been okay on NT/2K.
Do you attempt to view every page in the document or only validate the ability to open and view page 1?
Yes. You have to view each page - no matter how many - usually by holding down the arrow key and getting to the end of the file without an error dialog.
Excellent! That will help discover potential content issues.
We currently use ESP GhostScript 7.05 (I believe this is now or was until recently the latest).
That's a good version to use for PDF 1.3, but will fail on PDF 1.4 in some cases due to bugs addressed during the run to 8.0...
I think the comparable Aladdin version is 8.00.
No, the 8.x series is quite new and I wouldn't recommend it just yet - there have been some MAJOR changes and they are still in flux. 8.1 is on the way, but there are some show stoppers at this time...
We are happy with ESP GS 7.05 at this point.
Warnings are considered errors and grounds for failure.
Interesting. Some warnings are harmless though. You fail for any?
Yes. Clean GS is required.
Use the print command/dialog.
We generally use either the Adobe Distiller as the destination, set to print to file.
That's good, since that will keep the driver out of the picture for the most part...
Why is redistillation a criteria?
This is one of the most important criteria. Acrobat often generate PS that is in error (I think we have discussed this in the past). There are a large class of issue here which are subtle. "adobe says" that the distiller front end matches the current RIP front ends very closely (CPSI 3.0 class RIPs). So success here is a good predictor that test 5 will succeed.
I just wonder if Acrobat and/or Distiller has any "special casing" for this particular scenario (redistillation) that wouldn't provide a true test case....
This is a pragmatic test and we believe its very important.
And what tool(s) are you using to perform this "redistillation"??
Acrobat Distiller 5.0 out of the box (though 4.0 matches 5.0 for this test).
5.0/5.0.5 would be fine - I would NOT use 4.0, but 4.0.5....
Yes. I mean 4.0.5.
We don't care about the output - we are concerned whether the file is structurally correct and consumable.
I guess I am not sure that structurally correct and consumable are equivalent.
Agreed as above.
Success here is important, i.e., it RIPed without an error - its possible that some RIPs will fail while others will not - but not always for the reason that the file is incorrect, e.g., not enough VM, etc.
I am more concerned with failure due to lack of support for a PDF feature - again, use the CID Font issue as the test case...
Failures of this sort are detectable later in the workflow...
Correct output appearance is a completely separate problem - one that is too hard, IMHO, to be part of a test like this.
Agreed...
We've had problems with Xpdf on high-page count and complex files (LINUX runs out of swap space in default installations).
Haven't seen that - make sure you are current (2.0.2p1).
LDR
-- ----------------------------------------------------------------------- ----
Leonard Rosenthol <mailto:[EMAIL PROTECTED]>
Chief Technical Officer <http://www.pdfsages.com>
PDF Sages, Inc. 215-629-3700 (voice)
215-629-0789 (fax)
To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
