bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-ASCII characters in @include search path


From: Gavin Smith
Subject: Re: Non-ASCII characters in @include search path
Date: Sat, 26 Feb 2022 22:23:04 +0000

On Sat, Feb 26, 2022 at 11:09:53PM +0100, Patrice Dumas wrote:
> On Sat, Feb 26, 2022 at 09:29:15PM +0000, Gavin Smith wrote:
> > On Sat, Feb 26, 2022 at 9:11 PM Patrice Dumas <pertusus@free.fr> wrote:
> > > The whole output file is encoded, the problem is that you encoded
> > > $image_file, it should not be, it is assumed to be decoded from the
> > > document. image_path could be encoded, but then the encoding should be
> > > passed such that it can be re-decoded, for error messages, for instance.
> > 
> > It would probably be easier to do it the way you said and decode all
> > the file names and encode them just before use. It's too confusing
> > otherwise, even if doing it that way would give a little more
> > flexibility for non-UTF-8 input files and locales (assuming we
> > actually did it properly, and didn't ever break it by mistake).
> 
> Did I understand well that we should decode everything now?  How do you
> want to proceed?

Just as you recommended.  In texi2any.pl, decode all customization
variables as you suggested before.  I guess the locale encoding would
be used for this.

When encoding file names, use the @documentencoding if they came
from the document.  I'm not sure about encoding strings from the
command-line but the @documentencoding is probably okay for this too
(I'm not sure if it would always be possible to tell where the strings
came from.)

Don't use the locale encoding by default for encoding filenames.

I'm happy to work on this.  I won't have time until tomorrow afternoon
(GMT) at the earliest, but it may be several days later.  I'm happy if
you want to try implementing this before I do.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]