Re: Non-ASCII characters in @include search path

[Gavin Smith]

On Wed, Feb 23, 2022 at 09:52:21PM +0200, Eli Zaretskii wrote:
> > E.g. - UTF-8 Texinfo file, processed under KOI-8 locale on Windows,
> > accessing filenames named with UTF-16 filenames on Windows filesystem.
> > Then the UTF-8 filenames would be encoded to KOI-8, and then some file
> > access layer would convert the KOI-8 to UTF-16 and find the filenames.
> > Is that how it works or am I way off?
> 
> Are you describing what we will do in makeinfo, or are you describing
> how the current makeinfo, which doesn't re-encode file names, works?
> 
> If the latter, then Windows file-related APIs will assume that the
> file names we pass to them (taken from the Texinfo source's @include
> or @image directives) are KOI-8 encoded, and will attempt to convert
> the UTF-8 byte sequences to UTF-16 as if they were KOI-8 encoded.  The
> results will never be pretty, and if some byte doesn't exist in the
> KOI-8 encoding, the conversion will yield a question mark '?' or a
> space character; in the former case, the API call will likely fail
> because '?' is not allowed in Windows file names.

I meant what we would do in makeinfo.  The behaviour you describe is
useful to know.  If the codeset affects how filenames are accessed
through the file APIs, then it makes sense to convert filenames to that
codeset (for MS-Windows only).  On the other systems we support, there
is not this extra layer of conversion where the files are stored with
UTF-16 names but the file APIs take filenames encoded in the current
codeset.