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

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Keith Briscoe]

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

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
manually.

Comment 1

[R.K.Aa.]

Please always include build ID in bug-reports.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[sujay]

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

Comment 4

[rods (gone)]

Attachment: patch

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 73723 [details] [diff] [review]
patch

Oh.  Doh.  :)

r=bzbarsky

Comment 6

[karnaze (gone)]

nsbeta1+

Comment 7

[Roland Mainz]

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 ?

Comment 8

[Roland Mainz]

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...

Comment 9

[Roland Mainz]

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.

Comment 10

[Kevin McCluskey (gone)]

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 11

[kinmoz]

Comment on attachment 73723 [details] [diff] [review]
patch

sr=[e-mail]

Comment 12

[Roland Mainz]

Comment on attachment 73723 [details] [diff] [review]
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.

Comment 13

[Roland Mainz]

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...

Comment 14

[rods (gone)]

Yes, please take it.

Comment 15

[Syd Logan]

adt2 per adt triage

Comment 16

[Roland Mainz]

Taking...

Comment 17

[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) ...

Comment 18

[Roland Mainz]

Comment on attachment 73723 [details] [diff] [review]
patch

Death to this nightmare!

Comment 19

[Roland Mainz]

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.

Comment 20

[Roland Mainz]

Attachment: 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") ?

Comment 21

[Roland Mainz]

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

Comment 22

[Tracy Walker [:tracy]]

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

Comment 23

[Roland Mainz]

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 ?

Comment 24

[Tracy Walker [:tracy]]

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)

Comment 25

[sujay]

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

Comment 26

[Roland Mainz]

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 ?

Comment 27

[Boris Zbarsky [:bzbarsky]]

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

Comment 28

[sujay]

marking fixed....this worksforme...

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

Comment 29

[sujay]

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

Comment 30

[Keith Briscoe]

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!

Comment 31

[Paul Wyskoczka]

ADT: Nominating topembed

Comment 32

[Michael Buckland]

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

Comment 33

[saari (gone)]

topembed- assuming this is linux only

Comment 34

[Alexander Opitz]

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

Comment 35

[fmouse-mozilla]

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.

Comment 36

[Josh]

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!

Comment 37

[fmouse-mozilla]

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.

Comment 38

[fmouse-mozilla]

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.

Comment 39

[Boris Zbarsky [:bzbarsky]]

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

Comment 40

[fmouse-mozilla]

(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?

Comment 41

[Boris Zbarsky [:bzbarsky]]

Yes, on the "Firefox" product, not the "Core" product.

Comment 42

[fmouse-mozilla]

OK, see bug #280697

Comment 43

[Josh]

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?

Comment 44

[R.K.Aa.]

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

Comment 45

[Kenneth Herron]

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

Comment 46

[u232687]

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).

Comment 47

[Kenneth Herron]

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.

Comment 48

[henryfhchan]

in the location bar, type about:config, then click in the box in the window, type print, click filter, then click something like this:

print.(printername).print_margin*

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

Comment 49

[Joseph William Baker]

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.

Comment 50

[Boris Zbarsky [:bzbarsky]]

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.

Comment 51

[Rick Richardson]

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.

Comment 52

[Aleksander Adamowski]

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.

Comment 54

[Pacho Ramos]

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

Thanks :-)

Comment 55

[Aleksander Adamowski]

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

Comment 56

[alan]

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.

Comment 57

[u285178]

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

Comment 58

[Wayne Mery (:wsmwk)]

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

Comment 59

[fmouse-mozilla]

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.

Comment 60

[Jim Michaels]

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.

Comment 61

[Jim Michaels]

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

Comment 62

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 63

[Daniel Holbert [:dholbert]]

(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.