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.
On 17.07.2008 19:18:32 Andreas Delmelle wrote: > On Jul 17, 2008, at 18:53, Jeremias Maerki wrote: > > > For that you need an "Explicit Destination" (PDF 1.4, 8.2.1, > > "[page /Fit]") > > which you place as a value for the "OpenAction" key in the "Document > > Catalog". > > Thanks for the pointer! Unfortunately for Bill, this means that the > patch will need some more work to support (at least) PDF arrays as > well, before the extension can be used for this purpose. > > I don't think adding arrays by itself would be too difficult. I was > playing with the idea of using strictly typed objects (in favor of a > type attribute on an abstract entry), which I'll probably add pretty > soon. I'll see what I can do. > The only potentially tricky part may be the indirect reference to the > page object (?) > > IIC, this is a variable that the extension knows nothing about > (should be set/provided by the renderer) > > Apologies for the false hope for an immediate solution, Bill. On the > bright side, it's probably not too far away... > > > Andreas Jeremias Maerki