On Tue, Aug 18, 2026 at 08:35:19PM +0100, Gavin Smith wrote: > On Tue, Aug 18, 2026 at 11:13:58AM +0200, Patrice Dumas wrote: > > 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)?
There would not be a need for separate target_locations anymore, as they would be in the flow of th etext. > The method you propose in theory does appear to solve the problem of > relocating anchors in text and could possibly be easier to understand. That's the idea. The data complexity should not change as it goes from one place to the other, but the code flow should be easier to understand. > I guess the use of _stream_output_encoded would change as well and it > possibly wouldn't be needed? It wouldn't be needed anymore. > > such as 'need_quoting' for node name > > I don't understand this part. The quoting characters for node should not be taken into account when deciding how to place text when width of text is important. I propose to mark the text as needing quoting when it is convenient, but add the characters at the very end only, such that they are taken into account in bytes counts only. > 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. It was not really about node names being output as already encoded, but what you propose is indeed the same for node names, cache them unencoded, and do the same, ie keep unencoded all the text processed in count contexts. > > a width in character, if needed. > > I don't understand this either. It is not important, but it could be practical to set the width of text that can benefit from it once of all. > > 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. Where the footnote content is output is like the main text, it can be directly output. A multitable cell need to have padding spaces added to be rightly aligned, so it cannot be formatted at onece, first cells need to be formatted, then space added. > 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. Indeed, this is dealt with by the existing code, but I think that it could be more elegant if the bytes counts did not need to be modified at the same time as columns are reorganized, but appear 'automatically' in the right place once the surrounding text has been moved/padded with spaces and have their bytes count easily computed in the last stage. -- Pat
