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:

<fo:block line-height="12pt" font-family="sans-serif" font-size="10pt"
text-align="left">
        <fo:inline white-space="nowrap" white-space-collapse="true"
wrap-option="no-wrap">

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 (
                <fo:basic-link internal-destination="idM01005" 
color="black">Figure
3</fo:basic-link>
                 , Item 2) and  (
                <fo:basic-link internal-destination="idM01006" 
color="black">Figure
2</fo:basic-link>
                , Item 5).
        </fo:inline>
</fo:block>

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:

<fo:inline>See (&#x0A;     <fo:basic-link ...>

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 <xsl:output indent="yes" / > (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:

<xsl:template match="text()" />

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:

<xsl:template match="text()[string-length(normalize-space(.))=0]" />

Alternative approach would be to adapt the stylesheet, and make sure you have no:

<xsl:apply-templates />

but always

<xsl:apply-templates select="*" />

which would process only element nodes from your input, and leaves the text() nodes alone.


HTH!

Cheers

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to