> Date: Wed, 16 Sep 2026 15:55:27 +0200 > From: [email protected] > Cc: Gavin Smith <[email protected]>, [email protected] > > On Wed, Sep 16, 2026 at 02:58:03PM +0300, Eli Zaretskii wrote: > > > From: Gavin Smith <[email protected]> > > > Date: Wed, 16 Sep 2026 10:06:50 +0100 > > > Cc: [email protected], [email protected] > > > > > > On Tue, Sep 15, 2026 at 02:52:19PM +0300, Eli Zaretskii wrote: > > > > > I don't fully understand your use case for non-UTF-8 encoded Info > > > > > files > > > > > > > > The use case is a Texinfo source encoded in some encoding that cannot > > > > be easily converted to UTF-8. Another use case is when for some > > > > reason the preferred output encoding is not UTF-8. > > > > > > It occurs to me that the first use case you describe would not actually > > > work if the correct encoding is given in the source with > > > @documentencoding, > > > as texi2any uses UTF-8 as an intermediate format. > > > > That's actually a bother: what does texi2any do if some byte sequence > > fails to be converted to UTF-8 intermediate format? would it > > completely fail to produce an Info file, or does it have some fallback > > mechanism to cope with this? > > It depends where. If it is some isolated sequence, you get some message > that there is something wrong going on, but the result should be usable.
OK, but what happens with the byte sequence which couldn't be converted in this case? is it skipped, and thus nothing due to it will appear in the produced Info file?
