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 Andreas L Delmelle <a_...@pandora.be> on 2007/11/05 21:18:14 UTC
First steps towards an implementation for fo:inline-container
Hi people
I've recently (finally) started looking at implementing fo:inline-
container, and got to my first promising results, so just thought I'd
share, should there be any interested parties.
OTOH, I've also run into a few obstacles I'm unsure how to deal with,
so...
The rough InlineContainerLayoutManager implementation I have now
still descends from LeafNodeLayoutManager. No idea if that's going to
be enough in the long run, but for now I did manage to get some
simple examples working without changing this.
The generation of the element list is no particular problem.
Basically the same as blocks in an fo:inline, only slightly simpler
because the inline-container can /only/ contain block-sequences, and
as such there is no need to worry about closing any open paragraphs.
So far I only got it working for a sequence of one or more fo:blocks,
though. The sequences returned for an fo:table or an fo:list-block
seem to confuse the LineBreakingAlgorithm for the containing Block
once the inline table/list contains more than one row/item. Haven't
looked too deep into that, but it seems to be something like: the
algorithm expects to find a KnuthElement, but finds something else (a
KnuthSequence, probably => ClassCastException in
BreakingAlgorithm.getElement()).
ATM, in the basic getNextKnuthElements(), little more happens than:
KnuthSequence inlineSequence = new InlineKnuthSequence();
...
while (curLM ...) {
...
returnedList = curLM.getNextKnuthElements(...);
...
KnuthSequence tmpSeq = new BlockKnuthSequence(returnedList);
seq.wrapPositions(this);
inlineSeq.addAll(seq);
}
Qua area-generation, it is set up as a viewport/reference area pair,
where the viewport is the same Viewport type used for the images and
the reference-area is an InlineBlockParent.
Currently, I still sort of hacked the structure together:
* the reference-area has a single Block child that is used to add the
childAreas to
* at the end of the addAreas() loop, the viewport's content is set to
the reference-area
Maybe it would be slightly better to allow InlineBlockParent to have
multiple children, but for now, inserting that dummy Block seemed the
least intrusive way of reaching the goal.
Anyways, a small addition to cater for rendering an InlineBlockParent
in AbstractRenderer.renderViewport() did the rest.
One of the obstacles I'm running into now, and I'm hoping someone
might be able to provide pointers for, is adjusting the line-height.
See the attachment, where the inner blocks already appear nicely in
position, but the following line still overlaps. :(
It's not ready for a commit yet, but I do hope to get it in a more
usable state soon, so we can finally claim support for the XSL-FO
equivalent of HTML's IFRAME.
Cheers
Andreas
Re: First steps towards an implementation for fo:inline-container
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 5, 2007, at 22:30, Jeremias Maerki wrote:
> Very cool, Andreas! Actually, I don't see why you shouldn't commit
> what
> you have if it is a step forward an inline-container was basically
> unusable before.
Good to know. I have been considering uploading my changes so far,
but I'd at least like to take a look at a few other basic scenarios,
like borders and reference-orientation, before committing. Probably
something for the weekend.
> About your question (probably not very helpful): I'm not sure
> (Manuel is
> our baseline master) but why don't you take a look at
> AbstractGraphicsLayoutManager? external-graphic and i-f-o both
> generate
> a viewport/reference pair. I suspect that you simply have to provide a
> makeAlignmentContext(LayoutContext) method. Figuring out the right
> values there (given the baseline instructions for i-c) is another
> story,
> I guess. But one step at a time...
Yep, that seems to be it.
Thanks for the hint. More to follow soon.
Cheers
Andreas
Re: First steps towards an implementation for fo:inline-container
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Very cool, Andreas! Actually, I don't see why you shouldn't commit what
you have if it is a step forward an inline-container was basically
unusable before.
About your question (probably not very helpful): I'm not sure (Manuel is
our baseline master) but why don't you take a look at
AbstractGraphicsLayoutManager? external-graphic and i-f-o both generate
a viewport/reference pair. I suspect that you simply have to provide a
makeAlignmentContext(LayoutContext) method. Figuring out the right
values there (given the baseline instructions for i-c) is another story,
I guess. But one step at a time...
HTH
Jeremias Maerki
On 05.11.2007 21:18:14 Andreas L Delmelle wrote:
>
> Hi people
>
> I've recently (finally) started looking at implementing fo:inline-
> container, and got to my first promising results, so just thought I'd
> share, should there be any interested parties.
>
> OTOH, I've also run into a few obstacles I'm unsure how to deal with,
> so...
>
> The rough InlineContainerLayoutManager implementation I have now
> still descends from LeafNodeLayoutManager. No idea if that's going to
> be enough in the long run, but for now I did manage to get some
> simple examples working without changing this.
>
> The generation of the element list is no particular problem.
> Basically the same as blocks in an fo:inline, only slightly simpler
> because the inline-container can /only/ contain block-sequences, and
> as such there is no need to worry about closing any open paragraphs.
> So far I only got it working for a sequence of one or more fo:blocks,
> though. The sequences returned for an fo:table or an fo:list-block
> seem to confuse the LineBreakingAlgorithm for the containing Block
> once the inline table/list contains more than one row/item. Haven't
> looked too deep into that, but it seems to be something like: the
> algorithm expects to find a KnuthElement, but finds something else (a
> KnuthSequence, probably => ClassCastException in
> BreakingAlgorithm.getElement()).
>
> ATM, in the basic getNextKnuthElements(), little more happens than:
>
> KnuthSequence inlineSequence = new InlineKnuthSequence();
> ...
> while (curLM ...) {
> ...
> returnedList = curLM.getNextKnuthElements(...);
> ...
> KnuthSequence tmpSeq = new BlockKnuthSequence(returnedList);
> seq.wrapPositions(this);
> inlineSeq.addAll(seq);
> }
>
> Qua area-generation, it is set up as a viewport/reference area pair,
> where the viewport is the same Viewport type used for the images and
> the reference-area is an InlineBlockParent.
> Currently, I still sort of hacked the structure together:
> * the reference-area has a single Block child that is used to add the
> childAreas to
> * at the end of the addAreas() loop, the viewport's content is set to
> the reference-area
>
> Maybe it would be slightly better to allow InlineBlockParent to have
> multiple children, but for now, inserting that dummy Block seemed the
> least intrusive way of reaching the goal.
>
> Anyways, a small addition to cater for rendering an InlineBlockParent
> in AbstractRenderer.renderViewport() did the rest.
>
> One of the obstacles I'm running into now, and I'm hoping someone
> might be able to provide pointers for, is adjusting the line-height.
> See the attachment, where the inner blocks already appear nicely in
> position, but the following line still overlaps. :(
>
>
> It's not ready for a commit yet, but I do hope to get it in a more
> usable state soon, so we can finally claim support for the XSL-FO
> equivalent of HTML's IFRAME.
>
>
> Cheers
>
> Andreas
>