You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2008/03/06 10:26:58 UTC
Re: inline and fo:list-block
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.
- 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.
Andreas, have you, by chance, started on this one already? I want to
avoid that two people are working on the same problem.
On 05.03.2008 22:48:11 Andreas Delmelle wrote:
> On Mar 5, 2008, at 22:28, Steve Protulipac wrote:
>
> >
> >> Correct. As a workaround, you could insert a fo:block between the
> >> inline and the list:
> >>
> >> <fo:inline>
> >> <fo:block>
> >> <fo:list-block...>
> >
> > When I try the fo:block, the list is not rendered. I get a blank
> > page.
> > I tried the fo:block just as above, with no attributes.
>
> Just as a confirmation:
> You're right! The text I just saw rendered was inside a separate
> block outside of the list. The list itself is indeed not rendered.
>
> Sorry.
>
> Cheers
>
> Andreas
Jeremias Maerki
Re: inline and fo:list-block
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Done now. But I didn't look at inline-container!
On 07.03.2008 08:03:36 Jeremias Maerki wrote:
> 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
>
Jeremias Maerki
Re: inline and fo:list-block
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: inline and fo:list-block
Posted by Andreas Delmelle <an...@telenet.be>.
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