[bug #45859] Problems viewing Latin-1 Info file when Latin-1 locale is not installed

[Gavin D. Smith]

URL:
  <http://savannah.gnu.org/bugs/?45859>

                 Summary: Problems viewing Latin-1 Info file when Latin-1
locale is not installed
                 Project: texinfo - GNU documentation system
            Submitted by: gavin
            Submitted on: Tue 01 Sep 2015 08:25:42 PM GMT
                Category: None
                 Release: 
                Priority: 5 - Normal
                Severity: 3 - Normal
              Item Group: None
                 Privacy: Public
             Open/Closed: Open
             Assigned to: None
         Discussion Lock: Any
                  Status: None

    _______________________________________________________

Details:

I tried viewing a Latin-1 Info file on a remote host via SSH, in a Latin-1
terminal emulator, but because the remote host didn't have a Latin-1 locale
installed, it wasn't possible to view it properly. This wasn't a problem with
info 5.2 which just sent through the bytes in the file directly to the
terminal.

(The file happened to be gpcs-de-4.1.info, the GNU Pascal Coding Standards in
German.)

I'm not sure exactly how to proceed with this. Blame it on the locales being
missing, and leave it unfixed? Or adapt somehow?

One thought is to heed an environment variable, possibly INFO_CTYPE, or maybe
even the pre-existing LC_CTYPE, which would specify what character encoding
the user wants the output in, the locale settings notwithstanding.

The iconv function appears to support more encodings than are available in
locales. So with the problem I had, using the "C" locale allowed a conversion
from Latin-1 to ASCII (via UTF-8). To solve this, the iconv function would
have to be used instead of functions like mbrtowc, which depend on the current
locale settings. If we didn't have the wchar_t values of characters, then we
couldn't use functions like iswprint or wcwidth (which only really matters for
Info files in some Asian languages --- I guess they wouldn't be in Latin-1 in
the first place). I guess what could be done is first convert with iconv to
the current locale's encoding, use iswprint etc., and for output, convert the
character on to the encoding that the user specified --- that's more
complicated, though. So using iconv to iterate over characters in a different
encoding from that in the current locale may be possible, maybe as a fall-back
if the available locales are deficient, and possibly with slight reduction in
functionality.

I would be careful about possible solutions that just send on bytes to the
terminal with no conversion. I haven't tracked down which ones they are, but I
know there are some bytes in the 0x80-0x9f region (the "C1" set) which can
ruin the display (even running "reset" didn't seem to help), for example in a
UTF-8 dir entry in a merged dir file.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45859>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/