That looks good - how does the
"CheltenhamCdITC,ZapfDingbats,LucidaSansUnicode" syntax work? What
does it indicate? I assume that it is controlling the proportional
font as well as the regular body font, which is why you are able to
use unicode characters in your hyphenation.
Do you then embed the fonts in your PDF, or are the documents only
distributed in paper form?
Thanks,
Geraint North
Principal Engineer
Transitive
On 27 Nov 2007, at 15:15, David Cramer wrote:
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]
open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
