Hi Keiron,

Keiron Liddle wrote:

<snip/>
> 
> The line height calculation and alignment is only very basic at the moment.
> The idea is that the LineLM gets certain information to find the offset to
> baseline and total line height and when the InlineLM add areas they use this
> information to set the position of the inline areas.
> 
> 
Yes, I noticed that you'd added this as well to the information returned in the 
BreakPoss.


Now that it looks like things are heating up, we probably do need to do 
some cleanup before we get too much more code written. I agree with 
Joerg that we could simplify the inheritance now that we are only using 
the BP stuff. It wouldn't be so much work at this point to fold the BP 
versions back into the original interface and AbstractLM and to rename 
LineBP and TextBP. What do you think?

The other thing I have been thinking about is how to structure the 
information we are returning in BreakPoss (besides the actual position 
part). In fact, it's really the same (more or less) information which 
we'll end up putting on the final Area we create, since a BreakPoss is 
really just a potential Area. I was wondering a while back whether we 
should just encapsulate an Area directly in the BreakPoss and use that 
to store the size information. On the other hand, some information won't 
be needed on the final areas (once they are positioned) such as the 
MinOptMax space around the area, the keep constraints etc, which are 
only used by the LayoutManagers while decided which BreakPoss to 
actually use to create the Area.

Another general LM issue involves at which level to take into account 
the stacksize limit. For the inline stuff, I only used it at the LineLM 
level. I just had the lower level LM return each possible line-end and 
then let the LineLM decide whether it fit or not. When it got a 
BreakPoss which was too big, it could then decide to hyphenate, which 
means going into a kind of mode where it examines less optimal breaks.

The equivalent of that logic on the block stacking level could be to 
have all block-level LM except the FlowLM return fairly large chunks 
(between block-level FOs for example) and then have the FlowLM ask them 
to break the block into smaller pieces when it gets a BreakPoss which 
overflows the current column size. I was originally thinking of having 
the block-level LM return on every Line, but that makes a lot of work 
and a lot of object creation, so it would probably be slow.

For tables, I'd be tempted to always have the first layout pass return 
only breaks at row boundaries (or groups of rows linked by spanning 
cells) and only get into row-breaking logic if a) the row doesn't fit 
and there is no previous "good" break; b) the row and its cells don't 
have keep-together=always.
Of course, if we get a row or a row group which is already starting a 
page and still won't fit, we have to break it anyway (or overflow it) in 
order to avoid the infinite loop problem.

As you and Joerg were discussing the other day, exactly how to do the 
breaking in the row is very complex. If we try to optimize it we will 
get into some very deep decision trees with breaks in each cell.

I tend to think that most tables should be set up to have 
keep-together=always. (Hint to the users!) On the other hand, there are 
cases where people are using tables to get some kind of special layout 
effect (unequal columns for example) and they want the cells to be able 
to be broken, so we can't get around this in the long run.

Regards,
Karen





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

Reply via email to