On Oct 8, 2006, at 8:09 AM, Mike Emmel wrote:
On 10/8/06, Allan Sandfeld Jensen <[EMAIL PROTECTED]> wrote:
All this boils down to is two different ideas of printing really:
1. Print as specified in CSS. This typically produces better
output in pages
that have been designed for printing.
2. Print screenshot. This produces an exact print of what is seen
on the
screen. This produces worse results in some cases due to page-
breaking
problems etc.
1 is nice for printing papers, but 2 is what most users expect.
A choice like this "should" be available in a print dialog.
Add
3.) Print with a user specified css stylesheet.
Default choices would be the screen style sheet and the style sheet
for printing defined by the page author.
A user specifed style sheet when printing allows you to get it
just right tm.
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.
My application is not printing at all. I am creating PDF
representations of web pages for a browser that caches the
representations. These PDF representations consume very little RAM,
and have the added advantage of loading into a view quickly. A PDF
representation loads into a PDFView in a fraction of a second. I
started out using WebArchives, but realistically a typical web page
takes 1-4 seconds before it is fully loaded even if it is in
WebArchive format. A lot of web sites use "no-cache" (for whatever
reason), and there are often other dependent resources,
advertisements, etc.
So hopefully the problem I am running into makes more sense now. I
was asking about printing because dataWithPDFInsideRect was giving
the same result as printing with Safari, hence I assumed at first
there is a bug with Safari/WebKit printing.
Now I am just looking for API, public or private, to turn off this
media="screen" business so I can get on with my application. And you
guys are going to love my next question :-)
PDF format supports hyperlinks, so I am wondering why
dataWithPDFInsideRect doesn't preserve hyperlinks? Is there is a
technical reason or is this just a feature that hasn't been
implemented yet? The API CGPDFContextSetURLForRect() does exists, so
it seems like this should be possible.
Thanks,
.pj.
_______________________________________________
webkit-dev mailing list
webkit-dev@opendarwin.org
http://www.opendarwin.org/mailman/listinfo/webkit-dev
