docbook-apps

Hi,

If I use e.g.

<xsl:template match="literal">
<xsl:text>\fB</xsl:text>
<xsl:apply-templates/>
<xsl:text>\fR</xsl:text>
</xsl:template>

in the customization layer for a manpage XSLT stylesheet, I get an
output of:

\efB...\efR

I'm wondering, what is so different to using

<xsl:template match="literal">
<xsl:apply-templates mode="bold" select="."/>
</xsl:template>

which results in \fB...\fR? I can reproduce this issue with the latest
release, but not with the latest snapshot. I'm wondering, what's causing
this (different) behaviour? Can someone point me into the right
direction?

Regards, Daniel

Daniel Leidert wrote:
> Hi,
>
> If I use e.g.
>
> <xsl:template match="literal">
> <xsl:text>\fB</xsl:text>
> <xsl:apply-templates/>
> <xsl:text>\fR</xsl:text>
> </xsl:template>
>
> in the customization layer for a manpage XSLT stylesheet, I get an
> output of:
>
> \efB...\efR
>
> I'm wondering, what is so different to using
>
> <xsl:template match="literal">
> <xsl:apply-templates mode="bold" select="."/>
> </xsl:template>
>
> which results in \fB...\fR? I can reproduce this issue with the latest
> release, but not with the latest snapshot. I'm wondering, what's causing
> this (different) behaviour? Can someone point me into the right
> direction?

Which difference are you referring to? The difference between releases?

Or the difference between the output from your two examples? (The
output for both looks reasonable to me.)

Am Montag, den 19.03.2007, 18:41 -0500 schrieb Paul DuBois:
> Daniel Leidert wrote:
> > Hi,
> >
> > If I use e.g.
> >
> > <xsl:template match="literal">
> > <xsl:text>\fB</xsl:text>
> > <xsl:apply-templates/>
> > <xsl:text>\fR</xsl:text>
> > </xsl:template>
> >
> > in the customization layer for a manpage XSLT stylesheet, I get an
> > output of:
> >
> > \efB...\efR
> >
> > I'm wondering, what is so different to using
> >
> > <xsl:template match="literal">
> > <xsl:apply-templates mode="bold" select="."/>
> > </xsl:template>
> >
> > which results in \fB...\fR? I can reproduce this issue with the latest
> > release, but not with the latest snapshot. I'm wondering, what's causing
> > this (different) behaviour? Can someone point me into the right
> > direction?
>
> Which difference are you referring to? The difference between releases?

No. Between the output of both examples. Releases may differ in
behaviour of course :)

> Or the difference between the output from your two examples? (The
> output for both looks reasonable to me.)

They do not look reasonable to me. But I found it. In the 1.72.0
release, the mode="bold" template used

"▓fB"

to avoid the substitution (by the substitution map). This explains the
different behaviour. It would have been nice to announce it in the
Release Notes. But I cannot find a special note there.

Regards, Daniel

Daniel Leidert wrote:
> Am Montag, den 19.03.2007, 18:41 -0500 schrieb Paul DuBois:
>> Daniel Leidert wrote:
>>> Hi,
>>>
>>> If I use e.g.
>>>
>>> <xsl:template match="literal">
>>> <xsl:text>\fB</xsl:text>
>>> <xsl:apply-templates/>
>>> <xsl:text>\fR</xsl:text>
>>> </xsl:template>
>>>
>>> in the customization layer for a manpage XSLT stylesheet, I get an
>>> output of:
>>>
>>> \efB...\efR
>>>
>>> I'm wondering, what is so different to using
>>>
>>> <xsl:template match="literal">
>>> <xsl:apply-templates mode="bold" select="."/>
>>> </xsl:template>
>>>
>>> which results in \fB...\fR? I can reproduce this issue with the latest
>>> release, but not with the latest snapshot. I'm wondering, what's causing
>>> this (different) behaviour? Can someone point me into the right
>>> direction?
>> Which difference are you referring to? The difference between releases?
>
> No. Between the output of both examples. Releases may differ in
> behaviour of course :)
>
>> Or the difference between the output from your two examples? (The
>> output for both looks reasonable to me.)
>
> They do not look reasonable to me.

Which output looks unreasonable, and what were you expecting instead?

I would expect a literal "\" to come out as "\\" or "\e" ("\e"
preferably), and I would expect markup instructions such as "bold"
to produce something like \fB ... \fR, which is what you're showing
above.


> But I found it. In the 1.72.0
> release, the mode="bold" template used
>
> "▓fB"
>
> to avoid the substitution (by the substitution map). This explains the
> different behaviour. It would have been nice to announce it in the
> Release Notes. But I cannot find a special note there.
>
> Regards, Daniel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>

Daniel Leidert <daniel.leidert.spam@gmx.net>, 2007-03-20 01:29 +0100:

> In the 1.72.0 release, the mode="bold" template used
>
> "▓fB"
>
> to avoid the substitution (by the substitution map). This explains the
> different behaviour. It would have been nice to announce it in the
> Release Notes. But I cannot find a special note there.

I thought I had put preserved the checkin description for it in
the release notes but I guess I didn't.

Anyway, the complete description for the change (and for all
changes made between the 1.71.1 and 1.72.0. releases) is in the
NEWS file:

http://docbook.sourceforge.net/release/xsl/current/NEWS.html#V1.72.0_Manpages

To quote from that:

Adjusted manpages stylesheet to use U+2593 as the internal
representation for the backslash character within the
stylesheet. This prevents backslashes in source content from
getting eaten.

But note that that change (and some related changes I made for the
1.72.0 release) was a misguided experiment. It ended up resulting
in prohibitively huge memory consumption for transformations of
certain documents.

So I have since reverted to a simpler and less memory-hungry way
of handling the escaping of backslash, dot, dash, and apostrophe
(which all have special meaning in roff source in certain
circumstances). So the next release will not have the "▓fB"
stuff.

--Mike

Daniel Leidert <daniel.leidert.spam@gmx.net>, 2007-03-20 00:31 +0100:

> If I use e.g.
>
> <xsl:template match="literal">
> <xsl:text>\fB</xsl:text>
> <xsl:apply-templates/>
> <xsl:text>\fR</xsl:text>
> </xsl:template>

Better to use the following:

<xsl:template match="literal">
<xsl:if test="$man.hyphenate.computer.inlines = 0">
<xsl:call-template name="suppress.hyphenation"/>
</xsl:if>
<xsl:apply-templates mode="bold" select="."/>
</xsl:template>

If you look at the manpages source (for example, the
manpages/inline.xsl file), you’ll notice that’s the way boldfacing
of similar elements is handled.

That’s also why I put the following big comment in the source of
the utility.xsl file where the template@mode=bold template is -













> in the customization layer for a manpage XSLT stylesheet, I get an
> output of:
>
> \efB...\efR
>
> I'm wondering, what is so different to using
>
> <xsl:template match="literal">
> <xsl:apply-templates mode="bold" select="."/>
> </xsl:template>
>
> which results in \fB...\fR? I can reproduce this issue with the latest
> release, but not with the latest snapshot. I'm wondering, what's causing
> this (different) behaviour? Can someone point me into the right
> direction?

So I guess (see my previous reply) you know now that what you were
running into was a (misguided) change I made for the 1.72.0 (that
is, using U+2593 as an internal representation for backslashes).
But I have since reverted that change, so your original
customization will work as expected with the latest snapshot.

But I recommend using the template@mode=bold mechanism instead.

\Mike

Am Donnerstag, den 22.03.2007, 16:30 +0900 schrieb Michael(tm) Smith:
> Daniel Leidert <daniel.leidert.spam@gmx.net>, 2007-03-20 00:31 +0100:
>
> > If I use e.g.
> >
> > <xsl:template match="literal">
> > <xsl:text>\fB</xsl:text>
> > <xsl:apply-templates/>
> > <xsl:text>\fR</xsl:text>
> > </xsl:template>
>
> Better to use the following:
>
> <xsl:template match="literal">
> <xsl:if test="$man.hyphenate.computer.inlines = 0">
> <xsl:call-template name="suppress.hyphenation"/>
> </xsl:if>
> <xsl:apply-templates mode="bold" select="."/>
> </xsl:template>
>
> If you look at the manpages source (for example, the
> manpages/inline.xsl file), you’ll notice that’s the way boldfacing
> of similar elements is handled.

Thanks for the hint, but I already found that. The cited code is from
another project, which had broken manpages now. I already suggested your
code to avoid the broken manpage output ;) I was just wondering, why the
using this worked, but using <xsl:text>\fB</xsl:text> did not. I just
oversaw, that you used the unicode code to represent the backslash in
the mode="bold" template, which explains the difference.

Regards, Daniel