Received HM's preface article for vol 40, and marked it up. In the process, I marked up a series of references to the other articles in the issue, using relative links. This threw up a new situation in the PDF export. Previously, I was handling two distinct cases of links in PDF output:

• Those beginning with #, being internal links; easy to process into internal PDF links.
• Those beginning with http, being external Web links, also easy to process into external PDF links.

Now there was a third case:

• Those not beginning with a hash, and not containing a protocol, meaning that they're relative.

Relative links don't work in PDFs because they're typically downloaded to a temp folder and opened from there. It was necessary to reconstruct the full original URL of the request so that I could build a full link, to create a proper PDF external link. The Cocoon {request:requestURI} variable, available in the sitemap, should, according to the documentation, give you the full URI, but it doesn't; it gives you only the path after the port. After some reading around, I found the solution. In the sitemap, you pass this into the XSLT transformation:

<map:parameter name="browserURI" value="{request:scheme}://{request:serverName}:{request:serverPort}{request:requestURI}" />

giving you a variable with the full request path, and then you can do this, to reduce the path to its directory, in the XSLT:

<xsl:param name="browserURI" />
  <xsl:variable name="uriDirLength" select="mdh:lastIndexOf($browserURI, '/')" />
  <xsl:variable name="docPath" select="substring($browserURI, 1, $uriDirLength+1)" />

I'm blogging this in detail because the Cocoon documentation is ropy in this area, and I've previously tried to figure this out and failed.