Many web browsers not print the headers and footers.

Please always include build ID in bug-reports.

You can change this manually in the page setup dialog....

As far as that goes, though, we currently default to assuming the printable
region goes to within 0.04in of the page edge. This is insane. We should
change that default to 0.25in and then people will not run into this issue
except in the rarest of cases. This would be a trivial change if we just decide
to do it instead of saying that this bug is "fixed" because the user can look
for an obscure dialog, look at the second(!) sheet in it and try to guess some
numbers that will make his page print ok.

I agree with Boris..I'm also seeing the problem..

Created attachment 73723
patch

Until now nobody has told me what a reasonable value would be

Comment on attachment 73723
patch

Oh. Doh. :)

r=bzbarsky

nsbeta1+

Xprint API already returns the printable region and our Xprint module adjust the
page size and X,Y-offsets based on that information. What can we do in this case
(e.g. "correct behaviour") ?
Can we set the margin defaults per print module somehow ?

Just verified. Xprint sets the left/top edge to x=75, y=75 for 300 DPI printer
(e.g. 75/300=0.25). We need a way to adjust the margins per print module and/or
platform...

I suggest to fix the issue in the single print modules. They know about the
paper size, therefore they should know about the printable area (like Xprint),
too.

I would prefer to get the current patch checked in and file a new bug to query
the print module for the default margin settings. We need to go after some other
high priority bugs right now.

Comment on attachment 73723
patch

<email address hidden>

Comment on attachment 73723
patch

This patch completely screws-up printing with the Xprint module - the margins
are very very thick and the layout engine seems to have problems with tables
when there is not enougth room.

Can I overtake this bug, please ?
The fix may be very easy to solve by porting some minor functionality from the
Xprint-land to Mozilla's PostScript module without breaking existing
functionality...

Yes, please take it.

adt2 per adt triage

Taking...

I am going to use the same way as Xprint handles the issue. Xprint does not use
the paper width/height, it uses the printable region for it's paper size records
(e.g. left/top edge and width/height of printable area) ...

Comment on attachment 73723
patch

Death to this nightmare!

Moved the new fix for this bug into the patch for bug 132563 ("Print job options
dialog should use paper name instead of paper size to set/get the selected paper
size") - this one has to modify the page size stuff within PostScript module -
and the patch in bug 132563 touches the same code.

Created attachment 75728
PostScript output from PostScript module created with 2002-03-18-08-trunk and attachment 75725 from bug 132563

Reporter:
Does the attached output print "OK" for you (size is "Letter") ?

Patch for bug 132563 has been checked-in, marking bug as FIXED.

footers are printing, but headers are cutoff as seen on linux commercial build
2002-03-26-06-trunk

Tracy Walker wrote:
> footers are printing, but headers are cutoff as seen on linux commercial build
> 2002-03-26-06-trunk

What do you mean with "cutoff" ? Which paper size did you use (DIN-A4, Letter,
... ?)
Can you print it on a PostScript printer (e.g. no GhostScript), scan the
printout and attach it as an image (no JPEG, please - non-lossy formats like
GIF/PNG preferred if possible), please ?

ummm...no, sorry, I can't do that.

by cutoff, I mean that nearly all the type is not printed. the foot of "p"s are
there. as in "http://home.netscape.com" for the upper right header in the
printout; the only thing visible on the printout is the flat part of the bottom
of each of the p's. two tiny little dashes about an inch apart. For the upper
left header "Netscape.com" just one little dash printed from the bottom of the
"p"

same printer, same paper size selected as when printed out from windows builds.
(which prints the headers fine)

Boris, does the header and footer print out for you?

I need somehow a prinout where I can do measurements - sdtimage in Solaris 7
shows the page perfectly...

Tracy Walker:
Does attachment 75728 print correctly for you or does it print "broken", too ?

I can't test this till mid-April (after April 10, at least). Till then, I have
no printer (and no Linux, even).

marking fixed....this worksforme...

Tracy, please try again in 3/27 smoke builds...

verified in 3/26 build...I get header and footer for all 3 platforms.
especially linux.

The default printing margin seems to have changed back to .04 on Linux
(Linux/20030109) This should really be .25 by default--you shouldn't have to
set this manually!

ADT: Nominating topembed

Roland, are you going to fix this? Is fixing the default margin the right fix
and are there any side effects to doing so?

topembed- assuming this is linux only

*** Bug 155934 has been marked as a duplicate of this bug. ***

I've had this isolated as a gs bug for some time, and probably should have
reported this earlier. Somewhere in the gs setup, the PageOffset gets skewed
for various printers. Addenda to gs_init.ps of the general form of:

<<
       /ljet3 <<
               /PageOffset [0 0]
               /Margins [0 0]
               /.HWMargins [0 0 0 0]
       >>
       /ijs <<
               /PageOffset [0 -12.2]
               /Margins [0 0]
               /.HWMargins [0 0 0 0]
       >>
>> currentpagedevice /OutputDevice get
.knownget { setpagedevice } if

solve the problem, very nicely for the ljet3, and only marginally for my HP
1120C (ijs) since in the latter case the entire printable area needs to be
shifted down the page and setting Margins and HWMargins in various places
doesn't seem to solve this.

Maybe this bug needs to go elsewhere, like to the ghostscript people. It's a
very longstanding bug (several years!) and I've come on fixes for it posted to
the geocrawler archives from the late 90s.

As a company pushing OS software, we try to push Firefox as the browser of
choice. We wrote some web based medical software but are having difficulty with
the print margins.
In order for the forms to come out right, the margins have to all be set = to 0.
All of the headers and footers to --blank--

Reproducing the error...
Open the browser and click into a report, click file->print the output is messed
up. Overlapping the page, and headers and footers get printed.
Click file->page setup even though the margins are already at 0 and headers and
footers are already blank, you have to press ok.
Now click file->print and it prints fine.

The bug: Mozilla disregards or ignors page setup settings when printing until
file->pagesetup->ok are clicked ever time a the browser opens. Even if it is a
new or child window, you have to click file->page setup->ok just to enforce the
margins and headers and footers.

This is driving us, our clients and me nuts. Any thoughts?

https://bugzilla.mozilla.org/show_bug.cgi?id=130075
Quote:
Maybe this bug needs to go elsewhere, like to the ghostscript people. It's a
very longstanding bug (several years!) and I've come on fixes for it posted to
the geocrawler archives from the late 90s.

https://bugzilla.mozilla.org/show_bug.cgi?id=212369

Is anybody going to fix this bug? Printing is a big thing, and it is a very old bug!

It looks at this point like there's some confusion in Firefox, probably in other
gekko-based browsers, with regard to where and to which printers page settings
apply. It's not obvious that the page settings are actually per-printer, and
stored as such in prefs.js, even though there's a set of "global" settings which
aren't per-printer but seem to have no effect. These are probably defaults for
newly discovered printers.

You can see this by going to file-print, selecting a printer, and then
cancelling the print operation, then going to page setup and checking the page
settings. Change the settings, go back to file->print, select another printer
and cancel. Then go back to page settings and your previous settings have been
"forgotten". Actually, they're associated with the first printer you selected,
and stored in prefs.js (accessable through 'about:config') with a spec for the
printer.

The quick fix is to either edit prefs.js or use about:config to do the same,
keeping in mind that some settings don't seem to show up there until they've
been changed for each particular printer.

Filter on margin (you can do the same for header and footer). You'll see lines
in about:config like

print.printer_PostScript/some_printer_name.print_margin_top

same for print_margin_bottom, print_margin_left and print_margin_right.

Once you edit the proper entries, they should 'stick' between invocations of the
browser.

The larger fix seems to be that the page setup UI is going to have to be
redesigned - proper labeling, moving the config UI or whatever - so as to
clearly associate a particular page setup with a particular printer. Either
that, or the page setup is going to have to be generalized so that there's a
single master setup not linked with any particular printer, as implied by the
present UI layout.

The above issue is compounded by the fact that every time you bring up the
file->print dialog, the _first_ printer in the drop down list of printers is
selected, not the one that was previously selected the last time one printed. I
can definitely see where Josh's problem is coming from.

Could we file bugs on those UI issues and mark them as blocking this one?

(In reply to comment #39)
> Could we file bugs on those UI issues and mark them as blocking this one?

Is this the appropriate bug system on which to file a Firefox bug?

I am interested in enterprise deployments of thousands of users with hundreds of printers on multi-user Linux systems. Our group has about 30 users and 10 printers. And I want to make it easier for larger organizations to follow in these footsteps.

I maintain that no user should have to customize this setting when all Firefox needs can be obtained from CUPS.

I could live with a system wide firefox preference setting change something like "Use CUPS values for margins?". I apologize for not being vocal on this issue for such a long time. It was wrong of me to not speak up years earlier.

Joseph, printing is basically unowned and has been for years. The only way things get fixed in it is if someone steps up and fixes them.

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/29622/comments/8

Till Kamppeter writes:

This is a problem of the browsers, as they can find out about the unprintable margins of the printer by means of the CUPS API. The CUPS API gives access to the complete content of the PPD file and the PPD contains the margin info. So this bug has to be assigned to both the printing part of the Gecko engine and the printing part of Konqueror.

The bug is not in CUPS, CUPS has everything to tell the apps how big the unprintable margins of each configured printer are.

It seems that bug 284925, bug 347518 and bug 415171 are related.

More specifically, fixing the general bug 284925 would also solve this particular bug. So I'm adding dependency on 284925.

*** Bug 407413 has been marked as a duplicate of this bug. ***

Would be nice get this 6 years old bug fixed for firefox3/seamonkey2 if possible

Thanks :-)

Re: to Comment #51:

To be precise, one can get the PPD file by using the cupsGetPPD() function:
http://www.cups.org/documentation.php/api-cups.html#cupsGetPPD

And the needed info can be extracted from this PPD using proper PPD-related functions:
http://www.cups.org/documentation.php/api-ppd.html#ppdPageSize

If I understand this correctly, one will receive a struct that describes (among others) the printable area:

struct ppd_size_s
{
  float bottom; // Bottom printable margin in points
  float left; // Left printable margin in points
  float length; // Length of media in points
  int marked;
  char name[PPD_MAX_NAME];
  float right; // Right printable margin in points
  float top; // Top printable margin in points
  float width; // Width of media in points
};

There are lots of working examples of the usage of those functions in open source software:
http://www.google.com/codesearch?q=ppdPageSize+cupsGetPPD

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.3) Gecko/2008092515 Ubuntu/8.10 (intrepid) Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.3) Gecko/2008092515 Ubuntu/8.10 (intrepid) Firefox/3.0.1

HP LaserJets (to the best of my knowledge, all models going back to introduction c:a 1986 of the technology) have an imageable area of 8.0 x 10.0 in. (203.2 x 254.0mm).

CUPS defines the imageable area of HP LaserJet using these figures, with lower-left corner of area at 0.x25 x 0.5 in. (6.4 x 12.7mm) from lower-left edge of paper and upper-right corner at 8.25 x 100.5 in. (209.6x266.7mm).

The printed output of a Firefox page is shifted 1/8 in. (~3mm) to the right of the imageable area as outlined on the CUPS Printer Test Page. As a result, the right-most 1 1/2 letters of the header and footer are lost.

Also, the headers and footers both print outside the imageable area as printed on the CUPS Test Page. Nominally, these lines should therefore not print. On my particular HP (an ancient LJ 4L), they did show, but as this is out-of-spec, positive results cannot be guaranteed.

Reproducible: Always

Steps to Reproduce:
1. From CUPS admin page (http://localhost:631), print a test page
2. in |File |Page Setup, select the predefined paper type US Letter HP LJ and click "Apply". Print a page from Firefox.
3. Hold the two pages together and up to a light and note the placement of the Firefox header and footer with respect to the border of the CUPS Test Page which defines the nominal outer limits of the imageable area of the printer.
Actual Results:
1. Header and footer are both outside the border of the CUPS Test Page.
2. Entire header and footer lines are offset 1/8 in. to the right of the border of the CUPS Test Page.

Expected Results:
1. Header and footer both within the border of the CUPS Test Page.
2, First character of the header and footer aligned with the left border of the CUPS Test Page.

Kubuntu Intrepid Ibex beta, dist-upgraded at least 2x daily while the distro remains in development.
Firefox 3.0.3 (pace the build identifier)
CUPS 1.3.8-11ubuntu2

Even in Windows where there is a facility to set margins using File->Page Setup you can only set the page margins. Not the header and footer margins. I have also looked at prefs. on both systems. The options there are

print_margin_bottom
print_margin_left
print_margin_right
print_margin_top

These settings are page margins and can be varied to suit individual printers. That begs the question, why are these settings easily available via the GUI File->Page Setup in Windows as well as via about.config and only in about.config in Linux/Mac? In neither case there are no settings available to vary the size of the headers and footers.

gtk+ 2.20 and later provides a function for getting the printable area of the page:

http://library.gnome.org/devel/gtk/stable/GtkPrinter.html#gtk-printer-get-hard-margins

This bug is of the same era as https://bugzilla.mozilla.org/show_bug.cgi?id=256095

This bug is 14 years old. As I recall, this margin depends on the print.print_margin_* settings which can be set from about:config in Firefox. I long ago fixed this problem in my local copies of Firefox, but it may be that the default settings from Mozilla still aren't proper. I have all these four settings at 0.5 and have no problem anymore with printing margins. They're marked as "user set" in my Firefoxes so I'm not sure what the default settings are or were.

I have these problems.
I was going to put in a bug report (found this one) "not using 0.5 print margins, multipage large table overwriting print headers and footers".
it's set with fit-to-page.

and btw, the page prints to 0.25" margins unfortunately despite 0.5 setting in file, page setup.

The bug assignee didn't login in Bugzilla in the last 7 months.
:jwatt, could you have a look please?
For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#assignee_no_login.py).

(In reply to Keith Briscoe from comment #0)
> Either we need to somehow detect the printable area for the print
> driver, modify the layout a bit

We do this now (we encode it as `unwriteableMargin`)

There are still edge-cases/special-circumstances where we get this wrong (e.g. bug 1763246) but in general this is a non-issue these days.