On Jul 14, 2008, at 11:55, Jiri Tyr wrote: Hi Jiri
I have found one error now. The pdf:dictionary definition works only if it is placed in the fo:root only and before the fo:page- sequence. If you place it into the fo:layout-master-set or after the fo:page-sequence it doesn't work. See the example in the attachment.
Yep, just noticed myself, and IIC from the code, then extension- attachments currently are only processed for a very limited set of FOs.
I was confusing things with the fox:destination extension, which attaches itself to the fo:root, so it can be specified anywhere in the document.
The pdf:dictionary extension will currently only work either as a child of fo:root or fo:declarations. I guess it can be made to add itself as an attachment to the root, since that's where it belongs... OTOH, we could also make those the rules and add some validation events if the dictionary appears elsewhere in the document. If necessary, we can always make an exception for special types of dictionary later (?)
I haven't looked into implementing subdictionaries yet (which would be necessary for the ViewerPreferences or OpenAction) The fact that the pdf:entry child nodes are added as extension attachments to the parent extension node, is probably not the best way... that's what looks so awkward about PDFRenderer.renderPDFExtension(), passing the attachment as an argument, thereby obtaining the dictionary object, and then having to check its extension attachments to extract the entries (?) Not sure, but I guess PDFDictionaryExtension could just add the entries as 'normal' child nodes. Instead of having to pass through PDFExtensionAttachment for each entry, via getChildNodes() we'd immediately get an iterator over the entries/subdictionaries.
Once in place, though, I think the infrastructure could open up some / very/ interesting possibilities...
Cheers Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
