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,530664ea9853476112746!
_______________________________________________
(*) 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:26:22 2014
This archive was generated by hypermail 2.1.8 : Thu Feb 20 2014 - 12:26:23 PST