Aargh!
Setting 'keep-together.within-line="always"' has a very undesirable
side effect and that is to prevent wrapping of xrefs within tables,
leading long xref text to cause tables to overflow the page margins.
So that isn't a feasible workaround :(
David
On 2/20/14 6: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,530616af9853740918138!
_______________________________________________
(*) 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 06:52:35 2014
This archive was generated by hypermail 2.1.8 : Thu Feb 20 2014 - 06:52:36 PST