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...

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

Reply via email to