Hi folks, This is definitely not a cups-pdf issue. Some comments from the preceding discussion:
1) a2ps is 8-bit only. It is unlikely to support UTF-8 properly
without a full rewrite, from what I have read. Upstream don't seem
to have this as a high priority, so IMO we need another tool which
can cope with UCS.
For full unicode support, I've seen that "paps" might be a good
text filter. It uses FreeType and Pango to render PostScript. I
haven't tried it yet, but it might be wrapped as a more
sophisticated texttops replacement.
2) The bug is possibly in the texttops filter. It gets the text
encoding from the CHARSET environment variable, but I can't see
where in the CUPS sources this is set. It appears to be set to
UTF-8 by default, but I haven't yet found a way of overriding this
with lpr -o options.
This might be related to the IPP_TAG_CHARSET job option, but I
haven't yet found where or how to set it.
Given that it's most likely already set to use UTF-8 (Set
LogLevel=debug in cupsd.conf), you should get similar to this in
the error_log:
D [01/Oct/2006:13:58:44 +0100] [Job 310] envp[17]="CHARSET=utf-8"
but it might not be doing a good conversion to Postscript. If you
can save the output from texttops, that would be useful. Set
FileDevice Yes
in cupsd.conf, and set up a printer with a file:// URI, for
example. If you could attach the output of an lpr command using
this, that would be useful.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
pgpmUEV6psBMq.pgp
Description: PGP signature
