On Fri, Aug 14, 2026 at 05:24:55PM +0300, Eli Zaretskii wrote: > So it becomes impossible to control the encoding of the Info file by > any specification in the Texinfo source? Why is that a good idea? > > I don't understand why the current situation, where we use > @documentencoding, is a problem.
The first issue is about the encoding of cross-references. With a mix of encodings, the cross-references in the source and target manual may not match. The Info readers could mitigate this issue, but it would involve more decoding/recoding. For the C Info reader, Gavin decided that it is not worth it (it is documented in the manual). The second is about easing the implementation. We convert to UTF-8 upon reading and do everything in this encoding, in particular determining line width for cutting lines, or centering or flushing right. In Info output, however, we also need to track the bytes count in the output encoding to fill the Info tag tables that allows to find anchors and nodes in Info file. Therefore, we do the output in two phases, first conversion in UTF-8 and then encoding to determine bytes counts. In some cases it is not easy to do it in two phases, we need to convert back already encoded strings to UTF-8 to do the counting. Outputting in UTF-8 only would remove * the need to do two phases * the need to convert back More generally, having only UTF-8 encoded Info manuals will only simplify things in the long term, without any drawback. Info files are not usually manually modified, people modifying Info files manually will know what to do about encodings. -- Pat
