Phantomjs: When rendering to PDF, turn relative fragment identifiers into "bookmark" links

[anko]

Hello from https://github.com/alanshaw/markdown-pdf/issues/66.

Currently, HTML documents that refer to another part of the document with a fragment identifier (like #id-of-heading) when rendered to PDF creates a clickable link pointing to an absolute path to the .html page being rendered.

Currently, clicking on such links in the rendered PDF opens a web browser.

I expected such links to become "bookmark" links that simply link to the relevant part of the same PDF document.

---

Concrete example:

This renders the Wikipedia page for PhantomJS, where the table of contents has relative links that are just fragment identifiers.

var page = require('webpage').create();
page.open('https://en.wikipedia.org/wiki/PhantomJS', function(stat) {
  page.render('out.pdf');
  page.close();
  window.phantom.exit();
});

Clicking links in the generated PDF's table of contents opens a web browser.

[caleblloyd]

An example can be seen here:

Phantomjs 2.1.1:
https://caleblloyd.com/downloads/pdf/phantomjs.pdf
The Table of Contents links in the PDF Document open up to the original HTML document instead of the correct page in the PDF.

Latest Chromium:
https://caleblloyd.com/downloads/pdf/chromium.pdf
The table of contents links work fine.

code used to generate phantomjs pdf was rasterize.js with 144dpi:

phantomjs rasterize.js http://www.sec.gov/Archives/edgar/data/789019/000119312516441821/d15167d10q.htm test.pdf

[ckreon]

It would be great if we could figure out why this was happening - I'd love to get inter-document links working!

[jasonswearingen]

the problem is pretty straight forward, it's treating the link as a link to the absolute url. the solution isn't just converting the link to be a relative fragement unfortunately (i tried that!) as the fragment location is also not preserved.

[astefanutti]

Clickable links in PDF export have been introduced recently with Vitallium/qtwebkit@ef91a25 and Vitallium/qtbase@d50c481. For the time being, hyperlinks are currently rendered as PDF link annotation with the URI action irrespective whether they happen to be internal links or not. This should be possible to detect internal links and have them rendered as GoTo action instead of URI, as defined in the PDF specification.

This is something we'd like to have as well in DeckTape: astefanutti/decktape#49.

[jasonswearingen]

@astefanutti uri actions such as `"#nameddest=TOC"`` would also work. but they don't because

1) the links are created absolute, not relative, and don't have "nameddest=" included.
2) the targeted fragment location is not kept in the resulting pdf

[wazico]

Does anyone find a way to do it ? I'm working on it since days without any good result.
I did a script to transform absolute to relative (#page=1) urls used as /URI in pdf document but it only works in browser (adobe reader try to open a local file instead of moving inside the document).

Do you know Table of content generation is in the roadmap of phantomjs. I would love it ! :)

[Nikolay-Kha]

+1 for this issue.

[ZhichaoY]

+1 for this issue. it would be a great improvement.

[v-anyukov]

+1

[mwittmann]

+1 +1 +1!
Just discovered this limitation. :-(
Yes, any href="#..." links should be converted to internal PDF bookmark links.

[mattbryson]

+1

[aasshishpatil]

+1

[saad749]

+1000

[xu4wang]

+1

[anko]

Could folks please refrain from spamming "+1"? I want to keep following this thread, but getting notifications for contentless replies is annoying.

Please instead use the handy "+1" button that Github has introduced for this exact purpose:

[AnthonyYY]

+1

[stale[bot]]

Due to our very limited maintenance capacity, we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed (see #15395 for more details). In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!