Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

"Print page" doesn't work as intended when using lengthy tables. (Brother MFC 6490CW, possibly others)

more options

I had originally thought this was a printing driver problem, but further testing indicated that this was not a problem in Internet Explorer and it was a problem in Firefox.

When printing some web pages using Mozilla Firefox, particularly those having sizable tables which would extend beyond the length of a single printed page, the remainder of the table is not printed even though the remainder of the web page itself is printed. The behavior is also noted when using Print Preview. See, for example, this web page which I created: http://alltherightwaystowrite.blogspot.com/2013/08/the-basics-capitalization.html

I inquired of other bloggers to see if they were also experiencing this issue. See, for example, the discussion I began here: https://productforums.google.com/forum/#!msg/blogger/EpD6K2ezIZE/a5mPu8CV0HwJ

As you can see, the only response I received indicated it was not an issue for that person with a different printer. This leads me to believe the problem is with either the MFC6490CW printer (unlikely) or the MFC6490CW printer driver (more likely) or perhaps with Firefox, or some combination of those three. This problem is duplicatable by me on successive attempts to print with any web page with a table extending beyond the length of a single page of printed paper. The output error occurs whether printing in portrait or landscape mode.

Saving a web page as "Web Page Complete" and opening up the web page in Microsoft Word created a variety of formatting errors, but otherwise, the entire contents of the page would have printed. Of course, this is not an ideal solution in any event. The entire document should print seamlessly across multiple pages without losing any data or content in the process.

As indicated above, as an additional test, I attempted to print the same web page in Internet Explorer and did not note the output errors described here. The web page printed correctly under those conditions. As a result, I believe that the most likely culprit is Firefox since Internet Explorer was also a good test case for my printer and printer driver, and it passed that test case.

I had originally thought this was a printing driver problem, but further testing indicated that this was not a problem in Internet Explorer and it was a problem in Firefox. When printing some web pages using Mozilla Firefox, particularly those having sizable tables which would extend beyond the length of a single printed page, the remainder of the table is not printed even though the remainder of the web page itself is printed. The behavior is also noted when using Print Preview. See, for example, this web page which I created: http://alltherightwaystowrite.blogspot.com/2013/08/the-basics-capitalization.html I inquired of other bloggers to see if they were also experiencing this issue. See, for example, the discussion I began here: https://productforums.google.com/forum/#!msg/blogger/EpD6K2ezIZE/a5mPu8CV0HwJ As you can see, the only response I received indicated it was not an issue for that person with a different printer. This leads me to believe the problem is with either the MFC6490CW printer (unlikely) or the MFC6490CW printer driver (more likely) or perhaps with Firefox, or some combination of those three. This problem is duplicatable by me on successive attempts to print with any web page with a table extending beyond the length of a single page of printed paper. The output error occurs whether printing in portrait or landscape mode. Saving a web page as "Web Page Complete" and opening up the web page in Microsoft Word created a variety of formatting errors, but otherwise, the entire contents of the page would have printed. Of course, this is not an ideal solution in any event. The entire document should print seamlessly across multiple pages without losing any data or content in the process. As indicated above, as an additional test, I attempted to print the same web page in Internet Explorer and did not note the output errors described here. The web page printed correctly under those conditions. As a result, I believe that the most likely culprit is Firefox since Internet Explorer was also a good test case for my printer and printer driver, and it passed that test case.

Chosen solution

Hi glennalperin, I think that's a different bug. It refers to a case when your style rules override the default display property of a table (display:table) with an instruction to use inline layout (display:inline).

In your page, the problem is how Firefox renders tables inside a floated division. If you override this rule:

.column-center-outer {float:left}

Then the table prints in full. You can test that by viewing your page, opening the web console (Ctrl+Shift+k), pasting the following script next to the caret (">"), then pressing Enter and checking Print Preview.

var s=document.createElement("style"); s.type="text/css"; s.appendChild(document.createTextNode('@media print {.column-center-outer{float:none;}}')); document.body.appendChild(s);

If applied to the screen display, this would wreck the 3-column layout, so it is applied only to print output using the @media rule. There is much more you could do with a print style sheet if you want your visitors to have nice printouts, and that probably would improve their printed results in other browsers as well... for example, this script undoes some of the other style rules to create a more usable printout:

var s=document.createElement("style"); s.type="text/css"; s.appendChild(document.createTextNode('@media print {.column-center-outer{float:none;} div{position:static !important; width:auto !important; margin:auto 0 !important; padding:0 !important; min-width:100% !important;} table{width:auto !important;} body, div, h1, h2, h3, p, th, td, a{color: #000 !important; background-color:#fff !important} body{min-width:640px !important;} .body-fauxcolumns, .main-cap-top, .column-right-outer{display:none !important;}}')); document.body.appendChild(s);

You might check whether your theme already has a print style sheet that you're not using, since that would be the most maintainable approach.

Read this answer in context 👍 1

All Replies (8)

more options

Sorry, I don't see a problem with Print Preview on that blogspot page using Firefox 23 on WinXP with a Brother MFC-J615W printer, which is a few years newer than the MFC6490CW model. That table is split roughly in half on each page, and two pages appear complete.

About the only thing I can think of to recommend is to do a "printer reset" in Firefox, and see if that helps.

http://kb.mozillazine.org/Problems_printing_web_pages#Reset_printer

more options

I use the NoScript extension. When I visited your page with scripts disabled and checked Print Preview, everything would have printed. However, after enabling scripts, the part of the table that did not fit on page 1 was dropped. Hmmm... what changed?

Well, I can't figure out it.

I do think it might be a good idea to investigate adding a print-targeted style sheet. You may have noticed this on some other blog sites, that they print black on white with a simpler layout (omitting navigation, for example).

more options

Unfortunately, a printer reset did not seem to help., Thanks for that idea though.

more options

jscher2000, thanks for that observation regarding the effect of enabled scripts possibly having an effect on the printing of my page, something I would not have thought of. If this is indeed the case, this would seem like a bug in Firefox. Perhaps it is time to file a bug report given the information you provided here. I think I will do that.

more options

Apparently, this is documented as a bug already. https://bugzilla.mozilla.org/show_bug.cgi?id=869440

more options

https://bugzilla.mozilla.org/show_bug.cgi?id=521204 - this is a META Bug which is tracking all the Bugs which are related to Wrong page splitting / Missing page content when printing - 34 different Bugs, 14 of which are marked as solved.

IMO, that page would be better served with a print css script (as jscher2000 mentioned earlier) to make that a "printer ready" page, if wanting that page to be "printable" is your intention. As it now is that page is shrunk by about 50% with the "Shrink to Fit" feature engaged. Look at that page in Print Preview when the Scale is set to 100% instead of Shrink to Fit, and see that the page is so large that it shows that about 1/2 the width. Then decrease the zoom level in Print Preview to 50 or 60% to get that page to fit horizontally with the "Shrink to Fit" feature disabled. Looks like a case of "garbage in - garbage out".

I think the css used for that page uses too large a font which (IMO) forces Firefox to shrink the font too much to make that page fit to a letter size sheet of paper. And relying first upon the Print to Fit feature in the four different major browser engines (Gecko, Trident, WebKit, and Presto) and then the hundreds of print drivers out there is just looking for failures such as you are seeing; it works for some viewers and doesn't work for other viewers. What appears on the "screen" doesn't always translate to the "printed page" too well without proper instructions via style sheets, especially since "screens" are oriented horizontally and most "printed" pages are vertically oriented unless the user shifts to the Portrait view.


http://www.w3.org/TR/CSS2/media.html#media-types
http://www.w3.org/TR/CSS2/page.html

more options

Chosen Solution

Hi glennalperin, I think that's a different bug. It refers to a case when your style rules override the default display property of a table (display:table) with an instruction to use inline layout (display:inline).

In your page, the problem is how Firefox renders tables inside a floated division. If you override this rule:

.column-center-outer {float:left}

Then the table prints in full. You can test that by viewing your page, opening the web console (Ctrl+Shift+k), pasting the following script next to the caret (">"), then pressing Enter and checking Print Preview.

var s=document.createElement("style"); s.type="text/css"; s.appendChild(document.createTextNode('@media print {.column-center-outer{float:none;}}')); document.body.appendChild(s);

If applied to the screen display, this would wreck the 3-column layout, so it is applied only to print output using the @media rule. There is much more you could do with a print style sheet if you want your visitors to have nice printouts, and that probably would improve their printed results in other browsers as well... for example, this script undoes some of the other style rules to create a more usable printout:

var s=document.createElement("style"); s.type="text/css"; s.appendChild(document.createTextNode('@media print {.column-center-outer{float:none;} div{position:static !important; width:auto !important; margin:auto 0 !important; padding:0 !important; min-width:100% !important;} table{width:auto !important;} body, div, h1, h2, h3, p, th, td, a{color: #000 !important; background-color:#fff !important} body{min-width:640px !important;} .body-fauxcolumns, .main-cap-top, .column-right-outer{display:none !important;}}')); document.body.appendChild(s);

You might check whether your theme already has a print style sheet that you're not using, since that would be the most maintainable approach.

more options

Thanks, jscher2000. That was extraordinarily helpful, and, indeed, that did solve the printing problems I was experiencing. It is really important to me, as a designer and web author, that my viewers should not have to do anything extra to get a usable printout of my material. I've always been rather annoyed at the idea of writing web code that will only show up correctly in one particular browser. I have modified my new blog entry template to include that javascript at the top of all new posts of mine.

My theme does not appear to have a print style sheet built into it already, so I think that my solution to add the code to the top of my new blog entries is probably the most maintainable one, at least at this time. Thanks a bunch for your help!

Glenn