Default page size for printing is letter

changed title from:

  Default printer settings set to US Letter and inches

to:

  Printer settings should default to appropiate values for the user

So what works these days?

  /etc/papersize

  LC_PAPER

  nl_langinfo(PAPER_HEIGHT) / nl_langinfo(PAPER_WIDTH)

  others?

assign to katakai-san.
please have a look. Thanks

what's the status of this?

I've started working on this.

This issue also affect Thunderbird 1.5.0.7 (tested on Ubuntu 6.10).

This bug seems to be the same as https://bugzilla.mozilla.org/show_bug.cgi?id=144625 .

Will be marking that one as duplicate.

Masaki, are you still working on this?

Masaki, can you provide any feedback on this ? A month has gone by. Thank you.

I'm very sorry for the late response. I will not be able to work on this area. Anyone can take this?

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

Since Masaki can't work on this, shouldn't the bug be marked as NEW then?

This bug is really annoying. Is anyone interested in solving it? Is there a usual way to support (financially) someone?

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.8.1.11) Gecko/20071205 Firefox/2.0.0.11
Build Identifier:

Seems that Firefox/Seamonkey printing dialog doesn't take care of /etc/papersize setting and always defaults to letter instead of "a4" (/etc/papersize is provided by libpaper)

Thanks a lot for fixing this

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

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

confirming based on the dupe

Mandriva's 2008.1 firefox 2.0.0.13 doesn't has this bug though and I don't remember having it on other distributions using firefox 2.x.

It is still valid with 2.0.0.14, hopefully fixed in firefox3 because of gnome-printing usage

(Mandriva applies a lot of patches to their firefox, maybe one of them fixes this)

No it's not fixed in Firefox 3, that's why I reported the bug ;). See the duplicate.

I have exactly the same problem on Firefox3.
Opera and Konqueror browser can print in A4 with no problem.
This is a Firefox 3 bug.
Please to resolve it quickly.
Thank you.

I confirm this bug, its being happening since a while and its always get marked as dupe and resolved. But its never resolved, neither on Firefox 3.

Once you close firefox and open it again, default paper size is, again, us letter :(

People jams shared printers (waiting for confirmation) because of the paper size, and the more users trying to print to a networked printer, the more annoying it gets ;)

Known workaround (for the "highly computer literate"):

Print into some "virtual printer"
that accepts letter page size and generates PDF,
start some PDF viewer on the output,
set the page size to A4 in the PDF viewer, and "shrink page to fit paper",
print.

There must be a better workaround.
How can I set the page size for one single print job?

This problem has returned with a vengeance with Firefox 3. 3.0.5 implements
this Letter size default in a most annoying way that is really a challenge to override.

I am attempting now to determine what action I can take through the 'about:config" page.
What is the meaning of the '666' value in print.printer_CUPS/hp4l.print_paper_size?

On this (continuously upgraded from previous versions) Fedora 10 system,
$ cat /etc/papersize
A4
$ echo $LC_PAPER

So will try to set LC_PAPER (which should really be deduced
from my setting of LANG).
$ env | grep -i en_au
LANG=en_AU.UTF-8

With LC_PAPER set to a4, I get:
(process:22371): Gtk-WARNING **: Locale not supported by C library.
 Using the fallback 'C' locale.

(firefox:22371): Gdk-WARNING **: locale not supported by C library
With this unset, firefox starts without complaint.
I have changed the content of /etc/papersize to
a4
in case that helps.

smontagu: are you actually working on this? What's the status, please?

I have volunteered to take on this issue (note: I am not smontagu) with the aim of writing a patch. Since I am not a regular mozilla code contributor, the bug is still assigned to smontagu (perhaps I can be made a co-assignee?)

I have started looking into the mozilla code base in November, and the current status is still familiarization with the code base. I have 16 hours per month to spend on this issue, so it should be possible to make progress, albeit somewhat slowly.

Sebastian: assigning to you
smontagu is default assignee for this component, so I would expect he won't object;)

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

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

*** This bug has been marked as a duplicate of bug 147419 ***

Comment in duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=407406#c3 alleges that Mandriva has solved this problem. I tried to find a public repository of their patches, but gave up. Perhaps somebody more knowledgeable about their processes and infrastructure could look into this.

Just for the record, I don't think "a4" is a valid value for $LC_PAPER. It is not part of the standard locale settings (yet?) so it's not very well documented. My impression is that you can set LC_PAPER to the name of a valid locale, and then have the paper size from that locale override any other locale settings of yours. Thus, try e.g. LC_PAPER=en_DK (depending also on what locales are supported on your installation). But at this time, of course, Mozilla doesn't care at all about the value of this setting (other than including it in crash reports). [1]

[1] http://mxr.mozilla.org/mozilla-central/search?find=%2F&string=LC_PAPER

@Sebastian J Bronner: have you been making any progress?

fwiw, the crash reporter is actively ignoring the lc_ stuff, not honoring it ;-)

My original proposal above, from 2002-05-27, namely to decide on preferred units of measurement and standard paper size by searching for country codes in the LC_* environment variables (exactly as suggested in the above piece of code) is IMHO still the most advisable solution today! Please just try it, before thinking up alternatives.

The alternatives simply don't wash: The /etc/papersize mechanism is a complete non-starter, as it is a global setting that you cannot easily override for individual users or processes. The nl_langinfo(PAPER_HEIGHT) / nl_langinfo(PAPER_WIDTH) was a draft proposal (ISO technical report 14652) that only glibc implemented but that never made it into the POSIX standard or any other ISO standard. It won't work on other platforms and just leads to ugly platform-specific #ifdef massacres.

The above code will do the right thing by default on all POSIX platforms (not just Linux) and provides easy and obvious ways for users to override the defaults. It is the most pragmatic and workable solution you are going to find, given the rather messy standardization in this area.

What it does is very simple: The defaults are millimetres and A4 (because that's what ~95% of the world population use), and only if your environment suggests that you are in Canada or the U.S. will the default paper size become U.S.-Letter, and only if you are in the U.S. will the default unit of measurements become inches. This will be determined by the first of the variables LC_ALL, LC_{PAPER,MEASUREMENT}, LANG that is defined and non-empty, exactly the same priority order that setlocale() applies, but implemented in a strictly portable way without requiring the setlocale() implementation to even know of LC_{PAPER,MEASUREMENT}.

The inclusion of LC_{PAPER,MEASUREMENT} makes sure that users can override their countries' default for paper and measurement without affecting anything else. On the day when the U.S. finally goes metric, simply set LC_MEASUREMENT=POSIX and its done.

Shouldn't the more-specific LC_PAPER and LC_MEASUREMENT be allowed to override LC_ALL if they are present, though? (Pardon my ignorance.)

No, the whole purpose of LC_ALL is to allow you to override everything else, whereas the purpose of LANG is to provide the lowest-priority default. The more specific LC_* environment variables are placed between those two extremes in the priority order. (I regularly write LC_ALL=C to force all locale mechanics off in tests.)

Reference: POSIX, section 8.2 (Internationalization Variables): "The value of the LC_ALL environment variable has precedence over any of the other environment variables starting with LC_"

To understand the definition of these environment variables, read
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_02

Thanks for the solid clarification. It's odd how sparsely documented this is, at least on Linux.

(In reply to comment #22)
> Comment in duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=407406#c3
> alleges that Mandriva has solved this problem. I tried to find a public
> repository of their patches, but gave up.

I installed Mandriva Linux Free 2009.0 in Virtualbox. It's got Firefox 3.0.5. Even though I set up my regional settings to prefer A4 paper, Page Setup in Firefox defaults to letter. So there doesn't seem to be any basis for the claim that Mandriva has fixed this.

This problem is the same on Ubuntu Hardy LTS.
Does someone know how to make Firefox 3 understand that I want A4 paper by default? Without using GUI, of course, since it's for a Firefox Linux deployment, not for a personal Desktop.
I have tried without success to play with prefs.js, with *.rdf files, with gnome-printer-settings, with gtk-printer-settings, with gconf-editor and no success with all of these approaches.

Given the ubiquity of Linux compared to other unix systems (ignoring MacOS, which has its own port), is it really such a problem to include platform specific code, provided there is a reasonable fallback for other systems?

There is an API that will provide the locale default paper size, so it seems silly to rely on heuristics instead.

(In reply to comment #23)
> @Sebastian J Bronner: have you been making any progress?

No progress to report yet, but I am continuing to work on the issue as time permits.

(In reply to comment #25)
> My original proposal above, from 2002-05-27, namely to decide on preferred
> units of measurement and standard paper size by searching for country codes in
> the LC_* environment variables (exactly as suggested in the above piece of
> code) is IMHO still the most advisable solution today! Please just try it,
> before thinking up alternatives.

My proposol for implementation is to check for the proper paper size setting by stepping through the following items. The first successfully determined value would be used:

1 - if it exists, use a firefox-specific setting
    stored in the user's firefox profile
2 - infer paper size from LC_ALL
3 - infer paper size from LC_PAPER
4 - infer paper size from LANG
5 - if it exists, read paper size from /etc/papersize
6 - retrieve paper size from cups (if that is possible)
7 - default to a4

Comments?

I have left LC_MEASUREMENT out of this list purposely because it really has no direct bearing on paper. A user may wish to specify different measurement units, but wouldn't expect his locale's paper size to change because of that.

Step 1 - the firefox-specific setting is for users who don't care about user profiles. The user would be able to make a choice in a dialog between a specific paper size and "locale default" (or similar). This would be set to "locale default" unless the user specifically changes it.

Just for the record: only on glibc systems, an API for interpreting the LC_PAPER aspect of the locale setting is

#include <stdio.h>
#include <langinfo.h>
#include <locale.h>

int main()
{
  if (!setlocale(LC_PAPER, "")) {
    fprintf(stderr, "Can't set the specified locale! "
            "Check LANG, LC_PAPER, LC_ALL.\n");
    return 1;
  }
  printf("paper height = %d mm\n", (int) nl_langinfo(_NL_PAPER_HEIGHT));
  printf("paper width = %d mm\n", (int) nl_langinfo(_NL_PAPER_WIDTH));
  return 0;
}

which results in

$ LC_ALL=en_GB.UTF-8 ./lc_paper
paper height = 297 mm
paper width = 210 mm
$ LC_ALL=en_US.UTF-8 ./lc_paper
paper height = 279 mm
paper width = 216 mm
$ LC_ALL=en_CA.UTF-8 ./lc_paper
paper height = 279 mm
paper width = 216 mm

I just checked with

  for l in `locale -a` ; do echo $l: ; LC_ALL=$l ./lc_paper ; done

all glibc locales on openSUSE 10.3 and found in addition to US and CA only one other country code whose locales specify the U.S. Letter format: PR = Puerto Rico.

So please change in my original test code the term

  strstr(s, "_US") || strstr(s, "_CA")

into

  strstr(s, "_US") || strstr(s, "_CA") || strstr(s, "_PR")

to make its results compatible with glibc.

The file /etc/papersize is a configuration file of the groff text formatting package. It is not mentioned in any API standard. I strongly recommend that Firefox ignores groff configuration files.

This file really should have been called something like /etc/groff/papersize or, even better, groff should have used LC_PAPER instead, as proposed here for Firefox. Let's not perpetuate a mistake made in the design of groff by carrying it over into a web browser. One locale mechanism is enough. Forget about /etc/papersize.

If nobody else has the time, perhaps the fix could be made a Google summer of code project?

This is one of the most annoying bugs if your using FF in a business deployment.
It's really annoying that the printers stops working after it receives a Letter print job.

Also Mozilla Prism is facing the same problems (same code base I guess). Is there a way we can vote for this bug or something?

@Gerwin: there is a "vote" link next to the Importance field at the top of the Bugzilla web page for this bug report (which you will find a link to if you read this over email; I believe you will need to be logged in to your Bugzilla account in order to be able to vote, and possibly even see the "vote" link).

With FF3, printing a small sized page (popup format) forces printer into "Letter" while it's configured to "A4", making it unprintable.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.7) Gecko/2009031120 Mandriva/1.9.0.7-0.1mdv2008.1 (2008.1) Firefox/3.0.7

Can't reproduce it with Seamonkey
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.19) Gecko/20081216 SeaMonkey/1.1.14

related to bug 379074
related to Bug 414041 ?

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

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

does it really make sense to favor LC_anything over CUPS settings?

if i have two printers and one is using metric and one is using letter, surely i can't possibly want an env var to break one or the other.

note that using setlocale() is not something I'd want to see. We do not need to have our fragile code confused by something which will almost certainly confuse it on random systems and in random places. Yes that means someone might be forced to parse a couple of env vars manually, however, that's life and it's better than breaking the rest of our code.

1 - if it exists, use a firefox-specific setting
    stored in the user's firefox profile
2 - retrieve paper size from gtk
    (and hence cups)
---------------questionable---------------
3 - infer paper size from LC_ALL
4 - infer paper size from LC_PAPER
5 - infer paper size from LANG
---------------questionable---------------
6 - if the system is using something that hints it isn't en-US default to a4

There are lots of people in the US, and just because I'm one of the stupid ones who isn't there doesn't mean we should magically do something strange to their systems.

http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsPrintSettingsGTK.cpp

afaict, we use something called gtk_paper_size_get_name today and have since bug 193001 was fixed in 2008.

it's documented here:
http://library.gnome.org/devel/gtk/unstable/gtk-GtkPaperSize.html

Perhaps someone could figure out why it isn't doing the right thing instead of complaining about our behavior?

reporter: since you're able to use a compiler, could you please investigate?

someone who doesn't have a compiler is free to find a typical gnome app and (something like gedit) and indicate whether it gets this stuff right. if it does, then you could perhaps try to find someone who can compare our code (it's in the one file i listed above) with the gtk app's code.

@timeless: gedit gets it right, at least on my system. So do leafpad, evince, dictionary, eog, and in fact every other app except Firefox.

Should change this bug to something more important than a simple "enhancement".
For me, Firefox isn't able anymore to do a direct print to a laser printer.

roderick: cool, so please pick one and figure out what they're doing.

because i'd expect an app like gedit to use the gtk api and get data from cups.

or do you people really not have cups installed?

I have some more infos in Bug 478733

Actually I do think printing resets always to A4 currently if the paper size doesn't match the internals. I do think LC* is the wrong way.

Actually any hard paper setting is very wrong because I need to switch between A4 and POS Printing.

I tested on the same CUPS Setup:
Firefox 3.0.6 => Tries to always Print A4 on the pos printer, grrr!
Epiphany (Gecko) => Result was a bit better, but not perfect.
Margins couldn't be disabled, so not usable at all.

Midori Browser (Webkit+GTK) => This was the best experience, no margin problems, printing works on the POS Printer, yay!

My LC_PAPER=fr_FR and it stills try to print in US Letter format, which printer rejects. (no suitable tray).

Besides, for similar documents, the first print goes OK and prints to A4. The next ones goes to US Letter.

Something is really messed up. What are the differences with current Seamonkey (which works) ?

This bug has been reported back in 2002, it's 7 years now and it's still not resolved. I just spent an hour trying to force cups-pdf to produce A4 pdf instead of US Letter.

Why firefox ignores printer settings at takes a value from system's default? even though my LC_PAPER=en_GB suggests it should print on A4, it still prints on US Letter.

I had to set values (paper name, paper sizes) manually in order to get my cups-pdf working.

I've been scouring the firefox code-base repeatedly with all sorts of search terms, and I can't seem to find the code that makes the decision about what paper size to use when printing.

I'm still looking, but if anybody knows something, I'd be grateful for a pointer.

Maybe http://mxr.mozilla.org/comm-central/search?string=printsettings&filter=^[^\0]*$

Paper size should NOT be linked to language, but to location.
One can use any language in any country, but in most cases, you can only buy one type of paper size in a particular country or continent, e.g. A4 in Europe, Letter in US (for any language).

Here's an update:

Printing 2 pages document gives 1 correct A4, and the 2nd as US.

When you try to print, you can't select paper tray and the menu is grayed/stuck to "US Letter".

** workaround **
Now, if you "Print Preview", and you can change the document layout to A4 from the menu (footers options/ ...) and it's no longer US Letter. It Prints.

Pls some ppl confirm this.

Hi Francois,

I can confirm this behaviour! If you then go back to Print->Page Setup, you then find that Paper Size is now set to A4.

This is in FF 3.5.9

Also, settings are changeable in Page Setup.

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

I can confirm this behavior with Firefox 3.5 on Ubuntu 9.10

I can confirm the print preview from #52, and #53.

I've got a printer here with multiple types of stationary (A3, A4, ...) -- except I can't actually buy US Letter.

I suggest you don't ask the printer for paper size, since it actually accepts print jobs for US Letter, but expects me to go buy stationary before it's willing to print.

It should default to something sane (locale and /etc/papersize have settings) and allow the user to change per printjob.

It's possible to select stationary in Firefox 4 Beta 1

I've been debugging this a bit. The default "US Letter" setting comes from the following lines in nsPrinterEnumeratorGTK::InitPrintSettingsFromPrinter

  nsXPIDLCString papername;
  if (NS_SUCCEEDED(CopyPrinterCharPref(pPrefs, "postscript", printerName, "paper_size", papername))) {
  nsPaperSizePS paper;

  if (paper.Find(papername)) {
    DO_PR_DEBUG_LOG(("setting default paper size to '%s' (%g mm/%g mm)\n",
                     paper.Name(), paper.Width_mm(), paper.Height_mm()));
    aPrintSettings->SetPaperSizeUnit(nsIPrintSettings::kPaperSizeMillimeters);
    aPrintSettings->SetPaperWidth(paper.Width_mm());
    aPrintSettings->SetPaperHeight(paper.Height_mm());
    aPrintSettings->SetPaperName(NS_ConvertASCIItoUTF16(paper.Name()).get());
  }

It would be better to just call SetPaperName with null and let gtk_paper_size_new set it to the locale default. Better still would be to pull in the system settings for the printer, but I'm not sure how to do that.

This is still not solved for me - I've got an A4 printer paper selected in Firefox, I've got A4 selected in CUPS-PDF and I get US Letter print-out.

Created attachment 500694
don't use PS prefs in gtk

The attached patch fixes this problem for me.

In widget/src/xpwidgets/nsPrintOptionsImpl.cpp the page size is read and written to the prefs of the form:

print.printer_NAME.print_paper_name
print.printer_NAME.print_paper_size_width
print.printer_NAME.print_paper_size_height
print.printer_NAME.print_paper_size_type
print.printer_NAME.print_paper_size_unit

where NAME is the printer name.

In widget/src/gtk2/nsDeviceContextSpecG.cpp the page size is read but not written from the following prefs:

print.postscript.printer_NAME.paper_size
print.printer_NAME.paper_size
print.postscript.paper_size
print.paper_size

The problem is the prefs read in nsDeviceContextSpecG.cpp are not the same as the prefs written in nsPrintOptionsImpl.cpp. If these prefs do not exist there is no problem as the prefs read in nsPrintOptionsImpl.cpp are used. However I have found that in a newly created profile the pref "print.postscript.paper_size = letter" always exists. This will always be read and override the saved paper size. As it is not written, the "letter" default will not go away.

The attached patch changes the module name used when reading prefs in nsDeviceContextSpecG.cpp from "postscript" to null so the "print.postscript.paper_size" pref is never read. I am assuming the "postscript" module name is leftover from before gtkprint was used.

With the patch applied and using a newly created profile the default paper size will be the gtk_paper_size_get_default() paper size which is based on the current locale. After printing for the first time the selected page size is correctly saved and restored the next time the print dialog is opened.

Adrian : It seems really great. I hope that it could be commited into trunk for both Thunderbird & Firefox.

Hello. I'am italian. I have the same problem.. System default paper=A4. All other program work fine. I want to print in firefox 3.6.13, but the default in firefox is always letter. I set to A4 but firefox always forget that. It always start with letter size.
Please help me. Thanks in advance

The evil print.postscript.paper_size letter default comes from bug 125078 and
I don't see any means provided for changing the default.

initPrintSettingsFromPrinter was meant to get setting from the printer and the
xprint backend implementation appropriately asked the system for available
paper sizes. It seems print.postscript.paper_size pref was just a space
filler for lack of a postscript implementation.

savePrintSettingsToPrefs and printer-specific prefs in
initPrintSettingsFromPrefs weren't added until bug 128142 and they now seem
the appropriate place for managing preferences.

So I agree that it is better to leave the paper settings at their default than
to pull in this arbitrary default.

Comment on attachment 500694
don't use PS prefs in gtk

However, the way that this patch avoids the arbitrary default adds to the
existing confusion. It works because the pref lookup no longer matches the
pref setting. It would be better to remove the pref and the lookup code.
http://hg.mozilla.org/mozilla-central/annotate/a66254dfa588/modules/libpref/src/init/all.js#l3065

One of the (many) strange things about the print setup code, is that the list
of (basic standard) paper sizes is only added to
print.tmp.printerfeatures.paper.* if a paper_size pref is found, and that will
rarely be anything but "print.postscript.paper_size".
http://hg.mozilla.org/mozilla-central/annotate/7a3469118cf3/widget/src/gtk2/nsDeviceContextSpecG.cpp#l898
(The initial implementation was added in bug 132563.)

print.tmp.printerfeatures.paper.* is only used from
toolkit/components/printing/content/printjoboptions.js, as a set of available
paper sizes. AFAICS however, that is only used if
nsPrintingPromptService::ShowPrintDialog cannot find nsIPrintDialogService.
Now that the GTK port provides a nsIPrintDialogService, there is no need to
set up print.tmp.printerfeatures.paper.*

So it safe to remove the whole paper_size block
http://hg.mozilla.org/mozilla-central/annotate/7a3469118cf3/widget/src/gtk2/nsDeviceContextSpecG.cpp#l883

I found solution to my problem by doing this:
1-assured that in /etc/papersize there is written only a4.
2-open /usr/share/ghostscript/8.71/lib/ghostpdf.ppd and erase every line with inside the word "letter".
3-open /etc/cups/ppd/KM-1635.ppd (instead of KM-1635 use the name of the printer that doesn't print to a4) and delete the line where there's write letter/letter like this

*PageSize Letter/Letter: "%% FoomaticRIPOptionSetting: PageSize=Letter"
*FoomaticRIPOptionSetting PageSize=Letter: "-p1 "

*PageRegion Letter/Letter: "%% FoomaticRIPOptionSetting: PageSize=Letter"

*ImageableArea Letter/Letter: "12.00 12.00 600.00 780.00"

*PaperDimension Letter/Letter: "612 792"

4)changed in firefox at about:config every line where there's letter on na_letter or letter to a4 and the dimension of that format forced to height 297 and width 210. when i restart firefox the values of print.postscript.paper_size was returned to letter for example but the printer print correctly to a4.

Sorry for my english... Bye

i add to /etc/environment a line, too

LC_PAPER=it_IT.UTF-8

i'm not sure but i think this don't do nothig....

Bye

I prefer changing /etc/default/locale from en_US to en_GB in which changes the printing defaults from letter to A4:
LANG=en_GB.UTF-8

Debian/Ubuntu:
sudo /usr/sbin/update-locale LANG="en_GB.UTF-8"

JunyaKeller: That may work fine for you, but I am an American living in England. I have US keyboard layout, spell "color" without a 'u', and otherwise prefer an en_US locale. The only thing that changes for me is the default paper geometry in printers I use.

If LC_PAPER were honored more widely as an override, I think that would be the correct solution.

In Firefox 5, this problem seems to be worse than before.

1. I support a small architecture practice with 40 workstations on Windows (XP SP3).
- Due to their CAD package requirements, the OS cannot be changed (at least not in the near term).

2. The Firefox printer preferences dialog under Windows does *not* allow the paper size to be set at all.

3. The "native" printer preferences dialog under Windows *does* allow the paper size to be set, but the values are ignored by Firefox.

**Note: When the native printer setup dialog is called up from Firefox, it (wrongly) shows the printer page size to be Letter (it is actually set to A4). If I change it to A4, then the setting is actually shown as "A4 (97%)" indicating that the page will be reduced to fit. If I print with this setting, the output is the same (wrong).
--If, in the native print setup dialog, I go to the "printer settings", the page size there is also set to Letter; if I change that to A4, and then return to the print settings, then A4 becomes "A4 (100%)". If I print with these settings, the outputut is the same (and still wrong).

4. Under Firefox 2.0 (2.0.0.1) (on Windows), I successfully worked around the problem using "about:config" and manually editing all the printer page_size settings by hand.
- This worked.

5. Under Firefox 3.6 (3.6.12) (on Windows), the about:config workaround does *not* work - Firefox ignores any changes I make to the page_size_* settings, and in fact changes them back whenever I print to that printer.

6. Under Firefox 5 (5.0) (on Windows), the print_paper_* settings no longer exist in about:config.
- I have tried using "native" print setup window, and the values are always ignored.

I have a generated HTML page (timesheet report) that fits almost exactly on 2 A4 pages, but Firefox *always* renders it using Letter size, causing the bottom of the first page to be printed at the top of the second page; the content of the second page to start half-way down the second page; and the bottom of the second page to be truncated and not printed at all.

7. Google Chrome can print the same report perfectly.
- Sadly, this is my current workaround.

8. Interestingly - if I render the report in Firefox using IETab, then the pages print correctly as well.
--When I do this, the "Print Preview" window is different (it comes from IE); the printer preferences dialog is the same native dialog, but it shows the (correct) value of A4 by default, rather than Letter as it does when that same dialog is called up by Firefox.

This problem has been around, in some form, since Firefox 0.9.something, and it still exists. The indications are that there is no simple fix or patch that will correct it.
Perhaps the solution would be to take an existing open-source printing sub-system that works, and integrate it into both Firefox and Thunderbird?
The printing system from OpenOffice seems to work correctly on all platforms...

Cheers!
Nik

Best file a separate bug, thanks Nik.
This bug is about the Linux implementation while you are seeing a problem on MS Windows. Fixing this bug will not fix your issue.

(In reply to comment #71)
> Best file a separate bug, thanks Nik.
> This bug is about the Linux implementation while you are seeing a problem on
> MS Windows. Fixing this bug will not fix your issue.

Ah, ok. I was trying to avoid bug duplication...

Cheers!
Nik

I just did a new installation of Xubuntu 11.10, and then upgraded all the packages. The resulting Firefox version is 11.0.

I changed the contents of my /etc/defaults/locale file to

LANG="en_GB.UTF-8"
LC_TIME="en_DK.UTF-8"

then logged out and back in again. Now, when I print a page from Firefox, A4 is the paper size used, which is correct, but when I do a print-to-file, the default paper size is still letter. So this bug has not yet been completely fixed.

By the way, it's coming up on the bug's tenth birthday. Should we get together to buy something nice for it, what do you say?

Happy belated tenth birthday, dear bug!

In firefox 20.0, print to file defaults to letter. If I change this to A4, the PDF file on disk is still marked as size Letter. So various PDF readers assume it's Letter.

in print-to-file I first have to select a different paper size (any different paper size), then re-select A4, then I get A4 paper size in the .pdf. Otherwise I get letter.

printer_Print_to_File.print_paper_name=iso_a4

I have just followed the procedure of;

1) Download Firefox-24.0 English(UK) version for Linux
2) Download Firefox-24.0 English(UK) version for Linux again and compare just to be sure I didn't accidentally get the wrong one
3) Check environment and observe LANG=en_NZ.UTF-8
4) Check printer settings and see that default paper size is A4
5) rm -rf ~/.mozilla so there are no previous settings.
6) As root, rm -rf /opt/firefox and extract the one I just downloaded
7) as normal user again, run firefox and get the usual first-run page
8) about:config and search for paper_size

Observe that paper size is letter.

There is nothing on my computer that suggests it should be using letter, and no other program that I ever print from has EVER decided that the paper size should be letter. Only firefox gets this wrong. It's been getting it wrong now for well over ten years.

I like everything else about firefox except for this one infuriating bug.

This bug was first filed in 2002. It's now 2013. I've just upgraded to Firefox 24.0 on all my machines and my default paper size has, once again as it does every upgrade, reverted to the US_Letter papersize.

I live in the other 96% of the world that uses A4 paper, so every time I try to print from Firefox I get an error message on my printer.

OpenOffice and Libreoffice get the paper size right. GIMP gets the paper size right. Inkscape gets the papersize right. Abiword gets the paper size right. Gedit gets the paper size right. Tuxpaint gets the papersize right. EVERY OTHER program I use under any distro of Linux manages to correctly determine that I use A4 paper and doesn't give me any problems.

But not Firefox.

Firefox defaults to US_Letter. Even though my printer is set for A4. Even though my language is en_NZ. Even when I've manually changed ALL of the defaults back to A4 under about:config it still bloody-mindedly sets everything back to US-Letter every singe time there's some minor point-update of Firefox.

Firefox is the ONLY program that does this.

And it's been doing it far too long.

Pleas, for the love of Free Software, FIX THIS BUG.

I have submitted a duplicate and have been following this bug for years, saddly seeing no resolution at all. Some stuff must be made clear:

Paper size names are surely locale dependent ("Letter" in the US is "Carta" in Brazil), but the default value for the paper size is NOT. It is determined by the host operating system, i.e., the software component which is responsible for handling the printers and their queues. Any default value provided by Firefox, anywhere, is WRONG. Please find every line setting a default value and get rid of it.

I have not noticed this bug acting for quite a while in Windows and Mac OS, so this is clearly a platform independent feature which which was corrected the wrong way, probably in the platform dependent module. The linux module should get this values from cups, and that's it -- why on earth does 'letter' keeps popping up? Where does this value come from? Please get rid of it, I already abandoned Firefox for any printing in my Linux boxes, and I am on the verge of abandoning it whatsoever, just because of this stupid little bug which persists for more than a decade.

I cannot even find a place to buy letter-sixed paper if I needed to. It doesn't exist in Brazil, although some weird legal sizes are still used in some time-shifted places like notary offices and advocacy firms.

Weather websites are smart enough to tell I'm im Rio de Janeiro, but show temperatures in Fahrenheit and wind speed in miles/h. My new GPS app knows I'm im Brazil but shows distandes in miles and yards. My music editor (made in Europe!) gets the paper size right, but still defaults margins in inches, and worst: when I change them, they get rounded to the nearest inch fraction, so I keep getting 2.98 mm instead of 3.00 ! How an European software chooses to use inches inside it is beyond my understanding. This must have something to do with (very old) development frameworks.

Firefox should not be this dumb, and specially not in a internationally freely distributed OS like Linux.

Please do something. Let us get rid of all US medieval defaults, they're like a curse.

I completely agree with the last two commenters. This bug is getting beyond ridiculous. It is an embarrassment for Mozilla. Just fix it, already.

Well the whole situation is very complex, the other platform code is more or less broken too.
Bug 629500 sums the whole situation quite good and looks like a welcome refactor of the whole code base, maybe it will land in the next years? Feels like gecko/firefox printing is stuck in IE6 age...

I'm also annoyed that every firefox i run have the letter as default page size... and of course, one only discovers this after trying to print and nothing show up on the printer.

If in the past, print was little used, with the PDFjs, people start to print a lot more from firefox, making this issue more important.

If this can not be "fixed", at very least remove the default, leave it BLANK... on first printing, ask what paper size one wants... is not as friendly as a default, but having a broken default, trying to print and getting nothing is even worst. Most people will never know that the problem is the wrong paper size and don't understand why they don't have any printout.

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

Actually, while the windows version works better, it is screwed too, specially on unusually paper sizes and margins.

The main problem with "letter" is, that the gtk code part can't understand ps paper names, and the ps paper names doesn't understand iso_a4.

The right solution would be to drop the whole thing and query printer and paper names directly via ipp or use only gtk code and throw the old cups lib and ps based query solution.

Considering the other bug #629500 is stuck as well.
My solution will be my own private inhouse addon as can no longer wait for a solution.
The win32 version works more or less, except CSS2 Margins are still broken.
For the linux version I plan to to use a ipp based solution or directly accessing cups via js-ctypes.

Accessing CUPS via socket and ipp protocol, query paper sizes, create a postscript file and send it directly should be a more future proof technology. Technical that should work on OSX and if you have the right url with any ipp aware network printer, but that isn't my goal.

This bug is not half as bad now that the fix for bug 446041 provides that
print.print_paper_* prefs (once they exist) will override
print.postscript.paper_size.

The print.print_paper_* prefs will record the previous setting, but this will
only be different from print.postscript.paper_size if the value is been
changed in the page setup.

There is also much code here that can be removed and so make the use of
different prefs somewhat less confusing.

Created attachment 8620681
remove ununsed nsIPrintSettings::printCommand and print_command prefs

These was used only to write to and read from each other.

Created attachment 8620682
use GTK default paper size and orientation

In the nsPrintSettingsGTK constructor, gtk_paper_size_new(nullptr) gets the
system default paper size from the locale and gtk_page_setup_new() sets
default orientation to portrait.

These are subsequently overridden by prefs if any have been saved from
a previous nsPrintSettingsGTK.

Created attachment 8620683
remove print(|.<modulename>)(|.printer_<printername>).filename pref reading code

There are no default pref values, and even if some have been set, the value
is subsequently overridden by the print.print_to_filename pref, which exists
if saved from a previous nsPrintSettingsGTK.

Created attachment 8620684
remove meaningless GetPrintMethod()

Created attachment 8620685
part 5: remove ununsed plexName colorspace resolutionName and downloadFonts

This was only used to write to and read from otherwise unused preferences.

Comment on attachment 8620682
use GTK default paper size and orientation

Review of attachment 8620682:
-----------------------------------------------------------------

So with this patch, do we still remember the user's paper size in some way? How?

Comment on attachment 8620682
use GTK default paper size and orientation

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #89)
> So with this patch, do we still remember the user's paper size in some way?

Yes. The code removed here was not reading user's prefs. Those prefs were never saved.

> How?

(In reply to Karl Tomlinson (ni?:karlt) from comment #85)
> These are subsequently overridden by prefs if any have been saved from
> a previous nsPrintSettingsGTK.

This happens in nsPrintOptions from InitPrintSettingsFromPrefs(), called after
InitPrintSettingsFromPrinter().

https://hg.mozilla.org/mozilla-central/annotate/9ebd530c5843/widget/nsPrintOptionsImpl.cpp#l542
https://hg.mozilla.org/mozilla-central/annotate/9ebd530c5843/dom/base/nsGlobalWindow.cpp#l7011

Created attachment 8621437
part 4: remove meaningless GetPrintMethod() v1.1

Also removed a now-unused nsresult and a repeated argument sanity check.

Comment on attachment 8621437
part 4: remove meaningless GetPrintMethod() v1.1

Review of attachment 8621437:
-----------------------------------------------------------------

Delicious!

https://hg.mozilla.org/integration/mozilla-inbound/rev/f3661245688b
https://hg.mozilla.org/integration/mozilla-inbound/rev/d799f63ed244
https://hg.mozilla.org/integration/mozilla-inbound/rev/c96721303125
https://hg.mozilla.org/integration/mozilla-inbound/rev/86f5957e60f9
https://hg.mozilla.org/integration/mozilla-inbound/rev/78349b2422e8

https://hg.mozilla.org/mozilla-central/rev/f3661245688b
https://hg.mozilla.org/mozilla-central/rev/d799f63ed244
https://hg.mozilla.org/mozilla-central/rev/c96721303125
https://hg.mozilla.org/mozilla-central/rev/86f5957e60f9
https://hg.mozilla.org/mozilla-central/rev/78349b2422e8

This appears to have broken printer settings on Windows with e10s enabled (bug 1176141).

(In reply to Brian Birtles (:birtles) from comment #95)
> This appears to have broken printer settings on Windows with e10s enabled
> (bug 1176141).

My bad, this bug has nothing to do with it.