Closed Bug 147419 Opened 23 years ago Closed 9 years ago

Printer paper settings should default to appropriate values for the user/printer

Categories

(Core :: Printing: Setup, defect, P5)

Product:
Core
Component:
Printing: Setup
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla41
Tracking Flags:
Tracking Status
firefox41 --- fixed

People

(Reporter: Markus.Kuhn, Assigned: karlt)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: intl, regression)

Attachments

(6 files, 1 obsolete file)

don't use PS prefs in gtk
(deleted), patch
karlt
: review-
Details | Diff | Splinter Review
remove ununsed nsIPrintSettings::printCommand and print_command prefs
(deleted), patch
roc
: review+
Details | Diff | Splinter Review
use GTK default paper size and orientation
(deleted), patch
roc
: review+
Details | Diff | Splinter Review
remove print(|.<modulename>)(|.printer_<printername>).filename pref reading code
(deleted), patch
roc
: review+
Details | Diff | Splinter Review
part 5: remove ununsed plexName colorspace resolutionName and downloadFonts
(deleted), patch
roc
: review+
Details | Diff | Splinter Review
part 4: remove meaningless GetPrintMethod() v1.1
(deleted), patch
roc
: review+
Details | Diff | Splinter Review
The default download binary of Mozilla 1.0rc2 for Linux comes with language setting en-US only and sets the printing page size at each invocation back to "US Letter". This is extremely disruptive for most users. The vast majority of printers (namely practically *every* printer outside the USA and Canada) is fed with international standard A4 paper. Similarly, the vast majority of users worldwide are used to think in millimeters, not inches, but the default margin settings in the print menu use inches. It is currently not at all obvious for a highly computer literate user how to change these settings. A non-North American user should never ever have to worry about the paper size. No changing to A4 should be necessary ever. Suggestion: Mozilla for Linux can trivially determine whether it was invoked in North America by looking at the standard POSIX locale environment variables. The default settings for printer paper and unit of measurement should be determined under Linux as in the following example code: #include <stdio.h> #include <stdlib.h> #include <string.h> /* LC_PAPER and LC_MEASUREMENT were introduced in a ISO/IEC TR 14652 draft */ int main() { char *units = "mm"; char *paper = "A4"; char *s; if (((s = getenv("LC_ALL")) && *s) || ((s = getenv("LC_PAPER")) && *s) || ((s = getenv("LANG")) && *s)) if (strstr(s, "_US") || strstr(s, "_CA")) paper = "Letter"; if (((s = getenv("LC_ALL")) && *s) || ((s = getenv("LC_MEASUREMENT")) && *s) || ((s = getenv("LANG")) && *s)) if (strstr(s, "_US")) units = "inches"; printf("Paper: %s\nUnits: %s\n", paper, units); return 0; } American users should (and with most distributions typically have) LANG=en_US set (often also with LC_COLLATE=POSIX to prevent ls changing its sorting order), so they will still get their special national 8.5x11" paper format configured correctly, without disrupting Mozilla printing worldwide, as it happens at the moment. Another idea is to include in addition to "en-US" also a language setting "en" to the default download version of Mozilla. "en" differs from "en-US" in that it applies ISO standards for default settings instead of US customary values. en-US: US Letter, inches, mm/dd/yy, am/pm en: A4, mm, yyyy-mm-dd, 24-hour time The default distribution shouldn't force users to use a locale setting (en_US) that differs so dramatically from international standards.
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?
Severity: normal → enhancement
Summary: Default printer settings set to US Letter and inches → Printer settings should default to appropiate values for the user
Keywords: intl
QA Contact: ruixu → kasumi
assign to katakai-san. please have a look. Thanks
Assignee: yokoyama → katakai
what's the status of this?
I've started working on this.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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?
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?
Blocks: 400305
Assignee: masaki.katakai → smontagu
Status: ASSIGNED → NEW
QA Contact: kasumi → i18n
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;)
Assignee: smontagu → sebastian.bronner
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 ;-)
Component: Internationalization → Printing: Setup
QA Contact: i18n → printing.setup
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.
Status: NEW → ASSIGNED
(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 ?
No longer blocks: 400305
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.
Summary: Printer settings should default to appropiate values for the user → Printer settings should default to appropriate values for the user/printer
@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.
Severity: enhancement → normal
Priority: -- → P5
See Also: → https://launchpad.net/bugs/10910
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.
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.
Depends on: 581789
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.
Attached patch don't use PS prefs in gtk (deleted) — — Splinter Review
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.
Attachment #500694 - Flags: review?
Paolo S added the following comment to Launchpad bug report 10910: 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 -- http://launchpad.net/bugs/10910
Attachment #500694 - Flags: review? → review?(karlt)
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 [details] [diff] [review] 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
Attachment #500694 - Flags: review?(karlt) → review-
Paolo S added the following comment to Launchpad bug report 10910: 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 -- http://launchpad.net/bugs/10910
Paolo S added the following comment to Launchpad bug report 10910: 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 -- http://launchpad.net/bugs/10910
Summary: Printer settings should default to appropriate values for the user/printer → Printer paper settings should default to appropriate values for the user/printer
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"
Nick Moffitt added the following comment to Launchpad bug report 10910: 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. -- http://launchpad.net/bugs/10910
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.
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?
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.
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.
Blocks: 947125
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.
Assignee: waschtl → karlt
These was used only to write to and read from each other.
Attachment #8620681 - Flags: review?(roc)
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.
Attachment #8620682 - Flags: review?(roc)
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.
Attachment #8620683 - Flags: review?(roc)
Attached patch remove meaningless GetPrintMethod() (obsolete) (deleted) — — Splinter Review
Attachment #8620684 - Flags: review?(roc)
This was only used to write to and read from otherwise unused preferences.
Attachment #8620685 - Flags: review?(roc)
Comment on attachment 8620682 [details] [diff] [review] use GTK default paper size and orientation Review of attachment 8620682 [details] [diff] [review]: ----------------------------------------------------------------- So with this patch, do we still remember the user's paper size in some way? How?
Attachment #8620682 - Flags: review?(roc)
Comment on attachment 8620682 [details] [diff] [review] 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
Attachment #8620682 - Flags: review?(roc)
Also removed a now-unused nsresult and a repeated argument sanity check.
Attachment #8621437 - Flags: review?(roc)
Attachment #8620684 - Attachment is obsolete: true
Attachment #8620684 - Flags: review?(roc)
Attachment #8620685 - Attachment description: remove ununsed plexName colorspace resolutionName and downloadFonts → part 5: remove ununsed plexName colorspace resolutionName and downloadFonts
Comment on attachment 8621437 [details] [diff] [review] part 4: remove meaningless GetPrintMethod() v1.1 Review of attachment 8621437 [details] [diff] [review]: ----------------------------------------------------------------- Delicious!
Attachment #8621437 - Flags: review?(roc) → review+
Regressed by: 1660527
Keywords: regression
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: