Description of problem: Just a reminder for you... Anyway the whole paper size is a pretty large issue I think both for application developers since they cant agree on one place to get the papersize info, lc_messages, lc_paper, /etc/papersize etc.. And the end users, like for I have the system language set in EN_US yet here in Iceland we use A4 etc.. I'm not even sure if where it sets mine is it the servers default, the network servers default. my locale the apps them self??.. But possible we can bypass it at least with cups, any thing that would pass through cups would be forced to certain media size... There's an option in cups about DefaultLanguage and if i'm not mistaken adding the line there ( which is not there by default ) and changing that line from US.EN to US.GB ( Letter to A4 ) or visa versa should do the trick So creating an ask for default Media size box, that ask the user to choose either letter or a4 and the only thing it would do would to add that line and/or change it.. ( correct me if i'm wrong about the media size and the DefaultLangue ) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: And one paper joke to go with it.. http://ars.userfriendly.org/cartoons/?id=20050717
Yes, DefaultLanguage could be used like this, but it is much better to set the system locale correctly. For the common case of needing the system locale to correspond to the language and locality of the physical location of the user, system-config-language can be used to set this. For the less common case of wanting the system locale to be different from the language spoken, some other locale tool may be required, although your suggestiong of altering DefaultLanguage might be a stop-gap solution. What I would like to do is add a screen to the troubleshooter (i.e. the dialog you get from Help->Troubleshoot) to find problems that might be caused by the system locale being incorrect, and suggest solutions. There is a question mark over how to identify situations where the system locale is incorrect and causing a problem. One possibility would be to make it compare the system locale (from /etc/sysconfig/i18n) to the current locale (from the user's environment) -- if they use different paper sizes, this might suggest a cause for problems. Another possibility would be to compare the system locale (from /etc/sysconfig/i18n) to a chosen print queue's paper size. As for possible solutions, it could suggest selecting System->Administration->Language from the menu (hopefully system-config-language) is installed, or we could even have something like this: [British (A4) v] [Set Print Locale] American (Letter) ...
I think your assumption is wrong, you seem to be building upon the fact that the end users has his system locale incorrectly configured while I believe it's the other way around, user(s) choose to have their OS installer default language ( which in our case is en_us ) and only alter their keyboard layout. On top of that, whether my assumption is correct or yours, we have mobile users, users that travel from one continent to another which might use different media sizes. For example let's say you would travel here to Iceland to hold a lecture in developing user application and you need to printout some handouts you would not want to alter your system local on your laptop just to be able to print on A4 now would you? There have been some far out suggestion tying the media size to "time zone" which is just absurd ( At least as I see it ). If I was to travel around the world, I would be keeping my laptop on my time zone while using an clock applet the supports multiple time zones. The main problem here is that application should not be getting their paper size at all from system local. Application should either get their overall printer settings from their printer back end ( or their window system which then gets it settings from the OS's printer backend ), which in our case is cups or they should just send raw print job to the printer backend and he takes it from there. Printer backend ( arguably ) could take his default settings from system local. If you are going to create a troubleshooting wizard you build that wizard upon cups and printer related problems until everybody can settle on one place to get their printer settings from. ( Which should be cups in our case ) Trouble shoot the printer it's self (locally or network connected printer which you can log onto, check for ink, paper, firewall the usual stuff ). if its a network connected (cups) print server ask or offer to send an email to the printer admin that he has incorrectly configure the print server with text on what would be the correct way of setting up his printer. For example one classical could not retrieve ppd file from print server, up pops an msg box that offers to send the printer admin email which contains an direction on how to setup CUPS-Get-PPDs directive. Indeed there is an question mark over how to identify situations where the system locale is incorrect and causing a problem. Trying to troubleshoot system local brings in to many variables, on top of my head. A) Application developers cannot agree that getting their media size from the system local is the right thing to do. ( And I aggree and say get it from the printer backend ). Hence the risk is the troupleshooter suggest to the end users that he should start messing with system local settings and and he ends up messing up printing settings for other applications and his system local. B) Which one are you going to check and ask the user to change? The systems default or his? C) B - with more then one user on the system. D) B and C with different language settings.
I think there are several issues getting muddled into one here. Regarding the troubleshooter -- this application already exists. Try Help->Troubleshoot from the main system-config-printer window. This bug report is a reminder to me to add in some locale checks to that troubleshooter -- at the very least, reporting the system locale in its debug output. There are several types of "default page size", and it is important not to get them confused: 1. When a USB printer is connected, the queue that is automatically created for it is given a value for its PPD's DefaultPageSize attribute. This is the "default default": the default value that new print queues get for their default page size. CUPS sets this based on the system locale, i.e. the locale set in the environment of the cupsd process. (This is the default I have been talking about in previous comments.) Note that locale is absolutely the correct mechanism for this. Locale is not just about language, but also numeric display, currency, paper size, etc. 2. A particular CUPS printer queue has a default page size given by its PPD's DefaultPageSize attribute. This can be overridden by the application when it submits a print job, and some printers can select different input trays depending on the required page size of a particular job. This page size will be used when converting some file types to printable content: for example, when printing images directly. It may even be used to convert all jobs to the correct page size if only one is available. 3. When an application creates a new document, it may have an inherent page size associated with it: for example, which page size do you get when starting OpenOffice.org Writer? Additionally, some applications may allow a new document to be formatted for a particular printer, and fetch the page size and margins from its PPD. So, in answer to your question about mobile laptops: if someone has a laptop with a default system locale of en_US (i.e. US Letter paper), and connects it to a network in an A4 locale to print a document they have to a network CUPS queue, that queue will convert their US Letter pages to A4 size. If they want to print to (for example) a Windows print share, they can create a new queue for this but it will have a default page size of US Letter (due to default number 1 above). So as the next step they can just change the default page size of that queue (i.e. default number 2 above) to A4. If they want to create a new document and have it use the correct page size, they really need to set their locale to be correct, or use libpaper, or some other mechanism -- whichever they choose, that's outside the scope of CUPS and system-config-printer. My own opinion is that the locale should be used (the user can override the system locale for this), since that is precisely the kind of thing it is for.
The troubleshooter now reports locale settings in the diagnostic output, but does not suggest any changes to the user.