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
