Open Bug 648657 Opened 13 years ago Updated 2 years ago

Firefox UI inadequate to support printing web apps.

Categories

(Core :: Printing: Setup, defect)

x86
macOS
defect

Tracking

()

UNCONFIRMED

People

(Reporter: richard, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Firefox 4.0

It's not possible to write a web app that prints within 3/4 of an inch of the page edge without having the user open about:config and change print.print_margin_xxxx prefs.

Asking web app users to open about:config is wildly dangerous.

Not being able to print within 1/2 inch of the top of the page makes it impossible to create a web app to print business cards on stock pre-perfed card stock.

Reproducible: Always

Steps to Reproduce:
1.Open the demo page at http://netfools.com/bugzamples/cardmaker/index.html
2.Open File>Page Setup and notice that there is no page margin UI.
3.Click the Print Cards button and notice that the output is not centered on the page.
Actual Results:  
The output is split between two pages.

Expected Results:  
The output should be centered so that cards printed on any of the business card stock forms listed in the right hand column are properly centered.
In Aurora 5.0a2, the print.print_margin_xxxx prefs appear to have been removed.  

Sadly, the minimum margin is now 5/8 of an inch.

This is a step backwards.  It is now completely impossible to print a 7 by 10 inch rectangle on an 8-1/2 by 11 inch sheet of paper.
I think it may be that the prefs are still active, but no longer created by default. I'm no expert on how that code works, but the file that appears to use those prefs hasn't changed in years.

In banging around in MXR, I did discover some additional prefs that might help: 

http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#343

I was hoping that setting those to zero will make the print_margin prefs behave predictably, at the expense of the printer clipping if it's not capable of full bleed. I'm unable to test that right now on a real printer, but using the Preview button with the HP LJ4350 driver (OSX 10.6.7) still gives me a 1/2 top and left margin in Aurora.
Ignore Comment 1.   Those prefs seem to appear automagically somewhere in the process of using the printer for the first time.  (but seemingly not triggered by using the Page Setup dialog.
There is now a print alignment target which is better for illustrating this problem at: http://netfools.com/labels/align.html
Took a couple minutes to figure out where these defaults were coming from.

http://mxr.mozilla.org/mozilla-central/source/widget/src/xpwidgets/nsPrintSettingsImpl.cpp#85
The default "0.5" value for print_margin_xxx value is coming from the nsPrintSettings constructor, where margin defaults to DEFAULT_MARGIN_WIDTH, which is 0.5.

http://mxr.mozilla.org/mozilla-central/source/widget/src/xpwidgets/nsPrintOptionsImpl.cpp#245
If the prefs have been changed, they are read out in the nsPrintOptions::ReadPrefs method, here.  If they're not defined, another 0.5 default is applied.

http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsSimplePageSequence.cpp#203
http://mxr.mozilla.org/mozilla-central/source/layout/printing/nsPrintEngine.cpp#2329
These margins are applied either by the nsSimplePageSequence, or the nsPrintEngine.cpp (for Print Selection).  The margin and the unwriteable margin are added together and subtracted from the content.   From a quick reading it doesn't look like the CSS margin property has any ability to change that.

On Cocoa, the relevant bits of logic are:

http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsPrintSettingsX.mm#109
where InitUnwritableMargin reads the paper margins from the current PMPage and saves them to the mUnwriteableMargin variable (whence they will become the print_unwriteable_margin_[xxx] prefs)

http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsPrintDialogX.mm
Most of the Cocoa printing settings are preserved opaquely inside the nsPrintSettingsX object, through a NSPrintInfo*.  The NSPageLayout ("Page Setup") dialog manipulates them (#169), and they are later provided to the NSPrintOperation (#108).  The print_margin_xxx variable doesn't figure.  So, on Cocoa, we deliver appropriately-sized PMPaper margins, and then inset our content into that.

I am unable to find any place where the Windows or Cocoa widgets change the value of the print_margin_xxx preference.  The printPageSetup.js code in toolkit/content/global references the right property of PrintSettings, but I think no platform uses that dialog these days.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.