Re: [docbook-apps] How to remove extra newline in programlisting

["Bob Stayton" <bobs@sagehill.net>]

Hi Jason,
This request has come up before, so maybe it is time for a real solution.

I discovered that the DocBook XSL stylesheets have three named utility templates for 
trimming leading and trailing newlines.  They are named 'trim-left', 'trim-right', and 
'trim.text', and they reside in the lib/lib.xsl stylesheet module.  But it seems they 
are not currently used in any templates that match content.

I worked up this customization using them, but I have not had much of a chance to test 
them.  If you or anyone else wouldn't mind testing them with a variety of 
programlistings and giving me feedback about them, I would appreciate it.  I left in 
xsl:message elements to indicate when each template is being used, which is useful 
during testing.  They would be removed or commented out in production.

There are three templates because programlisting allows element content as well as 
text content.  So the three templates apply when the first node is a text node (uses 
trim-left), the last node is a text node (uses trim-right), and when the 
programlisting contains a single node that is a text node (uses trim.text), 
respectively.


<!-- selects the programlisting's first node, if it is a text node, and if it has a 
following sibling (which means it is not the only node) -->
<xsl:template 
match="programlisting/node()[1][self::text()][following-sibling::node()]">
  <xsl:message>got here left</xsl:message>
  <xsl:call-template name="trim-left">
    <xsl:with-param name="contents" select="."/>
  </xsl:call-template>
</xsl:template>

<!-- selects the programlisting's last node, if it is a text node, and if it has a 
preceding sibling (which means it is not the only node) -->
<xsl:template match="programlisting/node()[position() = 
last()][self::text()][preceding-sibling::node()]">
  <xsl:message>got here right</xsl:message>
  <xsl:call-template name="trim-right">
    <xsl:with-param name="contents" select="."/>
  </xsl:call-template>
</xsl:template>

<!-- selects the programlistings first node that is also the last node, if it is a 
text node -->
<xsl:template match="programlisting/node()[position() = 1 and position() = 
last()][self::text()]"
              priority="1">
  <xsl:message>got here both</xsl:message>
  <xsl:call-template name="trim.text">
    <xsl:with-param name="contents" select="."/>
  </xsl:call-template>
</xsl:template>

If these are successful at deleting only leading and trailing newlines in 
programlisting, they could be incorporated into the next release of the stylesheets, 
probably with a parameter to turn them on or off (default would be off for backwards 
compatibility).

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


----- Original Message ----- 
From: "Jason Gilmore" <wj@wjgilmore.com>
To: <docbook-apps@lists.oasis-open.org>
Sent: Wednesday, October 13, 2010 6:35 AM
Subject: [docbook-apps] How to remove extra newline in programlisting


> Hi,
>
> Thanks to the great documentation and this mailing list's archive I've
> managed to complete a pretty straightforward transition from MS Word
> to Docbook. So far everything is working brilliantly.
>
> I am however running into a strange issue involving <programlisting>
> elements in which the enclosed text is delimited by <![CDATA[...]]>.
> When I convert from Docbook to PDF using oXygen (using the Saxon 6.5
> transformer), my program listing's include two extra newlines at the
> top and one at the bottom when the <programlisting>'s look like this:
>
> <programlisting>
> <![CDATA[
> <?php echo $this->layout()->content; ?>
> ]]>
> </programlisting>
>
> A newline only appears at the top of the rendered listing when the
> format looks like this:
>
> <programlisting><![CDATA[
> <?php echo $this->layout()->content; ?>
> ]]></programlisting>
>
> The only way I can remove the superfluous newlines at both the top and
> bottom is to format my program listings like this:
>
> <programlisting><![CDATA[<?php echo $this->layout()->content; ?>
> ]]></programlisting>
>
> As you can imagine, this is not ideal and opens up the possibility for
> inadvertent editing errors.
>
> Surely there is some way to fix this problem perhaps at the XSL
> transformation stage?
>
> Thank you!
> Jason
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>
>