Many web browsers not print the headers and footers.

Bug #29622 reported by louli_ostl on 2006-01-25
44
Affects Status Importance Assigned to Milestone
Bugzilla
New
Medium
Epiphany Browser
Expired
Medium
Mozilla Firefox
Confirmed
Medium
epiphany-browser (Ubuntu)
Low
Ubuntu Desktop Bugs
firefox-3.0 (Ubuntu)
Medium
Unassigned
kdebase (Ubuntu)
Low
Unassigned

Bug Description

Ubuntu Version: Dapper Flight2
1.Launch Applications->Internet->Firefox Web Browser;
2.Open a website in Firefox;
3.Select File->Page Setup->Margins & Header/Footer,set Header & Footer information as default;
4.Print the page. The Header & Footer have not been printed.

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

In , Rods (rods) wrote :

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

In , Rods (rods) wrote :

Yes, please take it.

adt2 per adt triage

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.

In , Jlee (jlee) wrote :

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?

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

In , Jlee (jlee) wrote :

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.

Ubuntu Version: Dapper Flight2
1.Launch Applications->Internet->Firefox Web Browser;
2.Open a website in Firefox;
3.Select File->Page Setup->Margins & Header/Footer,set Header & Footer information as default;
4.Print the page. The Header & Footer have not been printed.

John Doe (johndoedoejohn) wrote :

Are you still having this issue in newer versions of Firefox (or in newer Flight's of Ubuntu Dapper)?

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

Dean Sas (dsas) on 2006-04-29
Changed in mozilla-firefox:
status: Unconfirmed → Needs Info

I believe the "problem" is with the printer: firefox, by default, prints headers and footers very close to the edge of the paper and many consumer printers do not support printing on the edges.

Anyhow, printing in Firefox in Linux should be improved (setting edges is unreliable, you cannot set any useful printer options, ...), if not by the Firefox team, maybe Ubuntu developers could take the job?
I don't know about xprint, but AFAIK Ubuntu build has xprint disabled. Does it feature a more complete printer-options interface?

I have the exact same problem. My printer, a Brother MFC-8440, will print the header and footer when using the Windows driver and Firefox (1.5 or 2.0) but when using the Linux equivalent, no header or footer is to be seen. I don't know I fix, but I do know that this is the root of the problem.

David Farning (dfarning) on 2006-12-31
Changed in firefox:
assignee: nobody → mozillabugs
John Vivirito (gnomefreak) wrote :

Is this still and issue for you? We are trying to trying sort out the older Mozilla issues and would like to know if this still happens

Well, for an example I printed this page with firefox to my default printer with default settings, but I checked the "print to file" checkbox, so I can show the results. I converted the ps into a pdf.

My printer cannot print that close to the edges, that's one thing.
I can set bigger edges in File->Print->Properties and it works.
I suspect default edges (0.04) are set in inches, but on my system are interpreted as millimeters. Is that possible?

However, I STILL (after all those years of mozilla developers fighting this point of view) regard not being able to set up any advanced options (such as duplex printing) from GUI _AND_ having to use a completely different print dialog compared to other, more gnome-integrated parts of the system, a total usability failure ....

John Vivirito (gnomefreak) wrote :

Please try this with a different browser (maybe konquerer and see if it still happens. Ive been playing with it here and i can reproduce this but i think its in cups not browser. im gonna test konq. now and see if it still happens.

John Vivirito (gnomefreak) wrote :

Changed this to cupsys due to it is the same in non gecko browsers so its either printers or cups issue.

Changed in firefox:
assignee: mozillateam → nobody

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.

Changed in firefox:
status: Needs Info → Confirmed
Changed in kdebase:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Alexander Sack (asac) wrote :

For now I set it back to Needs Info, as this issue is not yet ready to process properly imo. Will come back later :).

Changed in firefox:
assignee: nobody → asac
status: Confirmed → Needs Info
Alexander Sack (asac) wrote :

maybe your paper size in firefox is letter while it should be something else?

skrivis (stuart-krivis) wrote :

At (http://ubuntuforums.org/showthread.php?t=348518&highlight=header+print+firefox) I just wrote the following:

"I was just bitten by this one too. Ubuntu 6.10 with an HP LJ 4200.

There are 2 places to set the margin in Firefox, properties from the print dialog, and then the other at File -> Page Setup.

The one in the print dialog properties was set to 0.04" and you can't set it any higher than 0.5" for some reason. Setting this to 0.5" all around helped, but not enough, so I also changed the top and bottom margins at File -> Page Setup to 0.7".

That did the trick."

After reading the info here in launchpad, I tried printing from Konqueror and it does not have this problem. (But it uses KDE's print dialog and UI.)

Test pages via the CUPS web UI print perfectly, so I that would seem to confirm that it is not CUPS at fault.

Printing by some other apps like Acrobat and OpenOffice seems to work fine too, as does something like "lp filename.pdf"

Alexander Sack (asac) wrote :

this is probably a dupe of "does not remember page setting" ... and "does not choose proper default page size (by locale)".

Is your page format right (e.g. A4, Letter)?

Peter Brimacombe (brimacombep) wrote :

skrivis: thank you
Problem: url header doesn't print
Problem Restated: print doesn't match print preview
Solution: make top and bottom margins bigger (from .04 to .5), you have to set this in two places

Michael B. Trausch (mtrausch) wrote :

Alright. Well, this has been one of those issues that has been around forever—and not just in this distribution, but in any other distribution that I have used (everything from Slackware on up).

I have two printers, an HP DeskJet, and a Lexmark E240 PCL printer. Both of them print perfectly using Firefox under Windows {insert version here}. Literally, everything from Windows 98 to Windows Vista can do this correctly.

However, when I print from Firefox under Linux, the header and the footer from Firefox are cut off. This is not a printer restriction, and the location is the same under Linux as it is under Windows. It just doesn't doesn't print under Linux. There are no settings that I can find in CUPS regarding changing its perception of the hard margin, which in the case of both printers is nearly the entire page size.

The most I can say with absolute certainty is that (a) Windows gets it right, (b) No Linux distribution I have used (Slackware, Red Hat, Fedora, Gentoo, Ubuntu) gets it right, (c) the bug is almost certainly not in Firefox, because CUPS cuts off the header on both printers such that a part of it shows up and the rest of it is clearly within the printer hardware's printable range.

Perhaps I can scan a couple of copies of things I have printed on both printers with identical settings, along with the output from print to file, and along with the same things printed from Windows. I am going to need to find some time to do that, however.

As a point of record, even the Ubuntu test page does not print within that area that the Firefox header/footer prints in; but the printer is capable of it.

It would seem, then, that the problem is really that CUPS either does not know that it can print there, or that the PPD is flawed in some way, or that there are assumptions being made elsewhere in the system that determine what can and cannot be printed. Presumably, this means that my HP DeskJet which supports "borderless" printing probably does not support that under my current configuration under Ubuntu. I've not the $$ to test that theory, though.

Michael B. Trausch (mtrausch) wrote :

And by the way, I have experienced this issue under Dapper, Edgy, and now Feisty (which is what I am currently running). All sizes are set to Letter both for the laser printer (Ubuntu Feisty Server, running CUPS and broadcasting the printer) and the InkJet (Ubuntu Feisty, directly attached to my workstation).

Firefox 2.0.0.4, when run under Ubuntu Fisty 7.04 would print two almost blank pages for each page printed. Both almost blank pages had a thin line of dots at the top of each page, which later appeared to be attempts to print the page's header and footer.

Firefox has two sets of margin adjustments, one for the page and another for the sheet to be printed.

It appears that the default margin information Firefox sends to CUPS is wrong.

To print both a pages header and footer properly on my HP PSC-2175 I had to set the page and sheet margins as follows:

     File > Print Setup > Margins & Headers/Footers
          Top: 0.5 Left: 0.5 Right: 0.8 Bottom: 0.8

     File > Print > Properties
          Top: 0.25 Bottom: 0.5 Left: 0.25 Right: 0.5

I've spent some time looking at the ppd for my Epson PM-670C and found that using align.ps and the alignmargins utility from OpenPrinting.org I could confirm that the PPD is absolutely correct as far as the physical printable area of the page is concerned (I used the Epson Stylus Photo Series PPD). I investigated this because Firefox/Iceweasel was cutting off the outer edges of the header in my printouts. So I measured in millimeters what the margins were in fact, and put those (converted to inches) into the options for that printer in the Firefox/Iceweasel print dialog options settings. Presto, the printing did the right thing. However, as people have pointed out, there's a lot more to printing than just setting the right margins, LOL It does help tremendously if that detail is right though, so please have a look at align.ps and friends and see if you can improve the output of your printing while it gets fixed in the browser.
--
Gernot Hassenpflug

Changed in epiphany-browser:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Confirmed
Changed in epiphany-browser:
status: Unknown → New
Alexander Sack (asac) wrote :

I already asked, but received no response, so here another try:

If you see this issue, can you please check the Paper Size selected in File -> Print ... -> Properties ... dialog?

Is it as expected?

On Mon, 2007-07-30 at 01:33 +0000, Alexander Sack wrote:

> I already asked, but received no response, so here another try:
>
> If you see this issue, can you please check the Paper Size selected in
> File -> Print ... -> Properties ... dialog?
>
> Is it as expected?

Indeed. Letter, as expected on my system. It just tries to print
outside of the hardware-enforced paper margins (which on my laser
printer are pretty tiny; it does print the bottoms of letters like g, p,
q, and y, for example).

    — Mike

--
Michael B. Trausch
                                Web:
              http://www.trausch.us/
Phone: (404) 592-5746
                    Jabber IM/Email:
           <email address hidden>
Demand Freedom! Use open and free protocols, standards, and software!
Support free speech---it is the most valuable freedom we have!

Alexander Sack (asac) on 2007-07-30
Changed in firefox:
status: Incomplete → In Progress
Changed in firefox:
status: Unknown → Confirmed
Alexander Sack (asac) wrote :

ok, i think a real fix might be too hard to get soon. However, I want to do something about this .... so I try to find margins/bounds that at least does not cut off header and footer for most.

Can you confirm that these bounds fix this issue for you:

     File > Print Setup > Margins & Headers/Footers
          Top: 0.5 Left: 0.5 Right: 0.8 Bottom: 0.8

     File > Print > Properties
          Top: 0.25 Bottom: 0.5 Left: 0.25 Right: 0.5

syncomm (syncomm) wrote :

Those margins fix it for me! Thanks!

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.

Markus (mailnov) wrote :

I had the same issue and the value 0.5 do not work to me. The Print Setup dialogue mentions that these values are in mm. i.e. 0.5 mm from the top is very, very small. After I changed the values to 5.0 for both the header and footer are back again. Is there an issue between measurements (US vs metric)?

Changed in epiphany-browser:
status: New → Confirmed

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.

This problem currently has little chances of getting fixed, since the printing subsystem in Mozilla Core used by Firefox is practically unmaintained.

See:

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

I think the developer who is able to fix this is Roland Mainz (http://www.nrubsig.org/people/gisburn/) who quit working on Mozilla a couple of years ago. Maybe Canonical could hire him for the task of improving Mozilla Firefox's printing and its CUPS integration?

toobuntu (toobuntu) wrote :

"Alexander Sack wrote on 2007-08-02:

     File > Print Setup > Margins & Headers/Footers
          Top: 0.5 Left: 0.5 Right: 0.8 Bottom: 0.8

     File > Print > Properties
          Top: 0.25 Bottom: 0.5 Left: 0.25 Right: 0.5"

These options don't seem to exist any more in FF3b4 in Hardy. What to do?

  • unnamed Edit (189 bytes, application/pgp-signature; name=signature.asc)

On Mon, 2008-03-31 at 21:33 +0000, toobuntu wrote:
> These options don't seem to exist any more in FF3b4 in Hardy. What to
> do?

You can (though it's not _perfect_) go to Page Setup and select your
printer to format it for. Unfortunately, the option doesn't appear to
be "sticky"... that is, it doesn't seem to persist between Firefox
sessions.

 --- Mike

--
Michael B. Trausch <email address hidden>
home: 404-592-5746, 1 www.trausch.us
cell: 678-522-7934 im: <email address hidden>, jabber
Ubuntu Unofficial Backports Project: http://backports.trausch.us/

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

Jonathan Thomas (echidnaman) wrote :

Is this bug still valid for Konqueror 4.1.1? If so, an upstream report needs to be made and linked here.

Changed in kdebase:
status: Confirmed → Incomplete
Rolf Leggewie (r0lf) wrote :

I used to see (and be annoyed by) this problem with Firefox printing. But I am happy to say that this seems to work fine OOTB for some time now. I run hardy.

Printing from Thunderbird seems to be still too close to the edge.

Bruce Miller (brm0423) wrote :

I am running Kubuntu Intrepid Ibex beta with Firefox 3.0.3.

This bug is not only still valid, but Firefox 3.0 has introduced serious regression.

To the best of my knowledge, *_all_* HP LaserJet printers (and I have used many, going back to the original ~1986 model) have an unprintable area 0.5" (12.7mm) across the top and bottom of all paper sizes and 0.25" (~6.4mm) along each side of all paper sizes (top, bottom and sides as seen in "portrait" mode).

To get browser headers and footers to print reliably has always taken tweaking of the printable area and margins/headers/footers. The Firefox 3 page setup and printer dialogs have removed all ability to alter these settings.

This regression makes Firefox 3 on Linux close to useless for printing Web pages. I am trying to eliminate Windows from my life and considerably prefer Firefox to Konqueror. This regression therefore represents a considerable setback.

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

Michael B. Trausch (mtrausch) wrote :

Firefox in Intrepid seems to be getting this right for me now, adjusting the top and bottom on two different laser printers that I have with different available print areas. It'd seem that this is able to be closed for FF3 in Intrepid; anyone able to confirm that with another printer (preferably not a PCL6 or PostScript one)?

I would be disappointed to see this bug closed. Problems remain with Firefox 3 in the Intrepid Ibex beta using an old HP LaserJet 4L.

I have written up these problems on UbuntuForums (http://ubuntuforums.org/showthread.php?t=939484) and as bug 458641 on the Mozilla bug database. Briefly, the resolution involves a clumsy work-around, namely a special paper type buried in a sub-menu. Also, on my printer, the headers and footers still print outside the imageable area as defined by the special paper type and as set by CUPS. On my particular model, pages are also offset by 3/8" to the printable area set by CUPS.

Jonathan Thomas (echidnaman) wrote :

From previous comments it seems that this bug is no longer an issue with Konqueror.

Changed in kdebase:
status: Incomplete → Fix Released
Changed in bugzilla:
status: Unknown → New
Bruce Miller (brm0423) wrote :

I have changed the status back to New. Printing of KDE 4.x applications has been totally broken across three distributions of Kubuntu (7.10, 8.04, 8.10 development) and on different hosts and after several re-installations.

The problems experienced include, but are far from limited to, the lack of headers and footers.

Changed in kdebase:
status: Fix Released → New
Bruce Miller (brm0423) wrote :

I have filed a new bug againt Kubuntu printing in Intrepid Ibex because the problems go well beyond missing headers and footers. It is Bug 284730. I put in a reference there to this bug.

Changed in epiphany-browser:
status: Confirmed → Triaged
Alexander Sack (asac) on 2008-10-31
Changed in firefox:
status: In Progress → Triaged
Changed in firefox-3.0:
importance: Undecided → Medium
status: New → Triaged
Micah Gersten (micahg) wrote :

No more fixes will occur for Firefox 2.

Changed in firefox (Ubuntu):
assignee: Alexander Sack (asac) → nobody
status: Triaged → Won't Fix
Nicola Ferralis (feranick) wrote :

Fixed in Firefox-3.0

Changed in firefox-3.0 (Ubuntu):
status: Triaged → Fix Released
Nicola Ferralis (feranick) wrote :

Fixed in Epiphany-browser 2.22.2 (hardy)

Changed in epiphany-browser (Ubuntu):
status: Triaged → Fix Released
Jonathan Thomas (echidnaman) wrote :

The headers and footers print fine for me with Konqueror here. Since the remaining KDE print problems are being tracked in a different bug I'm closing this for kdebase.

Changed in kdebase (Ubuntu):
importance: Medium → Low
status: New → Fix Released
Changed in epiphany-browser:
importance: Unknown → Medium
Changed in firefox:
importance: Unknown → Medium
Changed in bugzilla:
importance: Unknown → Medium

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

Changed in epiphany-browser:
status: Confirmed → Expired
Adolfo Jayme (fitojb) on 2015-01-23
no longer affects: firefox (Ubuntu)
Changed in bugzilla:
status: New → Unknown
Changed in firefox:
status: Confirmed → Unknown
Changed in bugzilla:
status: Unknown → New
Changed in firefox:
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.