[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 #19 from David Lattimore <dml+webkit at google.com>  2013-03-17 17:19:27 PST ---
(In reply to comment #17)
> > 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.

I thought it might be possible to call addDestinationAtPoint from RenderObject::addPDFURLRect. I've now tried it and it doesn't work. Destinations only get written if they are on the same page as something that links to them. I thought that addPDFURLRect was getting called for each page and for each URL, but, probably fortunately for performance, it isn't.

I did some investigation as to where the GraphicsContext is getting created. It seems there is a new GraphicsContext for each page, created (at least for Chromium) in WebFrameImpl::printPage.

Given the above, I don't see any obvious options other than what I'm doing in my latest patch.

Is it a problem that I'm traversing the render tree for each page? The paint code already does that. One alternative to that would be to traverse it only for the first page, then store a HashMap on FrameView from names to elements that have been linked to. This could then be reused for subsequent pages.

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