I missed that this only happened when there was a sibling. The example I tried
only had one instance of replaceable embedded. When I added a second instance,
it worked exactly as Stefan describes. Sorry for any confusion.
To complete what I suspect Bob was going to suggest, you can add a template to
your customization that removes this behavior (the template below would do the
job).
I just looked at the stylesheets, and they include a parameter called
function.parens, which when set will take input of the following type:
<function>foo<replaceable>x</replaceable><replaceable>y</replaceable></function>
and render it as: foo(x, y).
The problem seems to be that the template for d:function checks this parameter,
but the template for d:function/d:replaceable (and d:function/d:parameter)
doesn't . The result when function.parens is set to 0 is inconsistent.
I think the following change would fix the problem for Stefan, and leave the
capability in for anyone who wants to use function.parens:
<xsl:template match="d:function/d:replaceable" priority="2">
<xsl:call-template name="inline.italicmonoseq"/>
<xsl:if test="$function.parens != '0' and following-sibling::*"> <!-- here
is the changed line -->
<xsl:text>, </xsl:text>
</xsl:if>
</xsl:template>
You'd need to do the same with d:function/d:parameter, too, though it appears
that parameter is not allowed inside function, so it may be a moot point.
Dick
-------
XML Press
XML for Technical Communicators
http://xmlpress.net
[email protected]
On Nov 5, 2012, at 5:13 PM, Bob Stayton wrote:
> I checked the archives, and apparently these templates that add a comma in
> the context of the function element were added very early in the XSL
> development, back in 2001. Given the variety of elements that function can
> contain, including indexterms,and the variety of contexts in which function
> can appear, including para, does anyone think these generated commas are
> appropriate? Are there more restricted contexts where they might be
> appropriate? If we eliminate the generated commas, would that mess up a lot
> of output?
>
> For now, I would suggest that you
>
> Bob Stayton
> Sagehill Enterprises
> [email protected]
>
> --------------------------------------------------
> From: "Stefan Seefeld" <[email protected]>
> Sent: Monday, November 05, 2012 4:05 PM
> To: "Richard Hamilton" <[email protected]>
> Cc: "DocBook Apps Mailing List" <[email protected]>
> Subject: Re: [docbook-apps] semantics of "replaceable" element.
>
>> On 11/05/2012 06:50 PM, Richard Hamilton wrote:
>>> Hi Stefan,
>>>
>>> I suspect the problem is in your customization. I just tried this with
>>> 1.77.1 (PDF and HTML), and there were no commas inserted in the output.
>>
>> Hi Richard,
>>
>> thanks for following up so quickly. I don't yet use a customization for
>> this. Please have a look at either the fo/inline.xsl or html/inline.xsl
>> stylesheets and look for the template matching
>> "d:function/d:replaceable". It does indeed add a comma if there is more
>> content after the replaceable element:
>>
>> <xsl:template match="d:function/d:replaceable" priority="2">
>> <xsl:call-template name="inline.italicmonoseq"/>
>> <xsl:if test="following-sibling::*">
>> <xsl:text>, </xsl:text>
>> </xsl:if>
>> </xsl:template>
>>
>> (In my docs I have things like
>> <function>vsip_<replaceable>d</replaceable>clip</function>, such that
>> the comma would be inserted between the 'd' and the 'clip'.
>>
>> Stefan
>>
>> --
>>
>> ...ich hab' noch einen Koffer in Berlin...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
