Keiron Liddle wrote:
A footnote or float is always ossociated with a line area. That line
area adds to the current stacking and to an out of line stacking.
Note that there are also the before-float separator and the footnote
separator, which complicae matters a bit.

Can the break information be held inside the layout managers and only
some sort of status return.
I thought a BlockBreakPossibility is a first class object, containing
the full state necessary to create the area before the break in the
current context, and enough to start creating further areas from then.
A break possibility is returned to the parent LM, which decides whether
this makes a break possibility for itself or not. In the latter case, the
break possibility can probably be discarded.
The situation is a bit different for line break possibilities, in case
of a fixed IPD passing up everything is most likely a waste. I think in
this case some sort of events rather than break possibilities have to be
passued up, in particular
- side floats
- before floats and footnotes, because of the change of available BPD
- increase in line height, for example because of a larger font size,
  a graphic higher than the current line height, base line shift or
  an inline container
Mixed orientations and writing directions on a page significantly
complicate matters. If there is a 10cm BPD left, and a block container
changing the writing mode from tb-lr to lr-tb follows, is the available
IPD for the text in the container 10cm even if this results in two
lines, filling let's say only 2cm BPD of the available 15cm BPD of
the container, which is the same as the IPD of the container's parent?
Looks bad. Also, footnotes in the lr-tb container subtract from the
available IPD for the container, don't they? And probably inherit the
lr-tb setting, therefore they have a variable IPD itself?

For the column IPD calculation for auto table layout, and probably
every other situation where the available IPD is not fixed, of course
all break possibilities have to be calculated. Should this already
include possiblities created by hyphenation?

Just for fun: because of the hyphenation-ladder-count, either the
parent LM must be able to tell the line LM not to hyphenate this line,
or the line LM must tell the parent LM about hyphenation, so that the
parent LM can reflow the block after the fact.

There are more dragons here. Lets say the remaining BPD is 15pt, font
size determined line height is 14pt and the block LM starts laying
out another line. After two short words a 30pt font sized word is
encountered -> line height increase event. What should the block
LM do:
a) break the block before the line, i.e. the whole line goes to the
   next column/page
b) close the line after the first two short words and open a new line
   starting with the 30pt sized word.
The choice might depend somewhat on whether shifting the whole line
creates an overconstrained condition or whether some spaces provide
wiggle room. Anyway, it's always a matter of opinion by how much the
last line rendered on a page may miss the total BPD. Missing by 0.5pt
is certainly acceptable, missing by some 40pt will probably cause
complaints. Multiple colums with varying font sizes/embedded graphics
of varying height provide another complication: the base line of the
last lines of the columns should better align, even at the cost of
violating other constraints by some small amount.
BTW would it be allowed to overshoot an area by 0.5pt rather than move
the whole line to the next page, leaaving 30pt of empty space?

How can we simplify the line area layout manager which is complex and
bug prone.
I'm afraid we can't. TR14 + proper hyphenation alone is complex enough,
throw in inline containers, arbitrary font size changes, baseline shifts,

Have nice dreams!

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to