Bug 25866 - Printing using media type other than "print"
Summary: Printing using media type other than "print"
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 29861 30621 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-05-19 09:19 PDT by Jakob Truelsen
Modified: 2016-05-27 02:34 PDT (History)
5 users (show)

See Also:


Attachments
Patch implementing screen mediatype printing (3.53 KB, patch)
2009-05-19 09:19 PDT, Jakob Truelsen
eric: review-
Details | Formatted Diff | Diff
Now with corrected whitespace (3.54 KB, patch)
2009-05-20 00:50 PDT, Jakob Truelsen
mjs: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jakob Truelsen 2009-05-19 09:19:07 PDT
Sometimes it would be nice to print using the screen media type instead of papir, e.g. when you print a page to pdf document most of the time you will want it to look exactly like it did on screen.
Comment 1 Jakob Truelsen 2009-05-19 09:19:56 PDT
Created attachment 30474 [details]
Patch implementing screen mediatype printing
Comment 2 Eric Seidel (no email) 2009-05-19 19:41:42 PDT
Comment on attachment 30474 [details]
Patch implementing screen mediatype printing

The spacing around usePrintMediaType=true does not match WK Style guidelines: http://webkit.org/coding/coding-style.html

But why do we want this?  When are pages going to specify a print media type and the user wish to override it?  This kind of override is not possible in normal applications on the desktop.

What port would use this flag?
Comment 3 Jakob Truelsen 2009-05-20 00:50:24 PDT
Created attachment 30499 [details]
Now with corrected whitespace

I'm using it in this application:
http://code.google.com/p/wkhtmltopdf/

I will submit the patches to the QT port later if/when this gets accepted
Comment 4 Alexey Proskuryakov 2009-05-21 06:29:50 PDT
Could you achieve the same by removing unneeded stylesheets from DOM before printing?

It seems strange to special case "print" and "screen" - e.g. "projection" is something that clients may want to print, too.
Comment 5 Maciej Stachowiak 2009-05-22 00:47:30 PDT
Comment on attachment 30499 [details]
Now with corrected whitespace

r- based on Alexey's comments. Does his suggested workaround work? If so, we probably shouldn't hack WebCore to add this capability.
Comment 6 Jakob Truelsen 2009-05-22 03:17:20 PDT
I do not believe that the workaround will work. Most pages have no css that talk directly about mediatype, however WebKit (and other browsers) render it very differently anyways. I could just be some different default CSS values, but I think that this is not the case.
Comment 7 Alexey Proskuryakov 2010-06-12 15:39:07 PDT
*** Bug 29861 has been marked as a duplicate of this bug. ***
Comment 8 Alexey Proskuryakov 2010-06-12 15:39:14 PDT
*** Bug 30621 has been marked as a duplicate of this bug. ***
Comment 9 Jack Cushman 2014-04-10 07:25:55 PDT
The need for this patch (and various workarounds) is still being discussed downstream, primarily at:

https://github.com/ariya/phantomjs/issues/10623

But also e.g.:

https://github.com/ariya/phantomjs/issues/10669
https://groups.google.com/forum/#!topic/phantomjs/AD3zyRdkkfs
https://groups.google.com/d/topic/phantomjs/AU84T8K5zsg/discussion
https://github.com/imakewebthings/deck.js/issues/121

The usecase is, when you are using a headless browser like PhantomJS, it is often desirable to take a screenshot that:

(1) accurately reflects what a user would see in the browser;
(2) uses vector rather than raster format (much higher quality, much lower file size).

Both are 'easy' to accomplish by printing to PDF with the desired media type.

As Alexey noted, there are workarounds that try to manipulate the DOM to make the print media type look right, but they can't be counted on to fulfill goal (1) for arbitrary pages.
Comment 10 Simon Scheurer 2015-04-29 00:18:27 PDT
There are many requests regarding this feature and the answer is often:
a) What is the use case and 
b) Why don't you change the page styles before printing

For us the use case is to provide proof in case of litigation (for the end user but as well for corporates). We have a solution to record web publication and also interactions and from given interaction points create PDFs because they are easier to transport and retain.

It is essential there that the page can be captured the way the user has seen it and not in some print view that is different.

We cannot change the page styles, because the solution can be applied to any web-page. We cannot just ask all the customers to change all their pages.

it would be enough to even have some global configuration flag to trigger a given behavior (that by default is obviously the way it is today). But it is really a pity, that there is simply not other option currently than to use a patched version of WebKit (we just adjust
void FrameView::adjustMediaTypeForPrinting(bool printing)
{
    if (printing) {
        if (m_mediaTypeWhenNotPrinting.isNull())
            m_mediaTypeWhenNotPrinting = mediaType();
            setMediaType("print");
    } else {
        if (!m_mediaTypeWhenNotPrinting.isNull())
            setMediaType(m_mediaTypeWhenNotPrinting);
        m_mediaTypeWhenNotPrinting = String();
    }
}
in https://github.com/ariya/phantomjs/blob/master/src/qt/qtwebkit/Source/WebCore/page/FrameView.cpp). We would like to have the option to just work with an unpatched version.