> Date: Mon, 17 Aug 2026 22:27:35 +0200 > From: Patrice Dumas <[email protected]> > > On Fri, Aug 14, 2026 at 04:42:32PM +0200, Patrice Dumas wrote: > > 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 > > Thinking more about the issue, I think that first it is a good thing to > keep the two phases, as one phase for conversion of characters as text, > with possibly dome reorganizations of the text and additions of leading > spaces or end of lines for example, followed by a phase considering the > text as bytes and doing the bytes counting and adding binary quoting > seems to be a good design independently of whether encoding takes place. > > I think that it would be good to revisit the design of the code that > needs to add spaces and move text around (@center, @flushright and > @multitable), such that > * when formatting the inside, character text segments and point anchors > are produced and possibly moved around. > * at the top level, go through the final segments and do the bytes > counting (and possibly encoding). > > I think that it would be a much cleaner design. > > Any comment?
If you are asking me, I don't think I know enough about the design and the implementation of this at a level where I could provide you with some useful response. Sorry.
