Re: [Groff] German Umlaute, ISO-8859-1, postscript.

[Bruno Hertz]

On Sun, 2004-05-16 at 18:54, Alejandro Lopez-Valencia wrote:

> 
> ISO-8859-1 and UTF-8 share the same bytecodes, that's by design.
> 
> First off, I'd try calling vi in a wrapper script[1] that set the locale 
> settings to see if it obeys the encoding settings. And use LC_ALL instead 
> of LC_TYPE.
> 

Hi Alejandro

phew, looks like I'm done. Took some time since I never actually looked
into the uni-/multi-byte stuff too deeply. For the records, things went
as follows:

(1) Redhat 9 has multibyte support enabled by default. This is set
in /etc/sysconfig/i18n where my original entry was LANG="en_US.UTF-8" .

(2) Obviously, by setting LANG and LC_CTYPE just in my shell I sort
of created a mixed environment in which umlauts typed on my keyboard
still got into the file as 2 byte sequences. With LANG=en_US in my
shell, groff -Tps accordingly and correctly interpreted those as two
distinct characters.

(3) I then observed that with LANG=en_US.UTF-8 in my shell, groff -Tps
worked *correctly*, i.e. the umlauts came out correctly. Stupid me I
didn't try this in the first place.

(4) Conclusion: vim, groff and ggv are all multibyte aware and work
correctly with the default, untouched en_US.UTF-8 setting. That is,
I can enter umlauts directly in vim, they are stored as multibytes
in the file and come out correctly with groff in postscript. Gunnar
Ritter's vi however does *not* display mutlibyte chars correctly.
They appear as escape sequences.

(5) Hence two alternatives: either leave the default untouched and
work with vim, or enable a unibyte charset and work with Gunnar's
vi. I tried the latter by setting LANG="en_US" in /etc/sysconfig/i18n,
which seemingly selects the iso-8859-1 charset. After a reboot, just
everything worked correctly: umlauts typed into vi/vim were stored
as one byte as well as correctly displayed by all apps, *and*
groff -Tps produced correct postscript output.

So basically, all works as designed and it was just me fiddling
around too much while thinking too little :)

Sorry for the trouble, and many thanks again for your quick
help and support.

Bruno