On Tue, Aug 18, 2026 at 11:13:58AM +0200, Patrice Dumas wrote: > 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,
I understand this would solve some of the problems addressed by the 'count_context' stack and the _update_locations_counts function (called by _align_environment)? The method you propose in theory does appear to solve the problem of relocating anchors in text and could possibly be easier to understand. I guess the use of _stream_output_encoded would change as well and it possibly wouldn't be needed? > such as 'need_quoting' for node name I don't understand this part. If this refers to the fact that node names are output as already encoded, it could be possible to cache them in in an unencoded form in 'node_name', as I said in my other email. (Looking at the code in 'node_name', I'm not sure of the exact status of this, as we do set an 'encoding_disabled' context, but then we pass the result of 'node_name' to _stream_output_encoded). As I remember, encoding the node name only once had a minor performance improvement, but this can easily be changed if the whole module is rewritten in C anyway. > a width in character, if needed. I don't understand this either. > 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. Basically we only need the node and anchor byte offsets once, when we output the Info file tags table, as far as I understand. I'm not sure what the relevance of a footnote is or how this is different to a multitable cell, for example. In summary it doesn't seem like a bad idea but I can't say for certain how well it would work. Multitable formatting, with multiple columns of text, seems like it would be difficult to get right with anchors in the columns, although presumably this is dealt with by the existing code. > > -- > Pat >
