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]
