I think \ is fine for programlistings where the the code is a shell
script where you can escape new lines, but for other languages, I'm with
Geraint: you need something that's obviously NOT part of the code
listing. Here's what we do (using xep as our renderer):
<xsl:param name="body.font.family"
select="'CheltenhamCdITC,ZapfDingbats,LucidaSansUnicode'"/>
and
<xsl:attribute-set name="monospace.verbatim.properties"
use-attribute-sets="verbatim.properties monospace.properties">
<xsl:attribute name="text-align">start</xsl:attribute>
<xsl:attribute name="wrap-option">wrap</xsl:attribute>
<xsl:attribute name="hyphenation-character">
<xsl:choose>
<xsl:when test="@role and string-length(@role) =
1"><xsl:value-of select="@role"/></xsl:when>
<xsl:otherwise>↲</xsl:otherwise>
</xsl:choose>
</xsl:attribute>
<xsl:attribute name="font-size"><xsl:value-of
select="$motive.monospace.font.size"/></xsl:attribute>
</xsl:attribute-set>
Then in our document conventions section (for print output only) we have
a bullet item: "In multi-line code code listings the ↲ symbol
indicates that the text was wrapped for typographical reasons."
The <xsl:when test="@role and string-length(@role) = 1"> stuff is there
so that if you want to use a \ for a particular listing, you can do
<programlisting role="\">.
David
> -----Original Message-----
> From: Geraint North [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 27, 2007 6:33 AM
> To: Dave Pawson
> Cc: Docbook Apps
> Subject: Re: [docbook-apps] Font used for hyphenation-character
>
> >>> WHich assumes all your readers have that font available?
> >>>
> >>> the \ character is (IMHO) far more generally used for
> this purpose.
> >>> If you add a note as to its use prior to the first usage in the
> >>> document you may save trouble for readers and clarify any
> >>> misunderstandings.
> >> Yes - Zapf Dingbats is one of the 14 base fonts that are
> guaranteed
> >> to be available for PDF files - unless your experience suggests
> >> otherwise? It certainly always seems to have been fine for me.
> >
> > I find that surprising.
> > Guaranteed by whom? The acrobat reader? The PDF 'standard'?
> > What of people who use other readers?
> > I hadn't realised PDF files 'carried' fonts.
>
> The embedding of fonts into PDF is optional, but the PDF
> Standard lists fonts that are expected on the target system
> (the "Base 14" - essentially variants of Courier, Helvetica,
> Symbol, Times and Zapf Dingbats), and therefore don't need to
> be embedded. The FOP documentation contains a brief description:
>
> http://xmlgraphics.apache.org/fop/trunk/fonts.html#Base-14+Fonts
>
> They are also mentioned in the xpdf (a non Adobe PDF reader) docs:
>
> http://www.foolabs.com/xpdf/problems.html
>
> Font Book on the Mac (the font browsing utility) lists
> Courier, Helvetica, Symbol, Times and Zapf Dingbats in a
> "PDF" category, and come as part of the standard install.
>
> Now, this doesn't guarantee that everything will look
> correct, but that's not a problem with Zapf Dingbats - I've
> seen issues just using Times - I found that I had to disable
> ligatures in XEP because although the Times font on my Mac
> had the required ligature characters, the Base-14 fonts on
> our (reasonably old) Linux systems did not include them,
> resulting in incorrect rendering when viewed with non-Adobe
> readers on Linux. The alternative to disabling Ligatures is
> to embed the original font, and that's the approach I've
> taken with the Japanese versions of our documentation, which
> require fonts from the optional Adobe Font Pack to render correctly.
>
> > With such an odd character I guess you'll still have to
> explain it for
> > your readers? That is means the line continues... and
> should all be on
> > one line.
>
> I'd test it with my reviewers first, and see what they
> thought, but we do have a boilerplate "conventions used in
> this document" that we drop in at the start, so that wouldn't
> be the end of the world. I'm trying to ensure that there's
> no way for the continuation character to be confused with
> typed text, and using an untypeable character would be one
> way of making that clear.
>
> I do see your point, though - if established convention is
> that a '\'
> character is fine, and the readers are able to tell when the '\'
> indicates a line break and when it indicates a typed
> character, then that would be an acceptable solution.
>
> Thanks,
> Geraint.
>
>
>
> ---------------------------------------------------------------------
> 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]
