PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
At 04:31 PM 6/25/2003 -0400, Todd Kueny wrote:
It seems like PDF/A has a serious problem. PDF/A files won't be usable in any workflow requiring XRX or KDK commands.
Well then the XRX and KDK folks will need to change if they want to support PDF/A...
I know that the PDF/X committee is also considering similar changes to the PDF/X spec.
Seems like the folks who came up with XRX and KDK were looking for "quick hacks" and NOT trying to address their needs in a compatible and standard way...
This eliminates PDF/A from most commercial B/W and color PDF workflows - specifically printing using drawer-pull commands on most any commercial printing device.
Given that the US Gov't is going to be moving to a PDF/A workflow in the future (which is why they are behind the project in many ways), I think it's probably going to be the other way around here. The vendors will need to get their act together.
Ironically, Adobe controls the PDF specification
Correct.
However, there are now "flavors" of it which are Int'l standards such as PDF/X and others in the pipe (like PDF/A) which are NOT controlled by Adobe.
- while its own OEMs are creating illegal BROKEN workflows around Adobe's RIPs
People do stupid things every day...
Someone on this list besides myself should be concerned that vendors using the equipment I reference are the ones who pay to buy the tools developers and standards makers create.
You mean the folks using broken equipment??
Why should we be concerned about them? Why should a new modern standard be concerned with supporting people who insist on using old, outdated, incorrectly implemented stuff??
It's no different than the arguments about HTML and browsers...
I am forced to conclude that the PDF/A standards committee is choosing a position that will ultimately be a disservice to PDF developers who sell to this market.
I think the exact opposite, since my hope (and those of other on the committee) is that PDF/A will be used to help CORRECT the flow of broken/invalid PDF's in the world today and therefore reduce the amount of errors that users encounter due to folks who don't follow the spec and instead rely on implementation behavior...
Further, I think it's irresponsible to use this list, which should be open to all developer issues, as a bully pulpit to claim that only certain workflows are good, i.e., not BROKEN.
I am stating my opinion as part of a discussion - it's no more my pulpit than yours...
And I stand by my position as an independent consultant AND an official trainer for Adobe Systems of the Acrobat SDK and the PDF File Format.
Leonard --------------------------------------------------------------------------- Leonard Rosenthol <mailto:[EMAIL PROTECTED]> Chief Technical Officer <http://www.pdfsages.com> PDF Sages, Inc. 215-629-3700 (voice)
To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
