On Mon, Aug 17, 2026 at 10:27:35PM +0200, Patrice Dumas wrote: > 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).
With more thinking, the design I propose would be to modify _stream_output such that it can either add text, or an anchor (or float). The text could also have information associated, such as 'need_quoting' for node name, a width in character, if needed. The anchor information would be an identifier. Pending text would become an array containing both text and anchors. There would be functions similar to _stream_result as used in a current count context specifically opened for a region, but that would return the _stream_output data, as described above, instead of encoded and byte counted result. _stream_result and similar would also be modified such that they go through the array setup by _stream_output, encode if needed, count the text bytes and set the anchor bytes counts. The code would be changed such that _stream_result is only called on main document, or footnote (bottom) contexts. -- Pat
