On Oct 8, 2006, at 11:33 AM, [EMAIL PROTECTED] wrote:
These are interesting features, but they miss my original point.
It is my own fault, I have been debugging this situation and so
didn't give enough context: My code is calling the NSView API:
[webview dataWithPDFInsideRect:[webview frame]]
Perhaps now my request makes a bit more sense: this API does not
say anything about printing, either in the API itself or its
documentation. As a developer I am expecting a PDF representation
of the WebView (emphasis on "view" here)
Obviously WebKit is using it's printing subsystem to generate this
PDF, which is entirely reasonable except for the fact that when
WebKit is generating PDF, it apparently assumes the PDF is being
sent directly to a printer. This is not necessarily the case, and
dataWithPDFInsideRect looks terrible if the site author has
mislabeled their CSS as media="screen". Regardless, my expectation
as a developer is that dataWithPDFInsideRect *is* screen media.
I think another explanation is that PDF is inherently a paged
document format. The "print" media type is a bit of a misnomer in
that it applies to visual paged media even when that visual paged
media is viewed on screen. If designers wants to target PDF output
with their CSS they will need to use the "print" media type with
their CSS.
On Oct 8, 2006, at 12:55 PM, David D. Kilzer wrote:
This is a known issue that is being worked on:
PDF created by printing should have live hyperlinks
http://bugs.webkit.org/show_bug.cgi?id=10216
Is there anyway pj could turn this stuff back on when not printing?
take care,
Rob
_______________________________________________
webkit-dev mailing list
webkit-dev@opendarwin.org
http://www.opendarwin.org/mailman/listinfo/webkit-dev
