The last time a content operator was added to PDF was with PDF 1.2
Since we are defining a file format and not the behaviour of a conforming reader, it falls within the PDF/D philosophy of minimizing the cruft to drop these operators. In the unlikely event that a future version of PDF adds new operators, we can add them back in a future iteration of PDF/D so that conforming writers can use the new operators.
For now, no need for BX and EX: as with PDF/A any operator in a content stream that is not defined in PDF ISO-32000 is considered an error.
As has been recognized by all of the ISO PDF committees, it is IMPOSSIBLE to define a file format WITHOUT ALSO defining how a conforming reader is to treat the format. Because a file format is just that - a bunch of bytes put together a particular way. They say NOTHING about what/how someone should do with them :(. That's your conforming reader...
ReplyDeleteTake the simplest file format on the planet (say ASCII text) - notice how there is no consistent behavior about how to display it...and the problems that this causes.
With PDF - you MUST HAVE BOTH...
Leonard
I commented in the Acrobat Reader user survey asking for a "strict" mode. It would be great for developers if Acrobat Reader was a "conforming reader". Or, at the very least, if there was a way to make it intolerant of obvious errors in PDF files.
ReplyDelete