I disagree this has nothing to do with webkit: Is the webkit team aware that when printing half of all the web pages out there the output looks like doodoo?

Whatever the CSS, having the pages print out in a totally ugly way is just plain silly. Surely using the "screen" stylesheet for printing is better than no stylesheet at all?

I propose that WebKit use the "screen" stylesheet for printing if there is no "print" stylesheet present in the source document.

I think half of all web pages out there is probably an exaggeration. I think most authors use "all" for the media type unless they are specifically targeting the screen. The Surfin' Safari blog had discussed a common mistake of using device dependent units when using the "all" media type, but I guess WebKit already adjusts for that. I could imagine a site targeting the screen with a design really only meant for the screen. Printing using that CSS would be worst than falling back on the default stylesheet. take care, Rob

On Oct 7, 2006, at 8:01 PM, Mike Emmel wrote:

On 10/7/06, Rob Burns <robburns1@mac.com> wrote:

...

...

I disagree this has nothing to do with webkit: Is the webkit team aware that when printing half of all the web pages out there the output looks like doodoo?

Whatever the CSS, having the pages print out in a totally ugly way is just plain silly. Surely using the "screen" stylesheet for printing is better than no stylesheet at all?

I propose that WebKit use the "screen" stylesheet for printing if there is no "print" stylesheet present in the source document.

I think half of all web pages out there is probably an exaggeration. I think most authors use "all" for the media type unless they are specifically targeting the screen. The Surfin' Safari blog had discussed a common mistake of using device dependent units when using the "all" media type, but I guess WebKit already adjusts for that. I could imagine a site targeting the screen with a design really only meant for the screen. Printing using that CSS would be worst than falling back on the default stylesheet.

take care, Rob

Since the case of a screen only css style sheet can be detected does it not make sense to make using it an option of the print dialogue. In fact a more general ability to pick a alternative style sheet when printing might have other uses. Or this could be a user option in the browser turned on by default. Or it could cause a warning or alert and let the use choose.

The chance of no style sheet vs screen only being correct in the real world is probably close to zero.

As I said before, I think this is a discussion not too related to WebKit, but more to the application developers who may use WebKit or any other engine to create a user-agent. My understanding is that WebKit already has the needed methods to handle this at the application level. However, let me just add that CSS is designed to give authors rich capabillities in terms of presentation and when an author selects "screen" instead of "all" as the media they're targeting for their stylesheet, that says something. And it's something that user-agents and users themselves should take seriously. Could it be a little mistake with large consequences? Yes. But it couls also be the authors intent. And building user-agents that gloss over those mistakes just make the mistakes more prevalent. So if many authors use a WebKit based application to test their designs and that application makes "screen" seem like "all" then such mustakes will proliferate. That's a concern that application developers should keep in mind. take care, Rob

Am 08.10.2006 um 02:26 schrieb peliom@tikirobot.net:

Thanks for clearing this up.

You're welcome.

...

BTW. This question has nothing to do with the development of webkit. It would be better placed on web-dev- request@lists.apple.com or some other HTML/CSS forum.

Well, my apologies. The output was so terrible I thought it was bug in webkit.

OK, no problem.

I disagree this has nothing to do with webkit: Is the webkit team aware that when printing half of all the web pages out there the output looks like doodoo?

Yes in that sense it does have something to do with webkit. Webkit does the correct thing w.r.t. media types for CSS. Some websites don't. (I don't agree with you assertion that "half of all the web pages out there" are affected though. Do you have any concrete proof of this?) Generally speaking I'd contact the authors of the websites that produce wrong output instead of asking one browser team to cater to broken code. (Even if Safari/webkit where to change, what happens if you use Firefox or IE or some other browser to print the page?) Instead you could lobby for the standards to be changed so that all browsers could try to somehow cater to broken websites. (OK, that would most likely not happen but think about the reasons.) Another thing to think about is this: How often do you (or people in general) actually print a web page? I do this mostly for invoices or similar receipts in which cases I care more about the content than the formatting. Does this justify making the browser behave in a non- standard way? Possibly with side effects none of us have really thought about yet?

Whatever the CSS, having the pages print out in a totally ugly way is just plain silly. Surely using the "screen" stylesheet for printing is better than no stylesheet at all?

I don't agree with this at all. When I see the media type screen specified I assume that the author chose that media type on purpose and didn't want this stylesheet to be used for other media including printing. The website you had trouble with is actually an excellent example for this. Without the stylesheet it prints out in a very legible form without loosing any important information. So without actually knowing the intent of the author I'd feel safe to say that this is actually a well done website (w.r.t. to the printing issue).

I propose that WebKit use the "screen" stylesheet for printing if there is no "print" stylesheet present in the source document.

I propose to keep webkit the way it is for the default case. I do see the need to sometimes capture a web page exactly as you see it on screen. There are two mechanisms already in place to do this: screenshots and webarchives. Screenshots have the drawback of only capturing the visible part of a web page. Webarchives are not completely static, as the content might be rendered differently when they are displayed due to different plug-ins or a different versions of webkit for example. Maybe we need an optional third mechanism where you "print" a page while specifying a media type other than "print". Come to think about it why limit this setting to printing? How about an option to have webkit use an arbitrary media type setting for display on the screen as well? It would be useful when designing websites for alternate media types, I'm sure. I don't know if this would be a webkit enhancement or something to build into Safari or both. Probably the later as webkit would need to have the actual functionality and Safari would need to add the UI. How about filing an enhancement request on Safari and/or webkit? Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html>

On 10/8/06, Allan Sandfeld Jensen <kde@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. The default setting in the print dialog should be to use the screen css if no print css is specified. This has nothing to do with standards. At worst a warining about this situation could be displayed. The logic is that if it needs a style sheet for the screen the chance of not needing one for printing is slim. The choice of style sheet would be by default 1.) User defined 2.) Print css 3.) Screen css 4.) No css ( system css) Preferences can be used to change the order.

Regards `Allan

_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev

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

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

On Oct 8, 2006, at 11:33 AM, peliom@tikirobot.net 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