User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 The print function of Firefox 4.0 has sometimes a strange behavior. (I am in fact always printing to PDF files, using currently PDFCreator 1.2, latest.) It works quite well on most pages I have seen, but not very well on a very simple, valid XHTML test page... I have checked with Opera 11.0, latest, and it works perfectly, therefore the problem comes most probably from Firefox 4.0. Reproducible: Always Steps to Reproduce: 1. Go to http://www.davidbourguignon.net/texts/critique-du-film-home-de-yann-arthus-bertrand.html 2. Click on the menu File > Print > Print to PDF (when PDFCreator 1.2 is installed as PDF printer) 3. Look at the resulting PDF : page 1 is roughly OK, page 2 and over are completely wrong... 4. Compare the output of the print to PDF manœuver on Opera 11: it works perfectly. Actual Results: Wrong PDF output. (See file pdfcreator1.2-firefox4.pdf in attachment.) Expected Results: Correct PDF output. (See file pdfcreator1.2-opera11.pdf in attachment.) It seems that similar bugs have been reported in the past... (See bug 384841 for example.) I will try to attach the mentioned PDFs for clarity of the demonstration.

Does the page appear correctly in print preview?

Thanks Tim for your quick reply. Nope, I just checked: the page looks exactly the same in the print preview as in the PDF...

The same issue occurs in 3.6 Changing the following css rule: div.texts-body { font-family: "Trebuchet MS",Helvetica,sans-serif; margin-left: 20%; margin-right: 20%; margin-top: 300px; position: absolute; to div.texts-body { font-family: "Trebuchet MS",Helvetica,sans-serif; margin-top: 300px; position: absolute; resolves the issue.

Alright Tim, but this is no longer my original layout! :-) The CSS I'm using is fully valid according to W3C validator. Yes, the issue was also there in Firefox 3.6. It's part of the lingering printing problems that have never been addressed apparently. (There are many bug reports about that, I mentioned bug 384841 for example.) Does this mean that Mozilla does not intend to implement fully the CSS specifications for printing HTML pages from Firefox? Thanks in advance for your help!

(In reply to comment #6) > Alright Tim, but this is no longer my original layout! :-) > The CSS I'm using is fully valid according to W3C validator. [etc] I don't think Tim was suggesting "Change your site to this and the problem will be fixed." I think he was just offering some insight into what's going on, for the purpose of helping to get to the root of the problem in Firefox. > Does this mean that Mozilla does not intend to implement fully the CSS > specifications for printing HTML pages from Firefox? Hopefully the above addresses this loaded question, too. :)

Thanks Daniel for the explanation. I should have been more careful in replying to Tim's answer... Sorry for this mishap. Thanks in advance for your help guys!

Still an issue on Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110903 Firefox/9.0a1 ID:20110903030832

(clarifying bug summary) I believe I've seen another similar open bug, but I don't know the bug number offhand. Flagging as possible-duplicate.

Seems to me the affected cases (this bug, and bug 1033149) are all related to overflow containers. And I'm guessing the bug is here: https://dxr.mozilla.org/mozilla-central/rev/b5a3b8ef6902998507fc881b6d628b055457fe31/layout/generic/nsContainerFrame.cpp#1171 nsSize containerSize = aReflowInput.AvailableSize(wm).GetPhysicalSize(wm); LogicalRect prevRect = prevInFlow->GetLogicalRect(wm, containerSize); // Initialize reflow params LogicalSize availSpace(wm, prevRect.ISize(wm), aReflowInput.AvailableSize(wm).BSize(wm)); Afaict, we're passing in the frame's intended width as its available space; which works only if there's no margin. If there's a margin, it'll accumulate page by page exactly as we're seeing here. (What's *intended* to happen is that the frame gets the same width calculation as its prev-in-flow. I'm not 100% sure what would be the correct way to make that happen for all layout types, but this method obviously isn't it.)