Re: encoding for PostScript output

[Werner LEMBERG]

> Essential for reproducing the problem seem to be the locale
> settings.

This is impossible.  An unmodified groff version doesn't handle
locales at all (except that it sets the `LC_NUMERIC' locale to `C' to
get correct PS output).

> As can be seen in the example file, it is in the ISO-8859-1 encoding,
> and the error occurs only if groff is called in an ISO-8859-1 locale,
> in my case with LANG=de_DE.ISO-8859-1.

For me this works without a problem.

> The error can also be seen when putting the file into UTF-8 encoding
> and running groff in the de_DE.UTF-8 locale.

Uh, oh, this can't work at all since groff doesn't support UTF-8 input
encoding.

My conclusion: You use the Debian version of groff which includes a
patch for Japanese support.  It seems that this doesn't work properly
for you.  I don't support this Japanese extension for various reasons
-- you should file a Debian bug report (or rather look up the bug
database whether it has been reported already).

My suggestion: Get the current CVS version of groff and compile it by
yourself.  Or perhaps there is a command to deactivate Japanese
support.

> As far as I understand latin1.tmac, it redefines the special
> characters if they are not already available.  But this purpose gets
> defeated when using a file encoded according to the locale groff is
> running in because then the characters are already defined.

latin1.tmac simply defines an input encoding.  If the file is in
latin-1 encoding, everything should be fine.

> By the way, if the text in the file starts with a guillemet
> character, troff core dumps, but that is another bug, isn't it?

I can't repeat this either (but I'm actually using the current CVS
version).  Again, I suspect a bad interaction with the Japanese
support.


    Werner