Glad that solved the problem. The URL for the namespaced version
replaces "xsl" with "xsl-ns".
Bob Stayton
Sagehill Enterprises
bobs@sagehill.net
On 2/20/2014 12:26 PM, David Clunie wrote:
> Ah ha!
>
> I was indeed using some further processing on the FO, specifically
> pmml2svg to make my MathML into SVG, and inside the pmml2svg.xsl
> stylesheet, indent was set to "yes".
>
> Setting it to "no" solves the problem (and removes spurious spaces).
>
> Very cool.
>
> Thanks for the prompt response!
>
> David
>
> PS. I am using the namespace aware version, and using a catalog to
> map the import URL; should I be using a different URL that is
> namespace specific?
>
> On 2/20/14 1:00 PM, Bob Stayton wrote:
>> Hi David,
>> Those kinds of added line breaks only occur when the FO stylesheet has
>> <xsl:output indent="yes"/>. However, it doesn't look like your
>> stylesheet uses that, and the stock DocBook XSL stylesheet specifically
>> sets indent="no". If I add <xsl:output indent="yes"/> to your
>> customization, I get that kind of extra line breaking.
>>
>> Are there any other stylesheet files involved in the tool chain? I
>> notice that your stylesheet has this import statement:
>>
>> <xsl:import
>> href="http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl"/>
>>
>>
>> That will import the non-namespaced version of the stylesheets. Are you
>> using an XML catalog file to map that to a local stylesheet? If so, is
>> it possible that local stylesheet has such an <xsl:output indent="yes"/>
>> statement added to it?
>>
>> To sort this out, I would first try downloading a fresh copy of
>> docbook-xsl-ns-1.78.1 and process your document directly with that local
>> copy, without any customization. That will tell us if the fault is in
>> the distributed stylesheets.
>>
>> Bob Stayton
>> Sagehill Enterprises
>> bobs@sagehill.net
>>
>> On 2/20/2014 3:44 AM, David Clunie wrote:
>>> Hi guys
>>>
>>> I have a segment of a DocBook document that happens when rendered
>>> to PDF using xep to have a line break inserted after a section
>>> reference preceding a closing parenthesis.
>>>
>>> Specifically, the DocBook contains:
>>>
>>> <para>A C-MOVE request may be performed to any level of the
>>> Query/Retrieve
>>> Information Model. However, the transfer of stored SOP Instances may
>>> not
>>> be performed at this level. The level at which the transfer is
>>> performed
>>> depends upon the SOP Class (See <xref linkend="sect_C.6"
>>> xrefstyle="select: label"/>). </para>
>>>
>>> and the stylesheet writes the following FO for this sentence:
>>>
>>> <fo:block space-before.optimum="1em" space-before.minimum="0.8em"
>>> space-before.maximum="1.2em">A C-MOVE request may be performed to any
>>> level of the Query/Retrieve Information Model. However, the transfer
>>> of stored SOP Instances may not be performed at this level. The level
>>> at which the transfer is performed depends upon the SOP Class (See
>>> <fo:basic-link internal-destination="sect_C.6">
>>> <fo:inline>Section C.6</fo:inline>
>>> </fo:basic-link>).</fo:block>
>>>
>>> The result is shown in the attached PDF page.
>>>
>>> I don't know anything about FO, and what the rules are about whether a
>>> line break may be inserted after an <fo:basic-link/> element (or after
>>> an <fo:inline/> element), but is there any way this can be improved?
>>>
>>> Also, in general, I notice that there are extra spaces around all such
>>> references that are generated anyway, that look pretty ugly; see the
>>> other references on the same page that I highlighted. The FO follows
>>> the same pattern:
>>>
>>> <fo:block space-before.optimum="1em" space-before.minimum="0.8em"
>>> space-before.maximum="1.2em">The C-MOVE request shall contain an
>>> Identifier. The C-MOVE response shall conditionally contain an
>>> Identifier as required in
>>> <fo:basic-link internal-destination="sect_C.4.2.1.4.2">
>>> <fo:inline>Section C.4.2.1.4.2</fo:inline>
>>> </fo:basic-link>.</fo:block>
>>>
>>> Interestingly references to external documents do not have this extra
>>> space:
>>>
>>> <fo:block space-before.optimum="1em"
>>> space-before.minimum="0.8em" space-before.maximum="1.2em">The
>>> Identifier is specified as U in the definition of the C-MOVE
>>> primitive in
>>> <fo:basic-link external-destination="url(part07.pdf#PS3.7)"
>>> show-destination="replace">PS3.7</fo:basic-link>but is
>>> specialized for use with this service.</fo:block>
>>>
>>> and it would appear that though they both use a <fo:basic-link/>
>>> the difference is that there is no <fo:inline/> element that
>>> surrounds the text that is being supplied for the link. The DocBook
>>> for the external reference is:
>>>
>>> <para>The Identifier is specified as U in the definition of the C-MOVE
>>> primitive in <olink targetdoc="PS3.7" targetptr="PS3.7"
>>> xrefstyle="select: labelnumber"/>
>>> but is specialized for use with this service.</para>
>>>
>>> There is a slight difference in the xrefstyle attribute value that I
>>> am using for these internal and external links, but I am not sure
>>> that makes any difference.
>>>
>>> I looked at the stylesheet source, and fo/xref.xsl seems to be the
>>> relevant file.
>>>
>>> I gather that there are olink.properties and xref.properties, and this
>>> led me to notice that in the <xsl:template match="d:xref" name="xref"/>
>>> template that the text seemed to be created within an <fo:inline/>
>>> element only for the purpose of allowing xref.properties to be passed
>>> as an attribute set around the content. Strangely, the template of
>>> olinks does not seem to create an <fo:inline/> around the generated
>>> content and so olink.properties would presumably not affect that.
>>>
>>> I did try adding:
>>>
>>> <xsl:attribute-set name="xref.properties">
>>> <xsl:attribute
>>> name="keep-together.within-line">always</xsl:attribute>
>>> </xsl:attribute-set>
>>>
>>> to my customizations, and indeed that does change the behavior and does
>>> 'fix' the problem with the particular sentence that I was having trouble
>>> with (see second PDF attached).
>>>
>>> Interestingly, adding instead:
>>>
>>> <xsl:attribute-set name="xref.properties">
>>> <xsl:attribute
>>> name="keep-with-next.within-line">always</xsl:attribute>
>>> </xsl:attribute-set>
>>>
>>> does NOT fix the problem as I expected. The generated FO in the latter
>>> case is:
>>>
>>> <fo:block space-before.optimum="1em" space-before.minimum="0.8em"
>>> space-before.maximum="1.2em">A C-MOVE request may be performed to any
>>> level of the Query/Retrieve Information Model. However, the transfer
>>> of stored SOP Instances may not be performed at this level. The level
>>> at which the transfer is performed depends upon the SOP Class (See
>>> <fo:basic-link internal-destination="sect_C.6">
>>> <fo:inline keep-with-next.within-line="always">
>>> Section C.6</fo:inline>
>>> </fo:basic-link>).</fo:block>
>>>
>>> But I am not sure that I really understand which is correct or whether
>>> or not fo/xref.xsl should be emitting
>>> 'keep-together.within-line="always"'
>>> without the need for a customization, or whether or not the problem
>>> is with xep and 'keep-with-next.within-line="always"' should have
>>> worked. Or whether there should be greater consistency between the
>>> output of the xref and the olink templates with respect to whether
>>> an <fo:inline/> should be used to wrap the content (and allow properties
>>> to be passed) or not.
>>>
>>> And using the parameter that prevents the line break does not prevent
>>> what
>>> seems to be the spurious space emitted after the text for the reference.
>>>
>>> David
>>>
>>> PS. Note that my quotes of the FO have been "tidy'd" to fit in this
>>> email
>>> and may not be exactly as written by the DocBook stylesheets and read
>>> by xep.
>>>
>>> PPS. The DocBook stylesheets I am using are docbook-xsl-ns-1.78.1, and
>>> the parameters and customizations are in the attached file.
>>
>>
>
>
>
!DSPAM:87,530668029851926747223!
_______________________________________________
(*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
(*) By using the Service, you expressly agree to these Terms of Service http://w
ww.renderx.com/terms-of-service.html
Received on Thu Feb 20 12:39:34 2014
This archive was generated by hypermail 2.1.8 : Thu Feb 20 2014 - 12:39:34 PST