On Wed, 2002-08-21 at 23:29, Karen Lease wrote: > 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.
I worked out some alignment and ipd adjustment things. This look like it can work in a similar way. There is one tricky part, the ipd of the text parts accumulate. This means that to find the total ipd of a line break it needs to add the last ipd of each layout manager. > 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? I agree, the BP letters don't really add much information now anyway. > 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. I think this needs to come out from the functionality. If there is too much on the area tree it will need to cleared at some stage. > 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. I was thinking that it could return a break only if it is better or the same or if past the end. This way a block would only have one break position most of the time. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
