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
