Links

[Jordan Naftolin <jo...@jtcsv.com>]

FOP currently uses the FileSpec object for its simple-links.  As a result, FOP can only link to other PDF files (which, when clicked, will open in the curent Acrobat Reader).  However, with the current implementation of FOP, we cannot link to external (non-pdf) documents such as web pages.  The xsl:fo intends for simple-links to be used for all types of documents.  It is a poor design because (as Steve pointed out) there is no protocol specified in the external-destination and as a result, it is unclear as to how to open the external-destination.  
One way to be able to open both pdf files and web pages is to use URIs instead of FileSpecs.  The downside of using URIs is that all external-destinations will be opened in a web browser (including pdf files).  Thus the Acrobat Reader web browser plug-in would be required to view pdf files, and pdf files would not be opened in the current Acrobat Reader process.  Another disadvantage is that links cannot be relative since having an external-destination="normal.pdf" will try to open http://normal.pdf when it is clicked on within a non-web browser instance of Acrobat Reader.  An example of this can be seen by saving the XEP's links.pdf (from http://www.renderx.com/~dvd/CMP/index.html) to your hard drive and opening it up in Acrobat Reader, and then trying one of the links.

A possible workaround to get both web pages and pdf links to work properly is to do a check on the external-destination string and use FileSpec if the destination ends with ".pdf" and to use URI otherwise.

What are your thoughts on this issue?  (...and please correct me if any of this information is incorrect)
Thanks,
Jordan

Re: Links

[Peter Murray-Rust <Pe...@nottingham.ac.uk>]

At 21:56 01/06/00 -0300, Arved Sandstrom wrote:
>Yes, I agree. You're right, Sebastian, this came up before, and in my
>initial dev work (most of which James and I decided not to include because
>we were unhappy with precisely this issue) I basically just looked at the
>suffix, and the protocol _if_ it was there.
>
>Arved
>
>At 12:04 AM 6/2/00 +0100, Sebastian Rahtz wrote:
> >Jordan Naftolin writes:
> >
> > > A possible workaround to get both web pages and pdf links to work
> > > properly is to do a check on the external-destination string and use
> > > FileSpec if the destination ends with ".pdf" and to use URI otherwise.
> >
> >This sounds horribly familiar. Didn't this come up some time ago? It
> >is an area I wrestled with several years ago, and never came up with a
> >perfect answer to. I believe you need to check both the file extension
> >and the protocol (having expand the reference to a full URL
> >string). Only if its a file: protocol _and_ the extension is PDF do
> >you use the FileSpec link method. I'd say the onus should be on the
> >author to use the file: protocol if they want a local open in the same
> >copy of the PDF viewer.
> >
This is an important area - we certainly need links from PDF to non-PDF 
resources.

I think XML has a formal, if rather convoluted mechanism for managing this. 
[I am reluctant to rely on suffixes - there is so much variability and some 
resources are offered by (say) CGI or other server mechanisms and end in 
*.pl or even have no suffix.]

XML has a NOTATION mechanism which can be used to identify the type of an 
external unparsed entity and this can be mapped onto a string (e.g. PDF, 
HTML) or even a formal public identifier. The downside is that this has to 
be declared within a DTD (external or internal) and its syntax is 
non-trivial (at least to me). I argued on the XML-WG that there should be a 
"type" attribute on resources but NOTATION won the day - however I don't 
know whether anyone actually uses it. I would suggest a campaign to add a 
"type" attribute to links in XSL-FO if it isn't too late.

         P.

Re: Links

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Yes, I agree. You're right, Sebastian, this came up before, and in my 
initial dev work (most of which James and I decided not to include because 
we were unhappy with precisely this issue) I basically just looked at the 
suffix, and the protocol _if_ it was there.

Arved

At 12:04 AM 6/2/00 +0100, Sebastian Rahtz wrote:
>Jordan Naftolin writes:
>
> > A possible workaround to get both web pages and pdf links to work
> > properly is to do a check on the external-destination string and use
> > FileSpec if the destination ends with ".pdf" and to use URI otherwise.
>
>This sounds horribly familiar. Didn't this come up some time ago? It
>is an area I wrestled with several years ago, and never came up with a 
>perfect answer to. I believe you need to check both the file extension
>and the protocol (having expand the reference to a full URL
>string). Only if its a file: protocol _and_ the extension is PDF do
>you use the FileSpec link method. I'd say the onus should be on the
>author to use the file: protocol if they want a local open in the same 
>copy of the PDF viewer.
>
>
>Sebastian
>
>

Re: Links

[Sebastian Rahtz <se...@computing-services.oxford.ac.uk>]

Jordan Naftolin writes:


 > 
 > A possible workaround to get both web pages and pdf links to work
 > properly is to do a check on the external-destination string and use
 > FileSpec if the destination ends with ".pdf" and to use URI otherwise.

This sounds horribly familiar. Didn't this come up some time ago? It
is an area I wrestled with several years ago, and never came up with a 
perfect answer to. I believe you need to check both the file extension
and the protocol (having expand the reference to a full URL
string). Only if its a file: protocol _and_ the extension is PDF do
you use the FileSpec link method. I'd say the onus should be on the
author to use the file: protocol if they want a local open in the same 
copy of the PDF viewer.


Sebastian