[cups.general] Character set encoding names

Tim Waugh twaugh at redhat.com
Thu Aug 17 04:11:16 PDT 2006


On Wed, 2006-08-16 at 21:11 -0400, Michael Sweet wrote:

> > Can't we use the IANA names, so that the filters can use iconv_open()?
> 
> First, IANA provides both the ISO-defined names and non-ISO alternate
> names that have been registered with them.  We ONLY use the ISO names
> and make no attempt to track the original/alternate name that was used.

http://www.iana.org/assignments/character-sets lists Windows-31J, and
Windows-932 is not shown anywhere in the list.

> Second, locales generally don't follow IANA or ISO naming - think
> iso-8859-1 vs ISO8859-1, etc.  Since each OS vendor has adopted
> slightly different naming conventions, it is pretty much impossible
> to support every possible locale charset name - we can only address
> the common ones that have a corresponding ISO name we support.

Why not actually pass through the actual result of nl_langinfo(CODESET)
(or else the charset from 'document-format') from the front-end all the
way through to the filter?

> Even then, you should not depend on CHARSET to provide you with the
> character set - that exists only for plain text files, and even then
> it is a guess based on the user's locale.

Eh?  Are you suggesting it's better to guess character set encoding
based on the file's *content*?  You must know that isn't an even
slightly reliable method.

If the job has been submitted with
'document-format=text/plain;charset=sjis', you have been explicitly told
by the user what character set to interpret the file as.  But you say
the filter on the other end shouldn't rely on that?

As for 'that exists only for plain text files' -- my example is for a
text/plain filter.  The filter is never going to see anything but
text/plain.

> ALL messages sent to stderr MUST be in UTF-8

Completely different issue, not related.  I'm talking about input not
output.

> (If you do supply your own text filter, make sure you support ALL of
> the standard CUPS options!)

Already does thanks.

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cups.org/pipermail/cups/attachments/20060817/ed49d76c/attachment.bin>


More information about the cups mailing list