Bug 445610 (ff-print-letter)

You have the wrong system locale.  What does 'cat /etc/sysconfig/i18n' say?

Hello,

It says:

LANG="ro_RO.UTF-8"
SYSFONT="latarcyrheb-sun16"

which, on my knowledge, is correct for Romanian.

BTW, there is no such thing as "letter" paper available in Romanian
market/culture. We *only* use A4 (or A3) for usual office printing, so this must
be the *default* if system is set to Romanian.


Regards,
Răzvan

And the locale information is correct:

$ LANG=ro_RO.UTF-8 locale -k LC_PAPER
height=297
width=210
paper-codeset="UTF-8"

So it must be that the queue was created with Letter as the default page size
for some reason.  Use system-config-printer (System->Administration->Printing)
to change the default page size for that printer to A4.

How did you add the queue originally?

Hello,


Under System -> Administration -> Printing -> Canon IR2020i -> Printing Options
-> Page size I *do* have "A4". Also, "Media source" is set to "Printer default".

The driver is plxmono.

Regards,
Răzvan

Please attach the /etc/cups/ppd/queue.ppd file for the queue.

Created attachment 304930 [details]
The .ppd file for the Canon IR2020i, as requested

Another unclear fact that occurs from time to time is that printer ignores the
setting for the number of copies: despite asking for X copies in the printing
dialog, the printer only prints one copy.

Thanks,
Răzvan

I just tried sending a test page to a queue using that PPD, and the resulting
PXL file was A4 (verified by examining output with GhostPDL).

The real problem is with Firefox, which is sending US Letter pages even in A4
locales -- and even when the destination printer (with default page size A4) is
selected in the Page Setup dialog.

Other applications that use this dialog (e.g. evince) don't have this problem,
so it seems to be specific to Firefox.

There may be two problems:
1. Firefox defaults to US Letter page size even when the locale indicates that
A4 should be used (e.g. en_GB, ro_RO -- anything with LC_PAPER showing 210x297).

2. Firefox still selects US Letter page size even when a printer is selected in
the Page Setup dialog whose PPD has 'A4' set for PageSize (e.g. set using
system-config-printer in the Printer Options dialog).

firefox-3.0-0.60.beta5.fc9

(In reply to comment #7)
> Another unclear fact that occurs from time to time is that printer ignores the
> setting for the number of copies: despite asking for X copies in the printing
> dialog, the printer only prints one copy.

Razvan, please file a separate bug report for this.

Did it, please see bug #446177.

Regards,
Răzvan

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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

Try to enter "a4" into /etc/papersize. More info with "man papersize"

Sorry, but this doesn't make any sense:

1) See the output of this command
[matej@viklef firefox-3.0.1]$ find /usr/lib/firefox-3.0.1/ -perm /111 \
    -exec ldd '{}' 2>/dev/null \;|grep pap
[matej@viklef firefox-3.0.1]$ 

How could possibly firefox use libpaper library when no library in
/usr/lib/firefox* links against it?

2) When trying with the empty file /etc/papersize, I got working firefox print
dialog (note that firefox3 uses gnome printing subsystem, so that it makes a lot
of sense, that paper has been correctly guessed, because Gnome applications
generally work well in this aspect.

I have then tried to set /etc/papersize to intentionally incorrect format b4,
and yes still firefox happily suggested printing of the file in A4.

Any more ideas?

(In reply to comment #13)
> Try to enter "a4" into /etc/papersize. More info with "man papersize"

This is nothing to do with it.  The *selected printer* already tells us which
paper size it expects by default in its PPD; we should use that as the default
setting in the dialog, regardless of *any* local setting, either in the locale,
or from libpaper, or from anything else.

Seems like I also have hit this bug. I am running firefox in pl_PL locale, cups is set to a4 but for some reason (even if told in page setup to print on a4) it keeps changing the print.printer*.print_paper_* entries in about:config to the ones corresponding to legal. This is quite a major problem since it for example needlessly splits my digital banking documents into two pages, screwing up the formatting.

I've now upgraded from Fedora 9 to Fedora 10 rawhide (with all online updates as of October 18, 2008) and I'm able to confirm that the bug is still present.

Regards,
Razvan

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The comment about the discovery via the PPD is rubbish as if you goto the file -> page setup option you will see the sage printer dialog that you see for evince that asks "Format for: Any Printer" so it has a non-printer specific size option which is wrong by default for the UK too

Regardless of that, when you select a printer in the Print dialog the application knows *at that point* what the page size will be.

The Page Setup option only really makes sense when printing to a file -- in that case, the physical printer is not known at the time of print.

a quick and dirty solution:

1. open about:config
2. change print.postscript.paper_size to iso_a4 (by default firefox uses us_letter regardless of locale settings)

(In reply to comment #19)
> The comment about the discovery via the PPD is rubbish as if you goto the file
> -> page setup option you will see the sage printer dialog that you see for
> evince that asks "Format for: Any Printer" so it has a non-printer specific
> size option which is wrong by default for the UK too

Could you please print to PDF, run pdfinfo (from the poppler package) on the resulting PDF, and paste the output here, please?

I think I might have some additional info regarding this issue. It seems that if you start printing by file → print, the paper size settings are respected. When, on the other hand, printing is initiated by javascript (?), the paper settings are ignored and letter is used.
A possible example can be found here (the site is in Polish):
1. Go to http://www.mpk.lodz.pl/rozklady/start.jsp
2. Click any number from the top (these are just bus and tram timetables)
3. Click any street name (this should bring up a timetable for a given stop)
4. Click “drukuj” (print)
5. Print to file

The resulting pdf will be of US letter size. When you hit ctrl-p while on the same page and print to file, proper A4 size will be chosen.

pdfinfo for javascript printing:
Creator:        cairo 1.8.0 (http://cairographics.org)
Producer:       cairo 1.8.0 (http://cairographics.org)
Tagged:         no
Pages:          1
Encrypted:      no
Page size:      612 x 792 pts (letter)
File size:      63335 bytes
Optimized:      no
PDF version:    1.4

pdfinfo for normal printing:
Creator:        cairo 1.8.0 (http://cairographics.org)
Producer:       cairo 1.8.0 (http://cairographics.org)
Tagged:         no
Pages:          1
Encrypted:      no
Page size:      595.3 x 841.9 pts (A4)
File size:      63346 bytes
Optimized:      no
PDF version:    1.4

The other place where I'm seeing this issue is my digital banking site, but I obviously can't give you access to that :)

I can confirm that when using the javascript command to print. The Page settings are ignored and defaults to Letter (which kills our printer :( )

We are using Zimbra desktop too, which is a Mozilla Prism application it's giving the same problems. So it's probably not related to the Redhat builds but upstream related?

Forget to tell, the first time firefox start it's ignores the LC_paper locale setting completely. But after setting it to A4 it's being saved for the next time. But when using print function thru javascript it's being ignored ....

(In reply to comment #24)
> We are using Zimbra desktop too, which is a Mozilla Prism application it's
> giving the same problems. So it's probably not related to the Redhat builds but
> upstream related?  

Yes, you are right ... and sorry for not stopping this earlier. This is duplicate of bug 133658 (which is closed as upstream against https://bugzilla.mozilla.org/show_bug.cgi?id=144625

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

and the correct upstream bug is now https://bugzilla.mozilla.org/show_bug.cgi?id=147419