[cups.bugs] [HIGH] STR #2537: followup of #2533

[Jerome Alet]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

If CUPS only supports the ascii and utf-8 character encodings, as specified
in your answer to #2533, then it should immediately reject all print jobs
submitted from a locale with a different charset.

This is not the case, so we end up with CUPS answering badly encoded datas
to properly endoded IPP requests which explicitely request an answer
encoded in the UTF-8 charset.

If you let CUPS accept bad charsets in job submission queries, like it's
done at least in 1.2.7, then there's no way to be able to reuse jobs'
titles in any third party application or even in CUPS itself in a
consitent way : their encoding is lost as demonstrated in #2533.

Of course the correct solution would be for CUPS to immediately translate
the client's input characters (e.g. title) from the client's charset to
UTF-8 at job submission time. Then CUPS could only deal with UTF-8 for ALL
other queries, and let lp* commands (or any other client software)
translate UTF-8 back to the client's current locale if needed. Why is this
not done this way ?

Link: http://www.cups.org/str.php?L2537
Version: 1.2.7