[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] semantics of "replaceable" element.
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@example.com 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 > firstname.lastname@example.org > > -------------------------------------------------- > From: "Stefan Seefeld" <email@example.com> > Sent: Monday, November 05, 2012 4:05 PM > To: "Richard Hamilton" <firstname.lastname@example.org> > Cc: "DocBook Apps Mailing List" <email@example.com> > 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: firstname.lastname@example.org >> For additional commands, e-mail: email@example.com >> >>