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 

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]

Reply via email to