Open Bug 130075 Opened 21 years ago Updated 1 month ago

[ps] Page headers and footers outside printable region on almost all default printer setups


(Core :: Printing: Output, defect)

Not set





(Reporter: kbriscoe, Unassigned, NeedInfo)


(Depends on 1 open bug)


(Keywords: topembed-, Whiteboard: [adt2])


(1 file, 1 obsolete file)

This has GOT to be a dupe, but I can't find it.  Better safe than

Page headers and footers look fine in print preview, but are not
printed on my Epson Stylus Color 600 (standard inkjet) because they
are outside the printable area.

Either we need to somehow detect the printable area for the print
driver, modify the layout a bit, or allow the user to so this
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.
Ever confirmed: true
Summary: Page headers and footers outside printable region → Page headers and footers outside printable region on almost all default printer setups
I agree with Boris..I'm also seeing the problem..
Attached patch patch (obsolete) — Splinter Review
Until now nobody has told me what a reasonable value would be
Keywords: nsbeta1
Summary: Page headers and footers outside printable region on almost all default printer setups → [FIX]Page headers and footers outside printable region on almost all default printer setups
Target Milestone: --- → mozilla1.0
Comment on attachment 73723 [details] [diff] [review]

Oh.  Doh.  :)

Attachment #73723 - Flags: review+
Keywords: nsbeta1nsbeta1+
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 ?
Attachment #73723 - Flags: needs-work+
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
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),
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 [details] [diff] [review]
Attachment #73723 - Flags: superreview+
Keywords: review
Comment on attachment 73723 [details] [diff] [review]

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
Yes, please take it.
adt2 per adt triage
Whiteboard: [adt2]
Assignee: rods → Roland.Mainz
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) ...
Keywords: review
Summary: [FIX]Page headers and footers outside printable region on almost all default printer setups → Page headers and footers outside printable region on almost all default printer setups
Comment on attachment 73723 [details] [diff] [review]

Death to this nightmare!
Attachment #73723 - Attachment is obsolete: true
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.
Depends on: 132563
Does the attached output print "OK" for you (size is "Letter") ?
Summary: Page headers and footers outside printable region on almost all default printer setups → [ps] Page headers and footers outside printable region on almost all default printer setups
Patch for bug 132563 has been checked-in, marking bug as FIXED.
Closed: 20 years ago
Resolution: --- → FIXED
footers are printing, but headers are cutoff as seen on linux commercial build 
Resolution: FIXED → ---
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 ?
Status: REOPENED → ASSIGNED, 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 "" 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 ""  just one little dash printed from the bottom of the 

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 [details] 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...

Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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!
Resolution: FIXED → ---
Blocks: 155934
ADT: Nominating topembed
Keywords: 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
Keywords: topembedtopembed-
No longer blocks: 155934
*** 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 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?
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.

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

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


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

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?
Yes, on the "Firefox" product, not the "Core" product.
Depends on: 280697
OK, see bug #280697
These responces are great, I kindeled some new fire in this age old problem.
I still need to figure out a solution ASAP if our company is going to push
Firefox over IE to client medical firms.

  Can anyone tell me how to hack the settings files, to fix this problem?
*** Bug 287042 has been marked as a duplicate of this bug. ***
*** Bug 263677 has been marked as a duplicate of this bug. ***
Seeing this problem in Firefox 1.5-0.1 (Gecko/20051128). Margins are set to .25, paper size to Letter. SUSE Linux 10.0. The paper size is set to Letter in the printer setup as well (OS level).
Just to clarify, mozilla has two sets of margin settings. One set is accessed through the File->Page Setup dialog, and controls placement of ordinary page content. The other is accessed (using the xp print dialog) through File->Print->Printer Properties. This set defines the boundaries of the page on which the printer can print. As a practical matter it's used to position the header and footer text. This bug is about the printer properties margin, not the page setup margin.
in the location bar, type about:config, then click in the box in the window, type print, click filter, then click something like this:


and then type 0.2 or 1.0.
It means how much space the headers and footers can take up.  If you just want to show the text, type 0.175 with the smallest line between the webpage and the text in Print Preview.

Works in 1.5.01 and 1.5.02
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.

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.
Depends on: 284925
Duplicate of this bug: 407413
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:

And the needed info can be extracted from this PPD using proper PPD-related functions:

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:
QA Contact: sujay → printing
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


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:
This bug is of the same era as
See Also: → 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.

Assignee: roland.mainz → nobody
Flags: needinfo?(jwatt)
You need to log in before you can comment on or make changes to this bug.