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