pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Vacondio <andrea.vacon...@gmail.com>
Subject Named destinations refactor/enhancement
Date Sat, 05 Sep 2015 09:50:34 GMT
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.

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.

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.

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message