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
