Created attachment 636616 [details] FF_Print_Bug.png User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0 Build ID: 20120619191901 Steps to reproduce: I observed this in FF13 and 14Beta. I think it was fine with FF12 and FF11. Definitively ok on FF10. All German versions on Windows 7 I have a very large business report which I usually print at the end of the month. Due to its size I have to scale it down. I use "Seite einrichten" (setup page?) and hit the checkbox for "Auf Seitengröße verkleinern" (scale down to page size?). Actual results: The print preview looks fine, but when I print it, it is empty. See attached file. I then tried to set the scaling manually. It works fine until 25%. To print everything I need to go down to 23%. Workaround: Use different paper size, so I do not have to scale down that much. I was using A4 format, now using A3. But at the end of the year, the print wont even fit on A3 with 25% scaling. Expected results: Printout should match print preview.
Is it possible to attach a test report (a blank one with fake data) so we can test too?
Created attachment 637089 [details] test file to reproduce described behaviour In this attached file you can reproduce the effect. I hope this helps you out.
In the menu 'Print preview', do you choose 'portrait' or 'landscape' as paper orientation?
Indeed, I tried to print the attached page with settings 'Shrink to Fit' and 'Landscape' and the Document Writer XPS file was empty (I didn't try with a real printer) even if the print preview showed the entire page. I think it's a regression, due to: Florian Maier — Bug 680436. Don't clamp shrink-to-fit values. r=roc m-c good=2012-02-05 bad=2012-02-06 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ccbb41b873cd&tochange=814d0b2dbaba The fact is before patch from Bug 680436 landed, Shrink-to-Fit was broken (right side was missing) but Firefox was able to print exactly the print preview. Now, it fits good but the print output is empty.
I tried to reproduce with custom scale 20% with "Microsoft XPS Document Writer" on WindowsXP Sp3 Regression window Good: 24-Mar-2008 0714 Bad: 25-Mar-2008 0736 Bonsai log: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-24+00%3A00%3A00&maxdate=2008-03-25+04%3A00%3A00&cvsroot=%2Fcvsroot Regressed by Bug 417178
in local build, I confirmed that Backing Bug 417178 out from tip fixed the problem.
(In reply to David Baron [:dbaron] from comment #8) > You backed out attachment 311296 [details] [diff] [review] and that fixed > the bug? Yes.
5 years ago
A call to ExtCreatePen fails when we try to stroke a very thin line, because the line width gets rounded down to 0 (ExtCreatePen only takes integer widths in GDI logical units). That failure puts the surface into an error state so nothing more gets rendered. I guess this regressed because bug 417178 allowed us to choose narrower border widths, but really the bug was there in cairo all along.
Created attachment 637743 [details] [diff] [review] fix
Comment on attachment 637743 [details] [diff] [review] fix A reftest would be nice.
We don't have a harness that does actual printing :-(.
Is it possible to backport the patch in Aurora and maybe Beta or too risky (about potential printing glitches/issues)?
Given this has been broken for over four years, I don't see a good reason to bring the fix forward an extra 6 or 12 weeks.