On Sun, Feb 20, 2022 at 03:32:30PM +0000, Gavin Smith wrote: > On Sun, Feb 20, 2022 at 2:55 PM Patrice Dumas <[email protected]> wrote: > > > The byte sequences are just concatenated and used as the path to the file, > > > even if it's not validly encoded. This shouldn't cause a problem. > > > > It will cause a problem if the include file name itself is not ASCII. > > To avoid any problem and mismatch, decoding at input, doing everything > > in the code with internal perl unicode and encoding on output seems to > > me the best. > > It would make it impossible to build the Texinfo manual if it was > being done from a directory that was in a different encoding. This > could happen if a user had their home directory, for example, in > Latin-1 and then they download and try to build a manual that is in > UTF-8 in their home directory. The directory name could get into -I > options via Makefile rules, as was the case with the original bug > report for the Octave manual.
I don't get it. If everything is decoded to internal perl encoding and then the file name is encoded to the local, here Latin-1, everything will be ok, as long as the characters in manuals can be output in Latin-1. -- Pat
