Mailing-List: contact fop-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xmlgraphics.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Wed, 3 Aug 2005 22:00:27 +0200
From: Simon Pepping <spepping@leverkruid.nl>
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Handling of block-level FOs inside fo:inline and related
Message-ID: <20050803200027.GA5179@oranjetip.leverkruid.nl>
Mail-Followup-To: fop-dev@xmlgraphics.apache.org
References: <20050803200801.3CBB.DEV.JEREMIAS@greenmail.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050803200801.3CBB.DEV.JEREMIAS@greenmail.ch>
User-Agent: Mutt/1.5.6+20040722i

I have been working on that, rather slowly, as I do not have much
time.

My solution for the Knuth Elements is that each inline level LM
returns a list of Knuth sequences, inline or block. This part works
well.

The code works well for fo:inline with inline or block content. I have
not yet implemented it in other LMs except BasicLinkLM.

I have done some work for rendering. But I am not very familiar with
that part of FOP, and have not yet paid attention to details.

I will post a patch on Bugzilla. The present state of the code breaks
other inline level LMs as they do not yet return the correct data
structure for the next Knuth elements. Therefore I cannot commit it to
HEAD. I could commit it into a branch.

For the next few weeks I will also spend a lot of time on other
things. So, if I am progressing too slowly, someone else should feel
free to take this further.

Regards, Simon

On Wed, Aug 03, 2005 at 08:30:56PM +0200, Jeremias Maerki wrote:
> fo:inline, fo:bidi-override and fo:inline-container are all inline-level
> FOs and all allow block-level content. Currently, they are not
> implemented. See, for example, inline1.xml which fails with a
> ClassCastException. The FO I skipped here is fo:wrapper which in the
> current implementation doesn't really wrap its content and therefore
> avoids an important problem:
> 
> Inline FOs return element lists processed by the line breaker. They
> don't have a way to return elements for the page breaker.
> 
> I've been asked to do a time estimate for implementing fo:inline.
> fo:inline is particularly important since a lot of people use empty
> fo:blocks, for example, to mimic newlines. Now I wonder about how to
> implement fo:inline. The only way I came up with was to try normalizing
> the FO tree and to let fo:inline be what it currently is:
> 
> Input:
> 
> <fo:block color="blue">blah blah <fo:inline font-style="italic">blah<fo:block/>blah</fo:inline>blah</fo:block>
> 
> Output:
> 
> <fo:block color="blue">blah blah <fo:inline font-style="italic">blah</fo:block>
> <fo:block color="blue" font-style="italic"/>
> <fo:block color="blue" ><fo:inline font-style="italic">blah</fo:inline>blah</fo:block>
> 
> or:
> 
> <fo:block color="blue">
>   <fo:block>blah blah <fo:inline font-style="italic">blah</fo:block>
>   <fo:block font-style="italic"/>
>   <fo:block><fo:inline font-style="italic">blah</fo:inline>blah</fo:block>
> </fo:block>
> 
> Replicating the properties of an fo:inline to a copy shouldn't be much
> of a problem. Replicating the properties for the contained block might
> already me a little more difficult because of the whole inheritance
> stuff.
> 
> Is there another way? A better way? Any ideas?
> 
> For fo:bidi-override, the same approach would be used.
> 
> For fo:inline-container this whole thing is easier since it generates a
> viewport/reference pair, so it will ultimately need its own breaker
> (like absolutely positioned block-containers).
> 
> 
> Jeremias Maerki
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl