Description of problem: When printing plain text files, CUPS lpr tries to determine the charset of the file from the environment variables LC_MESSAGES (LC_ALL locale should be used instead) and LANG, and even the parsing of the LANG and LC_MESSAGES is incorrect. The value from the system locale LC_CTYPE should be used instead, i.e. lpr should call setlocale(LC_ALL, ""); char *charset = nl_langinfo(CODESET); Another problem is that they use the fixed list of charsets, and search in it by case-insensitive compare, while the compare should be both case-insensitive and alphanumeric-only - i.e. both "iso-8859-2" and "ISO8859-2" (note the missing hyphen and different case) should refer to the same charset. Version-Release number of selected component (if applicable): cups-1.1.20-11.1 How reproducible: 100% Steps to Reproduce: 1. create a text file in ISO-8859-2 encoding 2. export LC_CTYPE=cs_CZ 3. run "locale charmap" to verify that the charmap is ISO-8859-2 4. lpr text_file.iso8859-2 5. LANG=cs_CZ lpr text_file.iso8859-2 6. LANG=cs_CZ.ISO8859-2 lpr text_file.iso8859-2 7. LANG=cs_CZ.ISO-8859-2 lpr text_file.iso8859-2 Actual results: only the last copy of the file is printed with correct characters Expected results: all four copies should be printed with correct characters Additional info: I have reported this upstream, so hopefully they will fix the problem: http://www.cups.org/str.php?L856+P0+S-2+C0+I0+E0+Q
Created attachment 113073 [details] text file containing all 4 CJK locale characters
Can you try the latest rawhide? Things of handling i18n printing is improved there.
The problem is still here (cups-1.2.1-18.i386). It is a bit different than before (worse, I have to say): - the "cs_CZ" locale now defaults to the UTF-8 encoding, so this test is not valid anymore. - with the other values of LC_CTYPE - cs_CZ.ISO8859-2 and cs_CZ.ISO-8859-2 it does not work either (LANG=C, so everything except LC_CTYPE is set to C). - when I set LANG=cs_CZ.ISO8859-2 or LANG=cs_CZ.ISO-8859-2, it works. So it seems that cups looks to some other category than it should. According to my two years old bug-report to the CUPS bug tracking system, it used to use LC_MESSAGES category instead of LC_CTYPE it should use. But I have verified (by setting LANG=C, LC_MESSAGES=cs_CZ.ISO-8859-2) that this is not the case. Feel free to request more info.
this somewhat seems to be relevant to Bug#197577. Though CUPS should looks at LC_CTYPE as the applications that relies on the locale usually does, and then LANG if it's not. paps - which works as the text plain filter for CUPS now - needs to support the document-charset attribute. after that, that may helps you too.
I think that document-charset is something that CUPS is meant to support itself, rather than the filters. I'll double-check upstream: http://www.cups.org/str.php?L1819
SJIS-type encodings have now been added (1.2.1-21).
looks like you are confused to close a bug. this bug is irrelevant to sjis at all. but if the way to specify the document encoding is documented somewhere or provide the certain way for that, this may be duplicate of Bug#197577 I suppose. or this complains that LC_CTYPE should works to detect the charset instead of LC_MESSAGES anyway, this bug should be still kept as a separate bug IMHO. then maybe retitling a bug would be better.
Reported upstream: http://cups.org/str.php?L1915
This seems to work fine here with 1.2.2-10.