[Webkit-unassigned] [Bug 112081] Printing to PDF should produce internal links when HTML has internal links

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=112081





--- Comment #18 from David Lattimore <dml+webkit at google.com>  2013-03-15 00:05:01 PST ---
(In reply to comment #17)
> > Agreed. Not sure I have sufficient familiarity with WebKit to know where and how to write such a test. Ideally it'd run WebKit headlessly on an input HTML file, render to PDF then make assertions about the contents of the PDF. I've got no idea how straightforward it would be to run WebKit in this manner.
> 
> The hardest part here is to make assertions about contents of produced PDFs, and to a lesser degree, adding plumbing to produce a PDFD. Headless operation is what regression tests do normally, and we have 30000 of them.

The assertions I think I can manage, since both the links and the destinations end up in the PDF in plain text. It's the plumbing parts that I'm unsure of.

> > In any case, at the Skia level, we definitely have a different SkPDFDevice/SkCanvas for each page and the destinations need to get written to the correct SkPDFDevice for the page that the destination appears on. So unless there is some way to get access to a random page's SkCanvas, the destinations need to be put out while the page containing those destinations is being rendered.
> 
> Are you talking about pages in a produced PDF, or about subframes? There is something here that feels wrong, but I can't put my finger on it.

AFAIK there should be one SkPDFDevice and on SkCanvas per page in the produced PDF.

I've got some ideas that I'll investigate on Monday (Sydney time) that may mean it would work to add the destinations from RenderObject (like you originally suggested).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.