Bug 44634 - implement show-destination for fo:basic-link
Summary: implement show-destination for fo:basic-link
Status: NEW
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: pdf (show other bugs)
Version: 0.93
Hardware: PC Windows XP
: P3 enhancement
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-19 08:44 UTC by Luong To
Modified: 2012-04-11 06:15 UTC (History)
0 users



Attachments
patch for the implementation (25.64 KB, patch)
2008-03-30 08:00 UTC, Andreas L. Delmelle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Luong To 2008-03-19 08:44:40 UTC
Hi 
Please help on this,

I would really like to insert a hyperlink to pdf output, I wish this link will be opened in a new browser window?

I knew that show-destination attribute of <fo:basic-link> tag was not supported jet. Could you please tell me another workaround to satisfy

I'm using Adobe 8 and IE 7
Thanks
Luong To
Comment 1 Jeremias Maerki 2008-03-19 09:41:38 UTC
I don't think there is a work-around. "show-destination" on basic-link simply has to be implemented. In PDFGoToRemote, the "NewWindow" entry has to be implemented, too, and the two things have to be connected via the PDFRenderer. Patches are welcome.
Comment 2 Luong To 2008-03-23 18:45:17 UTC
How can I hard-code for links will be opened in new window?

Thanks much
Comment 3 Jeremias Maerki 2008-03-25 01:09:18 UTC
(In reply to comment #2)
> How can I hard-code for links will be opened in new window?
> 
> Thanks much

You're still looking for a work-around. I told you, there's none. Someone needs to implement this properly. There's no way around that. If you absolutely want a work-around, you can try inserting that "NewWindow" flag using a third-party PDF library (like PDFBox or iText). No guarantees that it'll work.


Comment 4 Andreas L. Delmelle 2008-03-30 07:59:07 UTC
Been looking into this, and I think I got it working (see patch in attach)

The only thing that's keeping me from committing ATM is that I'm unsure how to test for it...
Comment 5 Andreas L. Delmelle 2008-03-30 08:00:34 UTC
Created attachment 21738 [details]
patch for the implementation
Comment 6 Andreas L. Delmelle 2008-03-30 23:25:54 UTC
Additional reservations:
The patch only adds show-destination functionality for links with an external-destination. Internal links are converted to destinations or local /GoTo actions, and there does not seem to be a way of forcing these to open in a new window.
I have checked the behavior of Adobe Reader standalone and the web-browser plugin. 
The /NewWindow flag works as expected in standalone mode, but the plugin seems to happily ignore it.
For external-links to non-PDF content (PDF: /URI action), the target obviously opens in a new web-browser window when clicked from Adobe Reader standalone. When viewed with the browser-plugin, the link always seems to target the current tab/window.

Unless I'm missing something, implementing this in a way that is 100% compliant with the XSL-FO Rec, is not possible...?
Comment 7 Jeremias Maerki 2008-03-30 23:35:58 UTC
Good stuff, Andreas (only a quick glance taken). The only thing that is probably missing is a parse method for the intermediate format.

I guess if the Acrobat plug-in does not handle the "NewWindow" flag properly, there's not much we can do. It probably needs to be considered a bug in Adobe's code.
Comment 8 Chris Bowditch 2008-03-31 00:26:27 UTC
<quote>
I guess if the Acrobat plug-in does not handle the "NewWindow" flag properly,
there's not much we can do. It probably needs to be considered a bug in Adobe's
code.
</quote>

I'm not sure that behaviour is a bug. Undesirable maybe. My understanding is that Adobe Reader plugin uses the option "Display PDF in Browser" under Edit\Preferences menu (Internet Tab) to decide whether to open a separate window for PDF links or not.
Comment 9 Andreas L. Delmelle 2008-03-31 03:35:17 UTC
(In reply to comment #7)
> Good stuff, Andreas (only a quick glance taken). The only thing that is
> probably missing is a parse method for the intermediate format.

Right. I'll have to adapt AreaTreeParser.setTraits() as well, since the external-link Trait is no longer a simple String.

> 
> I guess if the Acrobat plug-in does not handle the "NewWindow" flag properly,
> there's not much we can do. It probably needs to be considered a bug in Adobe's
> code.
> 

A bug or a missing feature, indeed. It is also not possible, AFAICT, to open a different destination in the same document in a new window. Still, if I interpret correctly, this is the expected behavior for show-destination="new", no matter whether the destination is internal or external.

[Chris:]
> I'm not sure that behaviour is a bug. Undesirable maybe. My understanding is
> that Adobe Reader plugin uses the option "Display PDF in Browser" under
> Edit\Preferences menu (Internet Tab) to decide whether to open a separate
> window for PDF links or not.

Not exactly. The above option controls whether the plugin is used altogether if you enter a PDF address in the browser's address bar or click a hyperlink targeting a PDF. If you disable it, then Adobe Reader or Acrobat is always used standalone to view PDFs. There is another option that also relates to the /NewWindow flag. On the General Tab, I have the possibility to disable "Open cross-document links in the same window". This determines what happens if no explicit value for the /NewWindow flag is specified. Only, this option does not influence the behavior in the plugin; only relevant for standalone mode.
Comment 10 Andreas L. Delmelle 2008-04-25 04:29:32 UTC
Changes applied to FOP Trunk.

see http://svn.apache.org/viewvc?rev=651575&view=rev

For the moment, I'm leaving the bug open, given the limitations of the added implementation...
Comment 11 Glenn Adams 2012-04-07 01:44:49 UTC
resetting P2 open bugs to P3 pending further review
Comment 12 Glenn Adams 2012-04-11 06:15:50 UTC
change status from ASSIGNED to NEW for consistency