On Jul 17, 2008, at 20:08, Jeremias Maerki wrote:

I've been quiet about about this PDF extension so far because I didn't
see much harm in doing it in a generic way for some simple name/value
pairs. If that goes much further (like doing hacks to produce some
complex PDF structures but still forcing it into the generic extension) then I'm a bit concerned. I do prefer the non-generic form I proposed at the beginning on the Wiki. I don't think there will be any problems with
PDF/A and PDF/X conformance but the further you go with a generic
approach the less control you have if a generated file will be
conformant. Please keep that in mind while working on this. Thanks.

OK, will do. As a plain and simple rule, I'd make it "either one or the other". If the user specifies a conformance level, processing of the extension is disabled, since otherwise FOP cannot guarantee the conformance.

I see perfectly what you mean, and the idea of specifying PDF 'expressions' is way too dangerous to allow. That's why I'd like to limit it to a handful of elements that, when combined, can serve to compose simple dictionaries/entries. Obviously, the docs will have to come with a Big Fat disclaimer that users are advised to stick to the examples that we provide, unless they are absolutely certain they know what they're doing...

In the meantime, I have received another reply from Bill, which raises some more concerns (something that was already playing in the back of my mind), namely, users that specify PDF 1.6 entries in a document whose header indicates PDF 1.4. Not sure, but this is very likely to cause unpredictable behavior in certain viewers... Some may simply ignore the entry, others might consider the PDF to be corrupt/ invalid.

Bill, note that the entry in question may well be available in the ViewerPreferences dictionary as of PDF 1.6, but FOP still produces PDF 1.4 max.



Reply via email to