RE: [xsl] RE: XSL-FL Basic-link results in wrong Adobe Acrobat link action specified

["Echlin, Robert" <Robert.Echlin@xxxxxxxxxxxxx>]

Hi Ken,
Thanks for that.
I am responsible for some XSL-FO, and will need to edit it soon.
Rob


> -----Original Message-----
> From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, September 27, 2011 9:55 AM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [xsl] RE: XSL-FL Basic-link results in wrong Adobe Acrobat
link
> action specified
>
> At 2011-09-27 13:24 +0000, Sharon Harris wrote:
> >I am trying to dynamically create active hyperlinks in PDF output
> >using XSL-FO. The code I am using traverses the
> >Release_Notes_Documentation node, which then calls the hyperlink
> >template that specifies instructions for finding a string beginning
> >w/ http:// and turning that string into a basic link. Everything
> >looks great in the PDF output as the links display as active.
> >
> >Unfortunately, only the 1st occurrence of an active link works
> >correctly. Launches the browser to display the Web page associated
> >w/ the url. All of the other active links (contain different but
> >valid urls) do not launch a browser as the action specified when
> >viewing the link properties in Adobe Acrobat for the other links is
> >to "go to a page in another document" and "file" prefixes the url.
> >On the 1 active link that does work correctly, the action specified
> >in Adobe Acrobat is "open a web link".
> >
> >How do I ensure that all of the active links uses the "open a web
> >link" action?
>
> I suggest looking at the intermediate result of XSLT transformation
> before looking at your code.
>
> Carefully inspect every <fo:basic-link> that you create and determine
> if there is a difference between the first one and the remainder.
>
> If not, it could be a problem with your XSL-FO engine.
>
> If so, then it is a problem with assumptions in your XSLT.
>
> In the classroom I remind students of the debugging value of the
> intermediate XSL-FO output:  it is the first place I look when I have
> inconsistent output.  Staring at my code doesn't help because I
> should have done it right the first time around.  Inspecting the
> XSL-FO generated usually at least reveals my mistakes, if not how
> they were made.
>
> And to help with the debug, I will often inject diagnostic
> information in comments in my XSL-FO.  This is new to students who
> have already used XSL-FO.  Since an XSL-FO engine ignores the
> comments, I can find the XSL-FO that is rendered near where I have
> problems and inspect the comments to correlate behaviours in my
> stylesheets.
>
> I hope this helps.
>
> . . . . . . . . . . . . Ken
>
>
> --
> Contact us for world-wide XML consulting and instructor-led training
> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
> G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
> Google+ profile: https://plus.google.com/116832879756988317389/about
> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal