Re: generating Info encoded in UTF-8 only

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