[pdf-devel] Re: Comments to the Encoded Text API

[Aleksander Morgado]

>    The easiest way to handle these host encoding conversions in GNU/Linux
>    is the wchar_t type and multi-byte functions. The problem is that
>    there is no way to get conversions to/from encodings different to the
>    one specified in the user's locale. To get those other conversions
>    either the locale should be changed in runtime (not a good idea) or
>    other utilities like GNU libiconv should be used explicitly.
>
> Hmm. It is not a problem to use GNU libiconv if we are running in a
> GNU system, but this would be a problem if running in a POSIX
> environment without GNU libraries installed.
>
>    Why not just detect the host encoding once, when the program
>    starts, and use that single encoding in all the operations
>    involving host encodings (get/set)? That would be perfect to be
>    able to use wchar_t and multi-byte functions, with no need to call
>    iconv.
>
>    The approach given in the Text Encoding API is quite similar to the
>    way things are done in Windows OS, where you first have to ask for the
>    specific ANSI Code Page being used (GetACP) and then use that
>    identifier in MultiByteToWideChar or WideCharToMultiByte functions.
>    The equivalent two-step approach in GNU/Linux would be done with
>    nl_langinfo (to get the name of the encoding set in the locale) and
>    GNU libiconv for the conversions, so it's possible, but not sure if
>    it's really needed.
>
> So the problem remains for POSIX systems, isnt it?.
> What do people think about this?
>

Well, maybe I should have been talking about 'iconv' and not 'GNU
libiconv'. 'GNU libiconv' is just an implementation of the 'iconv' API
for systems including GNU libraries (it is supposed to be highly
portable, anyway). The 'iconv' API is part of the Single UNIX
Specification (SUS) standard, so should be implemented in most UNIX
systems.