On Aug 24, 2006, at 02:39, Patrick Paul wrote:

Andreas L Delmelle wrote:
<snip />
A more correct approach --a matter of taste?-- would be for the TableContentLM to 'collect' the accumulated list of its descendant LMs, perform the min/max-width calculation, update the LayoutContext, and send it back down to the LineBreaker.

When you say 'collect' I suppose you mean that the TableContentLM whould have to keep all the LinkedLists of elements for the entire table.

Not necessarily the TableContentLM itself, but it could be made such that the higher-level LM at least gets to see the raw element list before it is handed over to the breaker. I was thinking this could offer opportunities in other areas as well, although I now have a hard time coming up with any concrete examples. Maybe this could help avoid certain expensive operations during the breaking stage, if it can be derived from seeing the base element list that they will be useless/futile anyway (?)

I haven't looked at this closely, but wouldn't that also imply some kind of mechanism on the TableCellLM and BlockLMs when going back down to the LineBreaker to perform the line-breaking?

Indeed, they would have to be involved in this as well.

If I understand all this correctly, it would imply holding the element lists for an entire table. Wouldn't that be expensive in terms of memory?

Isn't that what we currently already do? For an entire page-sequence no less... It is indeed expensive, but necessary for a total-fit algorithm. No way around that, I'm afraid.

<snip />

Strictly speaking, apart from the arbitrary default 'available ipd / # columns', you don't have a correct ipd to give to the Breaker. If you do perform the breaking, however, the element list will also contain elements that have been added by the Breaker.

A way around this is to give an arbitrarly large default available ipd the first time you run through the algorithm. This reduces the extra line-breaking.

Good point!

Although I haven't done too much investigation on whether they influence the content-width calculation, this still means these elements are created for no reason at all.
IOW: this would be a wasted trip through the breaking algorithm.

Correct. This is what is happening for now. I run through the getNextKnuthElements twice: the first time to determine the minimum and maximum widths of the content, and the second to do the proper line-breaking.



Reply via email to