On Mar 13, 2007, at 14:51, Manuel Mall wrote:

On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote:
<snip />
That would imply to change almost every LayoutManager to
compute/transfer this information. Quite a bit of work.

Yes, but I think for slightly different reason. The logic (in the case
of lists) to support relative-align would have to be in the ListItemLM. After doing the line breaking (getNextKnuth...) for both the item label and the item body the ListItemLM would need to get to the first line of
both subordinates (via the first Knuth element of each of the lists
returned?), compare their heights and baselines, signal adjustments
down to the relevant InlineLevel LMs and adjust the already generated
Knuth element for page breaking to the new line height. I guess a
similar logic would need to apply to support relative-align for table
cells, i.e. it would reside at row level.

FWIW: this would be much more straightforward to handle with Vincent's idea of merging page- and line-breaking, and my idea to use endBlock() as a start/resume trigger for this combined algorithm (supposing they're both feasible ideas, of course...)

As such, the end of the block in the list-item-label would then give the higher level ListItemLM the chance to determine the label's baseline/line-height/BPD *before* the block(s) in the list-item-body pass through the breaking-algorithm.

As a consequence, I'm not so sure whether it would make much sense to hack it in as a modification to every LM. The LMs and the interaction between FO tree and layoutengine need to be revisited anyway to address other issues (large page-sequences, alternating IPD, optimal start-/end-float placement, etc.)

Just my 2 cents...


Cheers,

Andreas

Reply via email to