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

REOPENED
Assigned to

Status

()

Core
Printing: Output
REOPENED
15 years ago
a year ago

People

(Reporter: Keith Briscoe, Assigned: Roland Mainz)

Tracking

(Depends on: 1 bug, {topembed-})

Trunk
mozilla1.0
x86
Linux
topembed-
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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

15 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Page headers and footers outside printable region → Page headers and footers outside printable region on almost all default printer setups

Comment 3

15 years ago
I agree with Boris..I'm also seeing the problem..

Comment 4

15 years ago
Created attachment 73723 [details] [diff] [review]
patch

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

Updated

15 years ago
Status: NEW → ASSIGNED
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]
patch

Oh.  Doh.  :)

r=bzbarsky
Attachment #73723 - Flags: review+

Comment 6

15 years ago
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Comment 7

15 years ago
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 ?
(Assignee)

Updated

15 years ago
Attachment #73723 - Flags: needs-work+
(Assignee)

Comment 8

15 years ago
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...
(Assignee)

Comment 9

15 years ago
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 11

15 years ago
Comment on attachment 73723 [details] [diff] [review]
patch

sr=kin@netscape.com
Attachment #73723 - Flags: superreview+

Updated

15 years ago
Keywords: review
(Assignee)

Comment 12

15 years ago
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.
(Assignee)

Comment 13

15 years ago
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

15 years ago
Yes, please take it.

Comment 15

15 years ago
adt2 per adt triage
Whiteboard: [adt2]
(Assignee)

Comment 16

15 years ago
Taking...
Assignee: rods → Roland.Mainz
Status: ASSIGNED → NEW
(Assignee)

Comment 17

15 years ago
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) ...
Status: NEW → ASSIGNED
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
(Assignee)

Comment 18

15 years ago
Comment on attachment 73723 [details] [diff] [review]
patch

Death to this nightmare!
Attachment #73723 - Attachment is obsolete: true
(Assignee)

Comment 19

15 years ago
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
(Assignee)

Comment 20

15 years ago
Created attachment 75728 [details]
PostScript output from PostScript module created with 2002-03-18-08-trunk and attachment 75725 [details] [diff] [review] from bug 132563

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

Updated

15 years ago
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
(Assignee)

Comment 21

15 years ago
Patch for bug 132563 has been checked-in, marking bug as FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
footers are printing, but headers are cutoff as seen on linux commercial build 
2002-03-26-06-trunk
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 23

15 years ago
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
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

15 years ago
Boris, does the header and footer print out for you?
(Assignee)

Comment 26

15 years ago
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).

Comment 28

15 years ago
marking fixed....this worksforme...

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

Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 29

15 years ago
verified in 3/26 build...I get header and footer for all 3 platforms.
especially linux.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 30

15 years ago
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!
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Updated

15 years ago
Blocks: 155934

Comment 31

14 years ago
ADT: Nominating topembed
Keywords: topembed

Comment 32

14 years ago
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

14 years ago
topembed- assuming this is linux only
Keywords: topembed → topembed-

Updated

14 years ago
No longer blocks: 155934

Comment 34

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

Comment 35

14 years ago
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

13 years ago
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

13 years ago
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

13 years ago
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?

Comment 40

13 years ago
(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.

Updated

13 years ago
Depends on: 280697

Comment 42

13 years ago
OK, see bug #280697

Comment 43

13 years ago
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

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

Comment 45

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

Comment 46

12 years ago
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

12 years ago
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

11 years ago
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

10 years ago
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.

Comment 51

10 years ago
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.
Depends on: 284925

Updated

9 years ago
Duplicate of this bug: 407413

Comment 54

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

Updated

7 years ago

Comment 56

6 years ago
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

6 years ago
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
See Also: → bug 256095

Comment 59

a year ago
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

a year ago
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

a year ago
and btw, the page prints to 0.25" margins unfortunately despite 0.5 setting in file, page setup.
You need to log in before you can comment on or make changes to this bug.