PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
Leonard,
We are looking to determine if a commercial PDF file someone intends to print can be expected to successfully RIP with with this validation test - a criteria independent of PDF level or output appearance. RIPing without error is the first step. 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. Failing indicates that the creator of the PDF file has done something wrong and should bear the responsibility of fix the problem - nothing more.
Before we can look at content and output, we need to believe that the file is a valid PDF file. Files that RIP non-deterministically, e.g., fail GhostScript but succeed with Acrobat, are not useful commercially So far, this is the best we have been able to do....
1. File must open in Acrobat 4.0.5 & Acrobat 5.0 on PC/Windows and Mac OSX & OS 9 without error and without Acrobat requiring you save the file when you close it.
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.
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).
What version(s) of Windows?
We have found that the versions of Windows is irrelevant - NT 4.0, 2000 and XP are our favorites.
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.
3. The file must open and RIP in Ghostscript on both Mac OSX and PC/Windows (we use either GNU or Aladdin (SP?) - same version)
What version of Ghostscript? Which -sDevice(s) do you use?
We currently use ESP GhostScript 7.05 (I believe this is now or was until recently the latest). I think the comparable Aladdin version is 8.00. Output to JPEG. We don't look at the output and let all pages render to a single .JPEG file. Warnings are considered errors and grounds for failure.
Are you building GS yourself from source, or using prebuild binaries? If the latter, which distribution(s)?
On OSX we use the GhostScript that's available for OSX on the web site pre-built. Ditto for Windows.
4. The file must open and be printable to PostScript without error on Mac OSX and PC/Windows.
Open in Acrobat, yes? This is #1.
How are you printing to Postscript? Using what PS driver? Using "export to PS"? This is ESPECIALLY important on Mac OS X which does prints PS in a quite interesting way, and that varies between 10.1 and 10.2...
Use the print command/dialog.
We generally use either the Adobe Distiller as the destination, set to print to file. The drivers are the default drivers. Mostly, we have found that for the purposes of RIPability, versions don't matter here. Ditto for OSX.
Since page sizes don't work right in Acrobat 5.0 and later, we like the QMS 1750 as an output device as well. Again, we don't mind if the output page size is wrong. Though we do care that all the rendering fit on the page, i.e., none hangs off the page.
The resultant PDF files must redistill without error to a PDF on the respective platforms.
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.
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. The file must RIP correctly on one or more commercial RIPs - this can include B/W rips and/or color RIPs and does not have to produce output.
How is a RIPping process that does not produce output considered valid?
We don't care about the output - we are concerned whether the file is structurally correct and consumable.
Isn't this the biggest issue in your "tests", in that I can produce PDF's that are valid in all other tests, but will fail this one due to use of features of PDF not implemented by "clone" or older RIPS. (eg. the CID font issue).
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. We tend to favor Barco and Xerox RIPs here.
Correct output appearance is a completely separate problem - one that is too hard, IMHO, to be part of a test like this.
Other applications, e.g., xpdf as it comes with Red Hat Linux, fails with larger, more complex PDF files.
I don't know what version of Xpdf you are using, but my experience with both Xpdf and Ghostscript has the former able to consume MANY MORE PDFs than the latter. I have worked with both in great detail including contributing source patches to both.
We've had problems with Xpdf on high-page count and complex files (LINUX runs out of swap space in default installations). Generally what you say is true - these apps work way better than Acrobat. But the above tests are sufficient and using Xpdf doesn't add anything as far as we're concerned. On the other hand, if your familiar with it, you could swap it for GS, I suppose. Again, this works for us....
Todd
To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
