New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative links not working #1843

Closed
jedvardsson opened this Issue Jul 8, 2014 · 18 comments

Comments

Projects
None yet
7 participants
@jedvardsson

jedvardsson commented Jul 8, 2014

It seems like relative links aren't working. For example,

wkhtmltopdf http://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.html test.pdf

open test.pdf in a pdf-viewer and click on "overview" at the top of the first page. A browser window displaying "http://docs.oracle.com/javase/8/docs/api/overview-summary.html". However, on my Mac, the pdf viewer complains that it cannot open the link since it is relative "../../overview-summary.html".

I used wkhtmltox-0.12.1_linux-precise-amd64.deb to generate the pdf, and opened it on a Mac OS X Mavericks.

Edit: Fixing typos and grammar in third paragraph.

@mn4367

This comment has been minimized.

Contributor

mn4367 commented Jul 8, 2014

The link in the PDF you mentioned (OVERVIEW) points to another document, how should wkhtmltopdf resolve this link?

If I render AbstractMap.html on a Mac and click on OVERVIEW I don't get the error message you mentioned, simply nothing happens.

@mn4367 mn4367 closed this Jul 8, 2014

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jul 9, 2014

I think this behavior was last changed in a97c797. What is the behavior you are expecting?

@ashkulz ashkulz added the Invalid label Jul 9, 2014

@jedvardsson

This comment has been minimized.

jedvardsson commented Jul 10, 2014

Hi,

thank you for taking your time to look into this. However, when I generate
the page just now on my Debian Jessie machine with the official Debian 7
build (or on the Ubuntu machine mentioned earlier) I do get broken relative
links.

Right clinking on the OVERVIEW link in the Gnome PDF-view and
selecting "copy link" gives: ../../../overview-summary.html

Here is a link to the result.

https://dl.dropboxusercontent.com/u/51882490/Stream.pdf

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jul 10, 2014

Just describing what happens without mentioning what you expect does not help.

@jedvardsson

This comment has been minimized.

jedvardsson commented Jul 10, 2014

Sorry. I expect that relative links are converted into absolute ones with
respect to the url given on command line.

Below is the same page printed with Chrome from the original url. Clicking
copy link on the OVERVIEW link in this document gives you an absolute url
just as described.

https://dl.dropboxusercontent.com/u/51882490/Stream-chrome.pdf

When checking how Chrome treats relative links when printing from file (as
opposed to HTTP-urls) I see that it absolutizes relative file links as
well. I am not sure if I like that though. It's a bit scary to leak an
absolute file path.

2014-07-10 16:29 GMT+02:00 Ashish Kulkarni notifications@github.com:

Just describing what happens without mentioning what you expect does not
help.


Reply to this email directly or view it on GitHub
#1843 (comment)
.

@juzzlin

This comment has been minimized.

juzzlin commented Jan 13, 2015

Why is this bug invalid?

For example, the online demo at http://www.essentialobjects.com/Products/EOPdf/UrlToPdf.aspx renders the links in that Oracle page correctly.

I run into this with a page that had links like <a href="videos/video.mpg">Download video</a>. Other converters I tried concatenated the base url of the site to the link to make it work in the pdf (just like a browser sees the link), but wkhtmltopdf didn't.

@ashkulz ashkulz reopened this Jan 14, 2015

@ashkulz ashkulz removed the Invalid label Jan 14, 2015

@pixelb

This comment has been minimized.

pixelb commented Jan 21, 2015

This used to work on older versions. I would also expect the old behavior that,
relative links are converted into absolute ones with respect to the url given on command line.

@KAYLukas

This comment has been minimized.

Contributor

KAYLukas commented Apr 25, 2015

Hi, we updated our wkhtmltopdf version on our server and now we are having issues as well. The old behavior seems to be more logical, as PDFs are normally not relative: the whole idea of a PDF is that it contains the whole source no matter where the PDF is opened. Moreover, on OS X opening such a pdf and clicking on a relative link doesn't open the file relative to the document, but causes an 'unknown protocol' message.

That being said, can we revert this change by reverting issue a97c797 in the current source code?

@ashkulz

This comment has been minimized.

Member

ashkulz commented Apr 27, 2015

@KAYLukas: try it and see if it works 😃

@KAYLukas

This comment has been minimized.

Contributor

KAYLukas commented Apr 29, 2015

@ashkulz Done, seems to work correctly. Also added a flag to be able to toggle this behavior, such that everyone can be happy. (We actually do also have some usage for keeping the relative links).

I'm not to familiar with the project structure, so I hope someone can review my changes.

@ashkulz ashkulz added the Verified label Apr 30, 2015

@ashkulz

This comment has been minimized.

Member

ashkulz commented Apr 30, 2015

What is the use case for keeping the current behavior? I'd prefer not add an option, because even in your PR you mention that

Actually, it seems to not resolve relative links, the comment above seem to be incorrect?

So unless there is a valid scenario, I'd prefer simply reverting the change. Thoughts?

@ashkulz ashkulz added this to the 0.12.3 milestone Apr 30, 2015

@KAYLukas

This comment has been minimized.

Contributor

KAYLukas commented Apr 30, 2015

The comment suggests that it resolves links, while it just keeps relative links as relative links. While the comment suggests it shouldn't behave like it actually did, I do have some usage for these relative links.

I added the flag, because for my use case we need to generate relative links in a pdf, for usage in a mobile app where, where the relative links are used to denote files in the same package as the pdf. Before that let us keep the relative links, we had to parse and rewrite the whole pdf file to achieve this. But in any other case we need the behavior without keeping relative links.

I see this option appear in other products as well (https://www.bluebeam.com/us/support/articles/ask-greg/7-11.asp, http://stackoverflow.com/questions/17800596/relative-file-links-in-pdf-files). I think the main usage would be when considering a package of pdfs that link to eachother.

Currently, I left the current behavior as the default behavior, I guess it would be better to let the default behavior be the new behavior.

Any ideas?

KAYLukas added a commit to KAYLukas/wkhtmltopdf that referenced this issue May 31, 2015

keep relative links only if --keep-relative-links is given
Relative links were not being resolved anymore, after wkhtmltopdf#4.
This caused issue wkhtmltopdf#1843, as PDF files should typically be self contained
and should not rely on relative files, this behavior was reverted. Keeping
relative links as relative links can still be done using --keep-relative-links.
For completeness a flag --resolve-relative-links was added.

@ashkulz ashkulz added Fixed and removed Verified labels Jun 1, 2015

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 1, 2015

The fix has been merged

@ghost

This comment has been minimized.

ghost commented Jun 2, 2015

Hello, I guess I don't quite understand if this is fixed or not reading this?
Should we expect relative links to work or not?

Thanks!

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jun 2, 2015

Read the commit message for bac3fbf, both behaviors are supported.

DanielCeregatti added a commit to DanielCeregatti/wkhtmltopdf that referenced this issue Jun 24, 2015

keep relative links only if --keep-relative-links is given
Relative links were not being resolved anymore, after wkhtmltopdf#4.
This caused issue wkhtmltopdf#1843, as PDF files should typically be self contained
and should not rely on relative files, this behavior was reverted. Keeping
relative links as relative links can still be done using --keep-relative-links.
For completeness a flag --resolve-relative-links was added.
@ashkulz

This comment has been minimized.

Member

ashkulz commented Jul 14, 2015

A preview for the next release 0.12.3-dev-79ff51e is available, which should contain the fix for this issue. Please report back if it is not solved with the above version.

Please note that the above downloads will be removed after the 0.12.3 release.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jan 21, 2016

0.12.3 has been released, which should contain the fix for this issue. Please report back if it is not solved with the above version.

Note that the preview downloads mentioned above have been removed.

@bismaya123

This comment has been minimized.

bismaya123 commented Oct 11, 2017

Hi Even i have the same issue, while converting html to pdf using wkhtmltopdf, the page number in the index has link to specific page number in html file. but the link somewhere is breaking and always targeting to the default home page irrespective of the page number in pdf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment