pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tilman Hausherr <THaush...@t-online.de>
Subject Re: Named destinations refactor/enhancement
Date Sat, 05 Sep 2015 15:06:20 GMT
Am 05.09.2015 um 11:50 schrieb Andrea Vacondio:
> Hi, I'd like to discuss few issues related to the named destinations and
> somehow related to PDFBOX-2793.
>
> 1. PDOutlineItem::findNamedDestinationPage I think this method belongs to
> the PDCatalog, public. In my use case I split a document and I want to
> process the annotations removing those link annotations pointing to a page
> that is no longer there (due to the split) so, whenever the annotation
> destination is a PDNamedDestination I could use that method to find the
> page destination. Same thing if I want to resolve a GoTo action (say open
> action) with a named destination.

done.

>
> 2. PDDocumentNameDictionary::getDests if it doesn't find the Dests name
> tree it tries to find the catalog Dests and wraps it in a
> PDDestinationNameTreeNode. I think this is wrong since the catalog Dests is
> a dictionary, not a name tree.
> I also think this is a hidden behavior that shouldn't be there, if I ask a
> name tree for Dests I don't expect it to return the catalog Dests behind my
> back, it should return null and it's up to me to take action in case it's
> null and look at the catalog Dests. Same for the setter, I actually would
> remove the catalog reference from the class or at least clearly document
> this behavior in the javadoc.

hmm.... I'm undecided about this. On the one hand, PDFBox is usually low 
level. On the other hand, we do have some simplifications to make life 
easier, e.g. what you asked for (and just got) in (3).

Of course "clearly document this behavior in the javadoc" I'd always 
agree. But you meant this only to the setter, didn't you?


>
> 3. PDDocumentNameDestinationDictionary::getDestination assumes that the
> destination returned by the Dests dictionary is a COSArray but according to
> specs 12.3.2.3 it could be a dictionary, in which case we are interested in
> the D entry value.

Yes you are correct. done.

Tilman


>
> I could write a patch for these issues but I first wanted to share my
> thoughts and see what you think
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org


Mime
View raw message