Created attachment 636616 [details]
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?).
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.
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
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
Regressed by Bug 417178
in local build, I confirmed that Backing Bug 417178 out from tip fixed the problem.
You backed out attachment 311296 [details] [diff] [review] and that fixed the bug?
(In reply to David Baron [:dbaron] from comment #8)
> You backed out attachment 311296 [details] [diff] [review] and that fixed
> the bug?
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]
Comment on attachment 637743 [details] [diff] [review]
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.