Print Error in Firefox 1.5+

[Aoirthoir]

[edited October 8, 2006 in order to place fix at top...]

Note: there are two issues some folks have run into with printing on Firefox that I am aware of at this time.

One, printing does not work at all. For this the fix is at this website:

http://forums.mozillazine.org/viewtopic.php?t=471648&highlight=firefox+printer+error+message

Two, the first and last page will print but nothing in between...For the fix to this you have to look at the websites CSS file. Basically it has to do with a CSS IDENTIFIER having a clear: both setting. Simple change that to clear: none. You can do so with the stylish extension for firefox. There are more complicated fixes, but they require the webmaster of the particular site to change his website. Many will not do so. If anyone needs specific help with this issue I can be reached at boscagarda-programming@yahoo.com

---------End of October 8, 2006 changes..now the original posts and responses follow:



I dont know if anyone else has noticed this situation. Whenever I try to print any Dataface based documents I get the first page printed fine (usually) then the second page is almost always just the footer. No pages in between. This occasionally happens on a few other websites also. But if I use the extension, nuke anything enhanced, it usually does the trick. But not on the DF generated pages. If I set to No Style, it still does the same thing. So I think it is not a CSS issue, but rather a table issue perhaps.

I am running Firefox 1.5.0.7 on XP. It prints fine on IE. Which of course I would like to avoid.


If anyone has the same experience or ideas, please let me know.



Thank you kindly.

[Aoirthoir]

Ok, I am using the following URL for testing since it is actually what I want printouts on anyhow.

http://lamp.weblite.ca/dataface-0.6/docs/index.php?-table=Projects&Name=Dataface&-action=view
In Firefox if I choose the View Menu then Page Style then No Style I get straight HTML output of course. No columns yada yada. This is the kind of thing that would be viewable on even a text based browser.

Then if I go to print preview or print, it resets the page style back to Basic Page Style. This setting is what causes firefox to use the CSS for a page. So I attempted to set No Style in other pages and then run Print and Print Preview. The other pages do not reset in this case. I even tried it on just plain ole pages of the Dataface site. But the problem currently seems to be (somewhat) exclusive to the DF generated pages. I say somewhat, because as I mentioned, I've experienced this issue before. But I never had reason to attempt to document it. And it was usually a one off page that I wanted to run, so I just went over into IE (ugh) to print it. Also, I had not considered the CSS problem at that time, and so did not attempt the No Style solution, thus I cannot state whether those pages would also have reset the style sheet to Basic Style or not.

Next I did a view source, copied the source to my text editor and saved it. It came up in the browser as it would with NO STYLE. Then I did the print preview. This worked fine. I got five pages. Then I downloaded plone.css from the site. Though I expect that it is probably the same plone.css as I have in my DF directories here, I wanted to make 100% sure I was using the same file. Went into the source and rerouted the @import for the plone.css to pick it up from the same dir. Then refreshed....

Ok now it looks like it did on the site. So then I did print preview...same error at this point. I tried removing the reference to styles.css down later in the source, this did not correct the error. I also cleared my cache and set NO STYLE...just in case. Same error. Lastly I turned off Javascript, because I thought, ok maybe javascript is turning the CSS back on. But I got the same error.

A simple fix for me would be for FF to not download the CSS at all. But Ive not been able to find such a setting on the web or in the firefox menus. So now I am off to look for an extension to do it.

Hopefully updates and a work around will follow.

[Aoirthoir]

Googling provided this link:

http://www.computergripes.com/firefox.html

Quoting:

July 19, 2006. Firefox can not print this article in Information Week magazine by Fred Langa. It is a long article, but Print Preview says it will print only two pages and the second page is blank. At first, Print Preview in IE is also wrong (it shows scrollbars), however, IE has an option to print only the selected frame and this works fine.

(here is the link since it doesnt appear up there
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=189400897



Well I was over excited...after testing the VIEW SOURCE I found the page was in a frame. If I viewed just the page in the frame, it printed fine....But I dont think DF does anything in frames.

[Aoirthoir]

Found it. In plone.css there is this block:

Code: Select all

/* Site-wide action menu - font size, contact, index, sitemap etc */
#table_selection_tabs {
    background-color: transparent;
    white-space: nowrap;
    list-style: none;
    height: auto;
    line-height: normal;

    padding: 1px 5em 0 0;
    clear: both;
}


The offender is the clear: both; I tried clear: right; and clear: left; and got the same error. If it is commented out or has clear: none; then FF will print fine. Unfortunately then the tables Menu (which is what this is...) appears at the very top, not attached as it should. So if you use The Stylish Extension ( http://www.userstyles.org/ ) you can put this little bit of code in, and then turn this on when you want to print, and off when you are using your application. Just a rough workaround for now folks...

Code: Select all


@-moz-document
url-prefix(http://yourdatafacewebsite/)
{

#table_selection_tabs { clear: none !important; }

}


This will let you print All of the web page. If you want a cleaner interface you can use this entire snippet:

Code: Select all

@-moz-document
url-prefix(http://yourdatafacewebsite/)
{

* {
float: inherit !important;
border: none !important;
}

#top-section,
#left_column,
#table_tabs,
#contentActionsWrapper,
#details-controller,
.fineprint
{
display: none !important;
}

}


This does several things. The first float prevents objects for forcing others to the right if you enlarge the font greatly. (I often do..to zoom in). The border, eliminates the border in your prints and on screen of course. The last section with the display: none; code, removes everything but the actual content block, your list of records or your form or view. It should work anyhow. Sometimes it doesnt and I designed it so I could print the API docs more cleanly.

Mr. Steve,

I put an issue for this in the Issue Tracker. I guess we could say it is 50% resolved. I do have a work around which I can post there if you want. I didn't know if you wanted workarounds posted to it or just actual solves.

Thank you kindly..now I go print the API DOCS.

Holler.

[shannah]

Thanks for finding the issue and the solution. I wasn't looking forward to digging through the css to find the problem on this one I would say that this is an issue with firefox as that is valid CSS. Hopefully they will fix this in future versions.

-Steve

[Aoirthoir]

I definitely agree. The page on screen renders properly. So it should render exactly on paper as it does on screen. IE renders it fine on Paper. But when I am printing these docs, I like to pull out the headers, menus and so on. I cannot do that in IE. I have to do it in Flock or Firefox (maybe it would work in safari or mozilla...and opera..not sure how the extensions support is in those browsers.)

It wasnt that difficult to find once I decided it just had to be the CSS. With CSS it didnt work, without it did. So I made a back up of plone.css. Then I cut about the bottom half out and pasted to another tab in my editor. Saved plone and reloaded. No error..it printed fine. So I knew it was the bottom half. So I took the top half of that and pasted it back into plone, saved and retested. Basically I followed this method until the error started again. Then I did the reverse...pulling half of the part I just pasted back, out again. Of course you cant do that with programming language code ...but it does work with CSS

[lonesky1]

Ok, I am using the following URL for testing since it is actually what I want printouts on anyhow.

>

http://lamp.weblite.ca/dataface-0.6/docs/index.php?-table=Projects&Name=Dataface&-action=view

>In Firefox if I choose the View Menu then Page Style then No Style I get straight HTML output of course. No columns yada yada. This is the kind of thing that would be viewable on even a text based browser.



>Then if I go to print preview or print, it resets the page style back to Basic Page Style. This setting is what causes firefox to use the CSS for a page. So I attempted to set No Style in other pages and then run Print and Print Preview. The other pages do not reset in this case. I even tried it on just plain ole pages of the Dataface site. But the problem currently seems to be (somewhat) exclusive to the DF generated pages. I say somewhat, because as I mentioned, I've experienced this issue before. But I never had reason to attempt to document it. And it was usually a one off page that I wanted to run, so I just went over into IE (ugh) to print it. Also, I had not considered the CSS problem at that time, and so did not attempt the No Style solution, thus I cannot state whether those pages would also have reset the style sheet to Basic Style or not.



>Next I did a view source, copied the source to my text editor and saved it. It came up in the browser as it would with NO STYLE. Then I did the print preview. This worked fine. I got five pages. Then I downloaded plone.css from the site. Though I expect that it is probably the same plone.css as I have in my DF directories here, I wanted to make 100% sure I was using the same file. Went into the source and rerouted the @import for the plone.css to pick it up from the same dir. Then refreshed....



>Ok now it looks like it did on the site. So then I did print preview...same error at this point. I tried removing the reference to styles.css down later in the source, this did not correct the error. I also cleared my cache and set NO STYLE...just in case. Same error. Lastly I turned off Javascript, because I thought, ok maybe javascript is turning the CSS back on. But I got the same error.



>A simple fix for me would be for FF to not download the CSS at all. But Ive not been able to find such a setting on the web or in the firefox menus. So now I am off to look for an extension to do it.



>Hopefully updates and a work around will follow.

[lonesky1]

Hello everybody, I apologise for "dropping in" like that, but I found this Forum when I did a Google search to desperately find a solution to my printing problem in Firefox 1.5.0.7. I've had this problem with FF (its inability to allow printing on a website) ever since I started using FF about 3 weeks ago. [I really like FF because of its speed; so, I would like to resolve this issue so I could continue to use FF instead of going back to IE!].

OK guys, I'm not too technical here, & I couldn't understand most of the stuff written about (presumably the solution(s) to the problem) this problem [my Google search words: printing error in Firefox] here.

I'm just a battler desperately trying to get on top of this seemingly simple problem. Would anyone be kind enough to e-mail me (lonesky1@bigpond.net.au) & give me the simple step-by-step solution to solving this problem?

[When I try to print, the error message says I have to "put a face on the Dataface...." (it didn't complete the sentence)]. The "techno" talk & jargon are beyond me, and I would just like to know what steps to take to resolve this absolute, real headache!].

Thanxx everybody!

Lone

[shannah]

Correct me if I'm wrong, but I don't think we really solved this problem. We identified it but did not solve it.

The problem was that firefox seems to have difficulty with the

Code: Select all

clear: both;


CSS declaration.. this is a common and helpful declaration... removing it seemed to get it going (correct me if i'm wrong), however this change has to be made on the website side, not the browser side....

A real pain..

-Steve

[shannah]

(Note I did not email this response to LONE -- Joseph, since this was your adventure, perhaps you can offer him some more accurate and helpful advice).

Thanks

Steve

[Aoirthoir]

Mr. Steve,

I will email him. You are correct, we did not come with a Firefox solve. I did create a print css file that would manage it for Dataface Based websites, so that when printing, we just strip out the headers, sidebars etc, and only print the data, either the view data or the list data.

Thanks for bringing this up.

[Aoirthoir]

I emailed and he had already found the fix for his trouble. However his was different than ours. He was not able to print at all. But for those who have this trouble the link to his fix is here..

http://forums.mozillazine.org/viewtopic.php?t=471648&highlight=firefox+printer+error+message

As to our error...what happens on some sites is that Firefox does not print all pages. It has trouble with some CSS, though not trouble displaying the CSS to the screen. In our case the problem was as you mentioned..and thus the solution was to remove that. I use stylish to override any CSS settings I dont like.

Regards

[mstolove]

Thanks for finding the issue and the solution. I wasn't looking forward to digging through the css to find the problem on this one " title="Smile" /> I would say that this is an issue with firefox as that is valid CSS. Hopefully they will fix this in future versions.

>

-Steve

This may help: media specific styles. E.g.:

There is one other way to apply media-specific styles: the @media rule. Here's an example:

@media print {
   BODY {font-size: 10pt; line-height: 120%; background: white;}
}
@media screen {
   BODY {font-size: medium; line-height: 1em; background: silver;}
}

[mstolove]

Oops, the style tags were lost in the posting. No mind, here's the URL for the relevent article.

http://meyerweb.com/eric/articles/webrev/200001.html

Mike

[Aoirthoir]

Thanks for the suggestion Mike. We posted a similar solution here:

http://framework.weblite.ca/development/issue-tracker/119