xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Delmelle <andreas.delme...@telenet.be>
Subject Re: inline and fo:list-block
Date Thu, 06 Mar 2008 16:55:40 GMT
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.



View raw message