If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

The "Print" (in "File" Menu) should render Pages as well as the Browser Windows does

RESOLVED INVALID

Status

()

Core
Printing: Output
RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: Rob, Unassigned)

Tracking

6 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
Build ID: 20110830092941

Steps to reproduce:

When viewing _most_ Pages they are rendered well in Firefox BUT trying to print them is another matter entirely.

BUG: The "Print" (in "File" Menu) should render Pages as well as the Browser Windows does.


Actual results:

- When I use the Browser's [File][Print] to print a Page then "bits of it are not too bad", but much of it is not very good.

- If I use the [PrintScr] Key to copy a screenshot to the Clipboard and then open a 'Graphics Utility' (such as IrfanView http://www.irfanview.com/) to print the screenshot I get a beautiful rendering, but only what can fit on my Screen. 

I would need to scroll the Browser Window, hit [PrintScr] and paste each screenfull together to print the whole URL's Page - what a LOT of hassle, why doesn't Firefox send a PROPER rendering of the Page to the Printer.

PS: Here is the "Free Printer" I am using: http://www.cutepdf.com/Products/CutePDF/writer.asp - It is a decent replacement for the "Quicken PDF Printer" from the "Amyumi Document Converter".



Expected results:

What I see in the Browser's Window (the "Layout" and the colors) should be sent to the Printer EXACTLY as they appear on the screen.

Even a checkbox that would send a HUGE image would be better than the terrible rendering (that likely saves a lot of bandwidth) which misses so much of the 'intent' of the Page that it is only a poor representation and hardly a "Print" of the Page.


PS: Almost ANY page (except the simplest text file) shown in the Browser will [Menu][Print] nowhere near as good (layout and color exactness) as printing a screenshot from IrfanView (or even MSPaint).

Comment 1

6 years ago
If you mean the background and some images and styling, FF intentionally scrubs that to keep your printer from wasting half a cartridge of ink printing a blue background on a page (exaggeration, but the point still exists). If you want to re-enable it, go to [Firefox] -> Print -> Page Setup, and check "Print Background (colors & images)". Then, try printing again.

Updated

6 years ago
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
(Reporter)

Comment 2

6 years ago
(In reply to Hmmwhatsthisdo from comment #1)
> If you mean the background and some images and styling, FF intentionally
> scrubs that to keep your printer from wasting half a cartridge of ink
> printing a blue background on a page (exaggeration, but the point still
> exists). If you want to re-enable it, go to [Firefox] -> Print -> Page
> Setup, and check "Print Background (colors & images)". Then, try printing
> again.

I have that set, it is not what I mean.

Try doing a comparison using the STR and re-reading the BR; thanks for your input though...


- In _THIS_ case there is NO ink because it is a "Virtual Printer" and converted to a ".PDF".
- The Browser 'over-scrubs' and wrecks the layout and what colored areas it does reproduce are way off color -- you will likely get better results on SOME Web Pages as opposed to others. 

I am OK with a checkbox to choose between "no background" (which we have) and another checkbox for "print every second pixel" (if you are cheap with your Ink). If you want a third checkbox for "precise layout" vs. "wing-it and just show me something, anything, please" I do not favor that and I see no purpose for it.


If we (the Browser) can figure out what we "think" the Web Page OUGHT to look like (right OR wrong), and display it on the Screen, then lets send the SAME RENDITION to the Printer (minus the Background IF that box is checked).

There is too much missing and some Elements are NOT being rendered, in addition the layout is completely re-arraigned on (SOME) Web Pages. Let us Print exactly what we see (though it does not have to be sent as a Bitmap - or does it).

BTW: IE is not much better at this (correct rendering to the Printer) though it gets different results on the same Pages.

Comment 3

6 years ago
Please provide a specific site to use as a testcase.
(In reply to Rob from comment #2)
> If we (the Browser) can figure out what we "think" the Web Page OUGHT to
> look like (right OR wrong), and display it on the Screen, then lets send the
> SAME RENDITION to the Printer (minus the Background IF that box is checked).
[...]
> Let us Print exactly what we see (though it does not have to be sent as a Bitmap -
> or does it).

It's not that simple.

When you view a page in your browser, there's basically an infinite-length unbroken canvas (potentially infinite-width, too, if pages want to use a horizontal scrollbar).
When you print, it's quite different -- there are discrete fixed-size containers (pages) that your browser has to cram content into, with no possibility of scrollbars and with some amountof broken continuity between pages.  (so e.g. we try to position images such that they don't overlap a page boundary)

There are absolutely situations where Firefox paginates incorrectly / poorly -- and we try to fix those when we find instances of that -- but "Print exactly what we see" is a non-goal, generally.

> BTW: IE is not much better at this

Sure -- all browsers need to paginate printed content, and they all hit issues like this (though not exactly the same ones).

(In reply to Rob from comment #0)
> PS: Almost ANY page (except the simplest text file) shown in the Browser
> will [Menu][Print] nowhere near as good (layout and color exactness) as
> printing a screenshot from IrfanView (or even MSPaint).

If you've got a *specific* page with a specific issue, let's make this bug be about that.  Otherwise, this is essentially a duplicate of the metabug bug 521204.
(Reporter)

Comment 5

6 years ago
(In reply to Daniel Holbert [:dholbert] from comment #4)
> (In reply to Rob from comment #2)
> > If we (the Browser) can figure out what we "think" the Web Page OUGHT to
> > look like (right OR wrong), and display it on the Screen, then lets send the
> > SAME RENDITION to the Printer (minus the Background IF that box is checked).
> [...]
> > Let us Print exactly what we see (though it does not have to be sent as a Bitmap -
> > or does it).
> 
> It's not that simple.
> 
> When you view a page in your browser, there's basically an infinite-length
> unbroken canvas (potentially infinite-width, too, if pages want to use a
> horizontal scrollbar).


Lets us assume that when I use Cursor Keys, Page Keys, or mouse-grab the Scrollbar and yank as far as it will go (up or down / left or right) that the exact "Page Size" is exactly THAT size, ASSUMING I print the Page at that moment - if the Page's size is dynamically updated then it is the NEW size at the moment it is printed.

How to determine length:
I expect the size of the printed Web Page to be as wide and as long (SEE CAVEAT in next sentence) as the Paper (minus the Borders) with the width at 100% scale. 

The length of a printed Page that is 'too long' is determined by the width - once the width is calculated (at 100% minus the left and right border) then the length of the Page is scaled by that same number AND if that does not fit on ONE Page then we simply eject the Sheet and continue on the next Page.

(Note: one whack on the [Page Down] Key is not the same length as a printed Page.)


> When you print, it's quite different -- there are discrete fixed-size
> containers (pages) that your browser has to cram content into, with no
> possibility of scrollbars and with some amountof broken continuity between
> pages.  (so e.g. we try to position images such that they don't overlap a
> page boundary)
 
It would be called removing Orphans, if it were Text; not such of the terminology for images.

We don't do it on the Browser's Page but doing so on a printed Page makes sense - unless it leaves more that 25% of the bottom of the prior Page blank, then we should have some on the bottom and the rest on the next Page.


> There are absolutely situations where Firefox paginates incorrectly / poorly
> -- and we try to fix those when we find instances of that -- but "Print
> exactly what we see" is a non-goal, generally.
> 
> > BTW: IE is not much better at this
> 
> Sure -- all browsers need to paginate printed content, and they all hit
> issues like this (though not exactly the same ones).


My complaint is NOT about Pagination (though I would like Pagination to work as I described above).


Let me explain it this way ...

You use CSS to make 2 Layers. On the first Layer you render some of the HTML content. Next you render more content on the second CSS Layer. Now when you print you only print the first Layer and ignore the second one.

I am NOT saying that this IS what is happening, I am saying that is what it LOOKS like.


 
> (In reply to Rob from comment #0)
> > PS: Almost ANY page (except the simplest text file) shown in the Browser
> > will [Menu][Print] nowhere near as good (layout and color exactness) as
> > printing a screenshot from IrfanView (or even MSPaint).
> 
> If you've got a *specific* page with a specific issue, let's make this bug
> be about that.  Otherwise, this is essentially a duplicate of the metabug
> bug 521204.

I checked 521204 and that is focused on Pagination. I am focused on "rendering" - IE: "layout of ALL the Elements (background is excludable)", "layout of the Elements in relation to each other", and "color" (close enough and not washed out).

----------

Examples:


1. This Page - not the best example but the MOST obvious one, click [File][Print Preview] now. Other Pages work out worse and show MORE problems (like the next example).


2. https://bugzilla.mozilla.org/ - The top and bottom are missing, only the middle is previewed. The (REAL) "top" starts at "Bugzilla@Mozilla – Main Page" and ends with your 'login name', the "bottom starts at "Home | New | etc." and ends with "Privacy Policy". 

Figure out your widest Element (likely the "Home | New | etc." line) and scale that to 100% of the Page width (minus the Printer's Page's Borders on left and right sides). Now use that multiplier on the length and you've got how long the Page is (it is not as long as it is wide so it's approximately a quarter Page).


3. http://www.cnn.com/ -- The widest Element in the Menu is not calculated and so the right side of the Page is simply chopped off.


4. http://www.google.com/intl/en/about/corporate/index.html -- The images are missing and the Page looks like it was ran through "html2text" before it was printed. A simple single Page (or a Page and a quarter, if your screen size is not 1920x1200) is turned into a TWO FULL Pages.


There are so many more (millions). Again it is nothing to do with Pagination (yet I don't want that wrecked too, that is easy to calculation once you know the width). Call it "Rob's Plea for WYSIWYG" if you wish, I call it NO "wing-it and just show me something, anything, please".


I am tempted to give the URL for the Emperor (and his lacking attire) if you ask for another example. 

:) (Thank you for reading my complaint).

YT,
Rob
Just addressing your testcases, to keep this comment reasonably-sized:

> Examples:
> 1. This Page - not the best example but the MOST obvious one

I don't see anything particularly busted on print-preview of this page.  If you're referring to the header/footer content, read on.

> 2. https://bugzilla.mozilla.org/ - The top and bottom are missing, only the
> middle is previewed.

Correct.  That's what's supposed to happen, as specified in the page's CSS. Quoting https://bugzilla.mozilla.org/skins/standard/global.css:
> /* Rules specific for printing */
> @media print {
>     #header, #footer {
>         display: none;
>    }

So -- the page explicitly asks for that content to be hidden, when rendered for printing.

Continuing...

> 3. http://www.cnn.com/ -- The widest Element in the Menu is not calculated
> and so the right side of the Page is simply chopped off.

This actually works correctly for me. (I checked nightly build as well as Firefox 6.0.1, on Ubuntu Linux).  The rightmost content that I see on the page is at the right side of my print-preview window, un-cropped.  Could be OS-specific due to font sizes or something.

> 4. http://www.google.com/intl/en/about/corporate/index.html -- The images
> are missing and the Page looks like it was ran through "html2text" before it
> was printed.

Correct.  As above -- this is what's supposed to happen per the page's CSS.

If you view-source and click on "default.css", you'll see this:
> @media screen, projection {
>   body {
>     min-width: 640px;
[Basically all of the style]

For reference, see http://www.w3schools.com/css/css_mediatypes.asp

So -- in 3 out of your 4 examples, we're doing the right thing.  At CNN, I don't know what the problem is since I can't reproduce it, but there are a number of things that could be going on.  That would be worth tracking in a bug. Shall we make this bug about that?
(In reply to Rob from comment #5)
> How to determine length:

Right, we do something along the lines of what you describe. Basically, we behave as if you have a series of page-sized containers to render into -- we start rendering stuff into the first, and when something doesn't fit, we push it to the second (or split it in some cases, when possible), etc.

Also, as you suggested, we (sometimes unsuccessfully) detect when content is too wide to fit horizontally, and we effectively "zoom out" to accommodate it.

This distinction in layout algorithm, along with the possibility for print/screen-specific style rules (utilized by many websites, as illustrated in previous comment), underscores why "print what I see on the screen" is necessarily a non-goal, as I said in comment 4.

I agree that it would be interesting to create a tool that did that (perhaps a Firefox extension, which could take a bitmap of the current page and render it to a PDF, shrunken horizontally if necessary & sliced into page-sized chunks).  However Firefox's main "print" function is not designed to do that.  (and e.g. the CSS parts in particular are absolutely necessary for standards-compliance)

(In reply to Rob from comment #5)
> My complaint is NOT about Pagination (though I would like Pagination to work
> as I described above).

(Apologies -- we have had a number of bugs where e.g. content disappears or is cropped when it overlaps a page-boundary, and before I knew what missing-content you were talking about, I assumed it was that sort of issue).
(Reporter)

Comment 8

6 years ago
Created attachment 558821 [details]
Two screenshots - the Browser and the "Print Preview" Window

(In reply to Daniel Holbert [:dholbert] from comment #6)
> Just addressing your testcases, to keep this comment reasonably-sized:
> 
> > Examples:
> > 1. This Page - not the best example but the MOST obvious one
> 
> I don't see anything particularly busted on print-preview of this page.  If
> you're referring to the header/footer content, read on.

It is a 'right side chop' (width not calculated properly). It is not a great example of how bad it can be but that URL is particularly convenient.



> > 2. https://bugzilla.mozilla.org/ - The top and bottom are missing, only the
> > middle is previewed.
> 
> Correct.  That's what's supposed to happen, as specified in the page's CSS.
> Quoting https://bugzilla.mozilla.org/skins/standard/global.css:
> > /* Rules specific for printing */
> > @media print {
> >     #header, #footer {
> >         display: none;
> >    }
> 
> So -- the page explicitly asks for that content to be hidden, when rendered
> for printing.

Sneaky, but fair. Accepted.


 
> > 3. http://www.cnn.com/ -- The widest Element in the Menu is not calculated
> > and so the right side of the Page is simply chopped off.
> 
> This actually works correctly for me. (I checked nightly build as well as
> Firefox 6.0.1, on Ubuntu Linux).  The rightmost content that I see on the
> page is at the right side of my print-preview window, un-cropped.  Could be
> OS-specific due to font sizes or something.

I'll make a screenshot of the "Print Preview".

One thing I can say about the "Print Preview" is that it VERY accurately depicts how poorly (or well) the Page will print.


 
> > 4. http://www.google.com/intl/en/about/corporate/index.html -- The images
> > are missing and the Page looks like it was ran through "html2text" before it
> > was printed.
> 
> Correct.  As above -- this is what's supposed to happen per the page's CSS.
> 
> If you view-source and click on "default.css", you'll see this:
> > @media screen, projection {
> >   body {
> >     min-width: 640px;
> [Basically all of the style]

OK. I'll ensure that any further examples are checked for those things.

I'll hunt down a few more examples. 

I think (from the looks of the Page I remember that printed poorly) it looked like 'CSS Boxes' were mispositioned (and visible) and the color was off quite a few shades. Some bit were missing and all-in-all it was really bad -- and it "LOOKED" like it was our fault (but I WILL ensure I am not caught by "@media" monkey biz.


> So -- in 3 out of your 4 examples, we're doing the right thing.  At CNN, I
> don't know what the problem is since I can't reproduce it, but there are a
> number of things that could be going on.  That would be worth tracking in a
> bug. Shall we make this bug about that?

See the composite of two screenshots attached. It show the 'right-chop'.
(In reply to Rob from comment #8)
> > > Examples:
> > > 1. This Page - not the best example but the MOST obvious one
[...]
> It is a 'right side chop' (width not calculated properly).

> > > 3. http://www.cnn.com/ -- The widest Element in the Menu is not calculated
> > > and so the right side of the Page is simply chopped off.
[...]
> See the composite of two screenshots attached. It show the 'right-chop'.

Ok -- so one thing that could be messing with those -- when you open up Print Preview at e.g. this site, there should be a dropdown box labeled "Scale" at the top of the print-preview window.

What value is that box set to?  (It needs be set to "Shrink to Fit" for anti-"chop" behavior -- any other value will have the potential for chopping.)
(Reporter)

Comment 10

6 years ago
Created attachment 558829 [details]
A CuteWriter .PDF of cnn.com from Firefox Nightly
(Reporter)

Comment 11

6 years ago
Created attachment 558833 [details]
A CuteWriter .PDF of cnn.com from Google Chrome

Notice how the "LAYOUT" is "correct". 

The Print does NOT "look better" (since Google Chrome has no "Page Setup" or "Printer Settings" Controls) but even though it is uglier (the Images are not as clear and the Fonts are really bad) the "LAYOUT" is "correct". 

We NEED Google Chrome's "correct layout" with our 'fine Images and Fonts' to FIX _this_ Bug (along with correct pagination - don't chuck that out).
Could you answer Comment 9? (not sure if you saw it)
(Reporter)

Comment 13

6 years ago
(In reply to Daniel Holbert [:dholbert] from comment #7)
> (In reply to Rob from comment #5)
> > How to determine length:
> 
> Right, we do something along the lines of what you describe. 
> ...

> I agree that it would be interesting to create a tool that did that (perhaps
> a Firefox extension, which could take a bitmap of the current page and
> render it to a PDF, shrunken horizontally if necessary & sliced into
> page-sized chunks).  However Firefox's main "print" function is not designed
> to do that.  (and e.g. the CSS parts in particular are absolutely necessary
> for standards-compliance)

If we could abide by "@media" (and any other issues you did not mention) and then take the "intended" (by the Website's Author) print output and print that as the Website's Author intended (whether they are a 'bad Artist' or not), subject to any Bugs or other disagreement in OUR interpretation of HTML (and CSS, etc.), THEN I would be satisfied that this Bug was fixed (thought not as happy as if it were "WYSIWYG-@media").


> (Apologies -- we have had a number of bugs where e.g. content disappears or
> is cropped when it overlaps a page-boundary, and before I knew what
> missing-content you were talking about, I assumed it was that sort of issue).

No problem. It is GREAT to avoid dupes.
(Reporter)

Comment 14

6 years ago
(In reply to Daniel Holbert [:dholbert] from comment #12)
> Could you answer Comment 9? (not sure if you saw it)

STF removes the chop. So does that mean that on a 1200DPI Printer that printing at 100% is pixel for pixel (and the print will be approximately an inch wide), why is it taking a few Pages - should easily fit on one Page.

If I set the Scale to 30% then it is two inches wide on my Screen and fits on 3/4 of a Page -- so 100% on a 1200 DPI Printer would easily fit on one Page (instead of 3).


I'll look for an example Page where things are missing and mis-colored (and it is not explained by the @media tag AND is laid out better in another Browser) I guess I'll use Google Chrome; since you might not use Wine to run Internet Explorer on Linux.
(Reporter)

Comment 15

6 years ago
Arggh. The last Update to Nightly added a new Bug. The "Print Preview" Menu does not [Close] and when you switch Tabs it is still present (on every Tab) (with TM+).

I'll switch to Aurora and find some example Pages without @media (or media="screen") and post some examples in the next few hours.
So -- to prevent this bug from reaching ~20 comments (and ~10 printed pages) before getting to an actual testcase for a "real" bug ;), I'm going to resolve this as INVALID (which is appropriate the specific examples brought up so far (in comment 5) are all non-bugs), and humbly request that you file new bug report(s) for whatever next example(s) you find.

(No offense intended -- it just ends up being impossible to read/maintain bug reports if we allow them to be retargeted from one issue to another to another before settling on something.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
> appropriate the specific examples
(er I meant "appropriate given that the specific examples")
(Reporter)

Comment 18

6 years ago
(In reply to Daniel Holbert [:dholbert] from comment #16)
> So -- to prevent this bug from reaching ~20 comments (and ~10 printed pages)

We wouldn't want that if it would not print properly !  :) !


> before getting to an actual testcase for a "real" bug ;), I'm going to
> resolve this as INVALID (which is appropriate the specific examples brought
> up so far (in comment 5) are all non-bugs), and humbly request that you file
> new bug report(s) for whatever next example(s) you find.
> 
> (No offense intended -- it just ends up being impossible to read/maintain
> bug reports if we allow them to be retargeted from one issue to another to
> another before settling on something.)

After downloading some Pages and modifying them (to fix them), after studying some Pages, and reading various Tutorials about 'producing print-friendly Web Pages' I have come to the conclusion that SOME people are (apparently) trying to get their Pages to print well on dot-matrix printers (for want of a better explanation - but certainly not a simpler one!).

I think that THIS Bug and Bug 521204 would be resolved if people were more skillful with HTML, CSS, @page and @media (etc.). IE: It is NOT "our" Bug.


Thank you for the time you spent on this. So it is naught for waste I'm going to make an RFE for "Permit Screen Media to Print" in the spirit of the [File][Page Setup][Print Background (colors & images)] checkbox here: Bug 685252 .


YT,
Rob
You need to log in before you can comment on or make changes to this bug.