Hi all,

First, I do not have a Windows machine to try, so that's why I'm asking. I have a utility to convert ePub files to PDF, that uses Prince, and I got a report from someone using Windows relative to links between different files.

I think the problem could be reproduced with something like this:

1. Two files in a subdirectory: text\a.html and text\b.html
2. text\a.html contains a link to "../text/b.html", that is, the link contains part of the path, not just the filename
3. Convert with "prince.exe text\a.html text\b.html -o output.pdf" results in a PDF with a non-working link.
4. Convert with "prince.exe text/a.html text/b.html -o output.pdf" gives a correct PDF.

It seems that Prince accepts filenames with / or \ as path separators, but only / are matched with links in the files. Am I right? Is this intended behaviour or a bug?

This does reproduce the issue you describe. The problem is that URLs are matched against filenames textually, and "text/a" does not match "text\a". Some kind of input filename normalisation might help with this, although due to the complexity of different filename and URL conventions it may be a tricky issue to resolve.

But browsers don't have this kind of problem, they parse a link to "text/a" and translate it to the appropriate folder/directory separator for their OS (or network). I mean, if I open the "text/a.html" file in a Windows browser it will have no problem guessing that "../text/b.html" actually means "..\text\b.html". So I guess this issue is mostly solved in other software.

After all, I believe (I'm not sure, I don't have Windows to try) that using "text/a.html" in the command line is correctly translated (by the Windows itself, maybe?) into "text\a.html". Perhaps local URL can be processed in the same way.

We have now released a latest build that normalises file paths to avoid broken links! Hopefully this helps.