PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
At 6:59 PM -0400 8/7/03, Todd Kueny wrote:
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
Understood, and I think that's a good well defined area over which to create such a test...
The only thing that I think is at issue is the definition of "successfully RIP". Does that mean that the RIP can digest/consume the PDF w/o any errors? If so, then that would seem to include content data issues as well.
- a criteria independent of PDF level or output appearance.
I don't believe you can do that...
How can you say that a PDF 1.4 document will successfully RIP on a PDF 1.2 RIP??
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?
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?
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...
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.
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.
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...
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...
Warnings are considered errors and grounds for failure.
Interesting. Some warnings are harmless though. You fail for any?
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....
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....
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.
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...
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
