Forum How do I...?

cross document links from relative paths in local files

ryanwist
I have a local (on the Windows file system, not served through localhost) web site. I'm using Prince to splice together a selection of pages from the site into a PDF. I have a problem with cross-document hyperlinks as seen in the following simplified scenario.

Sphinx is called from a one-line batch file to process a list of files:

sphinx -l list.txt -o mydoc.pdf


list.txt looks like this:

C:\site\main\main.html
C:\site\utility\functions.html
C:\site\process\information.html


The document "functions.html" is this (again, this is a simplification):

<html>
<body>
See <a href="../main/main.html#bookmark">main page</a> for information.
</body>
</html>


In a browser, that link works fine. However, when I build my the "mydoc.pdf" document, the link is incorrect. Hover over the constructed link, and an Acrobat tooltip reports the target as:

C:/site/utility/../main/main.html#bookmark


Click the link and it also reports this target in the ensuing dialog. Choosing "Allow" will cause it to load a browser with this:

file:///C:/site/main/main.html%23bookmark


The URL in the browser does not match what the tooltip or dialog said, and it will fail thanks to the "%23"; remove "%23" or change it to "#" and the page will load in the browser, because this is indeed the location of the file on my local file system. This would not work for anyone to whom I might give the PDF.

However, what I want is a link that works within the PDF. I was expecting that the relative link from the source html file would "pass through" to the constructed PDF, but that does not appear to be the case.

What am I missing? I'm pretty sure I missed something. Apologies if I missed the answer to this in an earlier post -- in which case, I missed that too even though I did search.

Thanks!
  1. site.zip31.8 kB
    simple example as described
mikeday
As you've found, there is an issue where paths are not always normalised when resolving links, which can result in some links failing to resolve. Currently the only way to avoid this is to structure the input filenames so that they match the paths used in the links exactly.

However this workaround isn't very convenient or satisfactory, so we will try and improve the situation by adding path normalisation. Sorry for the inconvenience in the meantime.
ryanwist
I greatly appreciate the reply -- I may have a problem or two, but at least it confirms the wall I'd perceived I was running into really is a wall, and not my own ineptitude. Thanks!