Ah - the use of multiple fonts might solve my problem in this instance - I'll give it a go.

Interesting that you used a pilcrow - that's what I used to start with, before I realised that it was the absolute worst symbol to use to indicate "there is no line break here" :-)

Geraint North
Principal Engineer
Transitive


On 27 Nov 2007, at 16:24, David Cramer wrote:

I believe it goes through that list trying to find a font that has a
particular character. I haven't bothered embedding zapf dingbats and
haven't heard any complaints since I started using that left arrow
character a year or so ago. Previously, when using an older version of
xep that didn't support multiple fonts, I'd been using a pilcrow since
it was in our monospace font.

David

-----Original Message-----
From: Geraint North [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 27, 2007 9:45 AM
To: David Cramer
Cc: Dave Pawson; Docbook Apps
Subject: Re: [docbook-apps] Font used for hyphenation-character

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>&#8626;</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 &#8626;
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]

Reply via email to