[xep-support] Undesirable line breaks after <fo:basic-link/> for internal but not external links.

From: David Clunie <dclunie@dclunie.com>
Date: Thu Feb 20 2014 - 03:44:09 PST

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&#160;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&#160;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&#160;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,5305eaaa9858512912002!

_______________________________________________
(*) 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 04:27:43 2014

This archive was generated by hypermail 2.1.8 : Thu Feb 20 2014 - 04:27:48 PST