[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 #29 from David Lattimore <dml+webkit at google.com>  2013-04-01 19:33:28 PST ---
Sorry about the slow reply - we had a 4 day weekend here in Australia.

(In reply to comment #27)
> (From update of attachment 194404 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=194404&action=review
> 
> > 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.
> 
> I don't understand how this can work. If every page is separate, how do cross-page links work at all? Surely there is an object in Skia that represents the whole multi-page document? For example in CG, it's a CGPDFContext, and one calls CGPDFContextBeginPage when moving to the next page.

There's SkPDFDocument. It represents the whole PDF document. The destinations still need to be written to the correct SkPDFDevice for the page they're on though.

> > Source/WebCore/platform/graphics/skia/GraphicsContextSkia.cpp:1113
> > +    return platformContext()->printing();
> 
> I'm not sure if this is a good place to make such checks. A GraphicsContext may not have any idea about whether it's printing or not, it's the responsibility of both higher level and lower level code.

So I should just revert this to return true here? Now that adding the destinations is being done in PrintContext, it will already only be getting run if we're printing. That only leaves linking to destinations which doesn't really do any significant amount of work, so is probably OK to do even if the underlying Skia device doesn't support it.

(In reply to comment #28)
> Created an attachment (id=195162)
 --> (https://bugs.webkit.org/attachment.cgi?id=195162&action=review) [details]
> with non-funcitonal CG support
> 
> I tried making a patch that works with CG too, but for some reason, a resulting document has no clickable links at all. Perhaps rects are represented in a way that's different from how it's done elsewhere?

Presumably it would need to apply transforms in a similar way to what the CG implementation of GraphicsContext::setURLForRect does. That said, I tried doing that and it still didn't work. Looking at the generated PDF in a text editor, neither the destinations nor the links to the destinations are being put out. I've got no idea why not.

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