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

Reply via email to