Hello,

I think that I have finished this 'redesign'.  I am quite happy with the
result.  I do not think that there is less code, as some simple
functions were added that could have been inline before, when the
pending code was a string.  But the code is much easier to follow, in my
opinion.

On Tue, Aug 18, 2026 at 11:08:28PM +0200, Patrice Dumas wrote:
> On Tue, Aug 18, 2026 at 08:35:19PM +0100, Gavin Smith wrote:
> > > 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.

In the end I did not do that.

> > > 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.

I did not do that either, as the need for width (outside of the
Paragraph formatter) is rare.

> > 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.

The multitable and align resulting code are more verbose than
previously, but do not seem to me to be more complex.

-- 
Pat

Reply via email to