https://issues.apache.org/bugzilla/show_bug.cgi?id=46980

Andreas L. Delmelle <adelme...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23450|0                           |1
        is obsolete|                            |

--- Comment #5 from Andreas L. Delmelle <adelme...@apache.org> 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.

Reply via email to