Thanks for the feedback. I'll probably look into it during the weekend.

On 06.03.2008 17:55:40 Andreas Delmelle wrote:
> On Mar 6, 2008, at 10:26, Jeremias Maerki wrote:
> Hi Jeremias
> First things first:
> > Andreas, have you, by chance, started on this one already? I want to
> > avoid that two people are working on the same problem.
> Not yet. In my experiments with fo:inline-container, I did stumble  
> upon a similar problem, but there the BreakingAlgorithm actually  
> chokes because the elements are still unresolved at the time the  
> LineLM for the ancestor block wants to compute the break- 
> possibilities. (ClassCastException in BreakingAlgorithm.getElement()  
> because a BreakElement, for example, is not a KnuthElement)
> I'm not even sure how to get around this for inline-containers, so if  
> you have an idea to fix it for inlines, then go right ahead.
> > I've done some investigation here. It looks like fixing this leads  
> > to a
> > somewhat bigger issue. But first things first:
> >
> > - The list-block (and tables and block-containers) don't get rendered
> > because their Position objects don't return true on generatesAreas().
> > LineLayoutManager filters those in addAreas() because of that.
> Seems more correct to have this return true.
> > - the mustKeepTogether() method in ListBlockLM must be adjusted  
> > like it
> > was already done in BlockLM.mustKeepTogether(). The other LMs will  
> > need
> > to be checked, too.
> >
> > That would fix the issue at hand but if I use a block-container inside
> > an fo:inline I get an NPE because stackLimit in the LayoutContext is
> > null. I then found out that stackLimit is used in both IP-direction  
> > and
> > BP-direction. I think this would need to be split in two fields so the
> > BP-direction value can be preserved so that block-level LMs which are
> > children of an inline-level LM can restore the stackLimit value  
> > that was
> > used by the last block-level LM in the stack.
> Good idea. I also noticed that the same stackLimit is used for both  
> directions. By itself, this did not seem problematic as long as page-  
> and line-breaking do not interact. Splitting up into a stackLimitBP  
> and a stackLimitIP (or whatever names you had in mind) seems better  
> in the long run.
> Cheers
> Andreas

Jeremias Maerki

Reply via email to