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, graphics... Have nice dreams! J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
