On Thu, 6 Oct 2005 03:44 pm, Jeremias Maerki wrote:
> What I write next should be consumed with caution and the fact in
> mind that English is a foreign language to me, because I have big
> trouble translating 4.2.4. 4.2.4 defines "preceding" WRT to the area
> tree, but I really can't parse that section. OTOH, 7.15.12 talks
> about flow objects, not areas, even though we're in the area
> generation stage. I didn't find a definition for "preceding" for the
> FO tree, BUT! XPath defines the "preceding" axis so that the space
> after "Start" (in your example) is directly preceding the first space
> inside the inline. So if you ask me, the current behaviour of FOP is
> correct. D'oh! :-)
>
Yes - d'ooooh!

But "my bad" - I should have checked the xsl-editors list first. Karen 
Lease (wasn't she a 'fopper'?) asked the same question years ago and 
the answers is in: 
http://lists.w3.org/Archives/Public/xsl-editors/2002OctDec/0004

In summary: "preceding" only applies to siblings and therefore does not 
go across inline boundaries. This means we do it wrong at the moment. 
In XPath language it means we have to use the preceding-sibling axis.

> On 06.10.2005 08:22:32 Manuel Mall wrote:
> > Not sure if this is another of those areas in the spec which is
> > cause for much confusion but I noticed that FOP trunk collapses
> > white space across fo:inlines. For example (I use a . to represent
> > a white space character):
> > Start.<fo:inline>.Text.</fo:inline>.End
> > is rendered as:
> > Start.Text.End
> >
> > However, in 7.15.12 the white-space-collapse property definitions
> > says for "true" (the default value) and I am rephrasing here(!): A
> > space character is dropped if the immediately preceding flow object
> > is a space character. I would read this as to mean NOT to collapse
> > across the boundaries of a fo:inline (FWIW - neither RenderX nor
> > AntennaHouse seem to collapse across fo:inline boundaries) although
> > it hinges on the interpretation of the term "preceding" in the
> > context of a tree structure.
> >
> > Manuel
>
> Jeremias Maerki

Manuel

Reply via email to