[webkit-dev] a question on printing: whither WSIWYG?

[peliom at tikirobot.net]

On Oct 8, 2006, at 8:09 AM, Mike Emmel wrote:

> On 10/8/06, Allan Sandfeld Jensen <kde at carewolf.com> 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.