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
>
