https://issues.apache.org/bugzilla/show_bug.cgi?id=46980
Andreas L. Delmelle <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #23450|0 |1 is obsolete| | --- Comment #5 from Andreas L. Delmelle <[email protected]> 2011-01-09 08:54:21 EST --- Created an attachment (id=26466) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26466) updated patch proposal Found this one still open... Took a quick look again, and I had applied the changes locally, slightly refined as in the attached patch. It can be tested with a fo:basic-link. Given <fox:destination internal-destination="dest" /> then <fo:basic-link internal-destination="dest">... yields behavior similar to <fo:basic-link external-destination="#dest">... Some reservations still: a PDFGoTo can be used to jump to either a page (with or without explicit coordinates) or a named destination. After the patch, I still have the feeling the implementation somehow is slightly messy. In some contexts, the 'destination' member was already used to pass in a string containing the x/y coordinates. As this was likely done as a shortcut, to avoid creation of unnecessary Point2Ds (only to have to reconstruct the String later in toPDFString()), for now, I have split that into two members positionDestination and namedDestination, to avoid confusion. The latter is made final since I saw no immediate reason to be able to change it after creation. There is still a PDFGoTo constructor that takes one String as a parameter, which leads to some ambiguity. Is the String a page reference or a destination name? If not for the parameter name, that would not always be clear. Given the parameter name, creating a shortcut for a named destination required adding a new constructor, taking a String and a boolean. I have not yet deprecated the existing String-only constructor, but would be inclined in that direction. Another point of concern might be the semantics when compared to external links. In case of 'real' external links, pointing to a named destination would have to happen via "....pdf#dest=...", whereas in this case, it is just "#...". Would we also have to cater for "#dest=..." (and possibly "#page=...")? And what about, vice versa, allowing "....pdf#..." to point to a named destination? (The latter is enabled with the patch.) Note also that this behavior only applies to external links with a protocol other than 'file' or 'http'. In those cases, respectively a PDFLaunch or a PDFUri action is created rather than a PDFGoTo or PDFGoToRemote. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
