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 Manuel Mall <mm...@arcus.com.au> on 2005/10/06 08:22:32 UTC
white-space collapse across fo:inlines
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
Re: white-space collapse across fo:inlines
Posted by Manuel Mall <mm...@arcus.com.au>.
On Thu, 6 Oct 2005 05:14 pm, Jeremias Maerki wrote:
> That helps a lot. Thanks for looking it up! Yes, Karen was a
> "Fopper", and a good one. Now, the only thing left is to fix the bug.
> :-)
>
Its a bug in the "inline" part of FOP so its probably me or Luca in the
moment.
<snip/>
> Jeremias Maerki
Manuel
Re: white-space collapse across fo:inlines
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
That helps a lot. Thanks for looking it up! Yes, Karen was a "Fopper",
and a good one. Now, the only thing left is to fix the bug. :-)
On 06.10.2005 10:23:49 Manuel Mall wrote:
> 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
Jeremias Maerki
Re: white-space collapse across fo:inlines
Posted by Manuel Mall <mm...@arcus.com.au>.
Further on this topic -
It appears that the 1.0 spec has some deficiencies in the area of
whitespace treatment. This has been recognized by the WG as summarized
in this post to xsl-editors:
http://lists.w3.org/Archives/Public/xsl-editors/2003JulSep/0012.
Again it was Karen who initiated the discussion and it took the WG 3/4
of a year to clarify and respond. Any way the changes outlined in the
post have made it into the 1.1 draft. What does it mean for FOP? IMO
the changes don't modify the intended meaning of the properties and
line building rules in 1.0. They just clarify them and make them less
ambiguous. We should therefore implement according to the 1.1 WD
descriptions. One interesting effect of the 1.1 changes is that the
whole whitespace treatment has been moved to the line building / area
tree construction and out of refinement.
Manuel
On Thu, 6 Oct 2005 04:23 pm, Manuel Mall wrote:
> 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
Re: white-space collapse across fo:inlines
Posted by Manuel Mall <mm...@arcus.com.au>.
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
Re: white-space collapse across fo:inlines
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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! :-)
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
Re: white-space collapse across fo:inlines
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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.
This isn't the correct behavior, as well as collapsing across
a changed text decoration. Unfortunately, this isn't easily
understandable from the spec or the errata, IIRC Peter made
an inquiry on a w3c list and got a clarification.
J.Pietschmann