On 15 Dec 2008, at 16:59, Philip V wrote:
Hi
Well, 0.20.5 was always slightly non-compliant where it came to white-
space handling. That said, it is not an issue of non-compliance in
this case.
I am having trouble collapsing some whitespace. I hope you may help.
Take the following resulting fo:
Specifying those properties on an fo:inline has no result (at least,
not one you would generally expect).
Explanation: The properties in question only apply to blocks and are
inherited by their descendants. The value for the white-space-collapse
property that governs the fo:inline will be the one of the parent
fo:block. The one you specify on the fo:inline may be inherited by
deeper fo:blocks, though...
Not that this would solve your issue, but I'm adding this just for
completeness.
See (
Figure
3
, Item 2) and (
Figure
2
, Item 5).
This will lead to the same (unexpected) result with 0.95, given that:
- white-space-collapse='true' refers ONLY to sequences of white-space
characters (so: if you have N white-spaces adjacent to each other,
only one will survive the white-space handling)
- linefeed-preserve="treat-as-space" (unspecified default) means
convert linefeeds to regular spaces
- white-space-preserve="ignore-if-surrounding-linefeed" (unspecified
default) means disregard any spaces surrounding preserved linefeeds or
implicit line-breaks
Now, as long as you have:
See (
This will, with those property settings, ALWAYS yield at least one
space between the opening bracket and the content of the fo:basic-
link. Even worse: there is no combination of properties that will
strip that white-space during formatting.
To avoid this, you need to make sure that no linefeed is generated
between the text and the fo:basic-link element.
In practice, such spaces are (almost always) added:
a) either by the XSLT stylesheet, due to an > (if the result is serialized to a file before FOP gets its hands on
it)
b) or because XSLT's built-in template rule for text() nodes gets
applied to white-space only nodes (in which case they just get copied
from the XML source file)
Case a) is bad practice, and best avoided, unless during development,
when you need to debug the intermediate FO result. If you plan on
feeding FOP XML+XSLT input directly, the indent attribute should
normally be ignored by the XSLT processor. If you have clearly
distinct transformation & formatting stages, then it's better not to
use that output-hint to make sure the stylesheet produce processor-
friendly XML/FO.
Case b) can be avoided, for example, by providing an override for the
built-in template rule, like:
Note: this ONLY works if your stylesheet does not rely on xsl:apply-
templates for outputting the value of text() nodes. If you're not
sure, then you can do something like:
Alternative approach would be to adapt the stylesheet, and make sure
you have no:
but always
which would process only element nodes from your input, and leaves the
text() nodes alone.
HTH!
Cheers
Andreas
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
