RE: [docbook-apps] Font used for hyphenation-character

["David Cramer" <dcramer@motive.com>]

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:geraint@transitive.com] 
> 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:geraint@transitive.com]
> >> 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: 
> docbook-apps-unsubscribe@lists.oasis-open.org
> >> For additional commands, e-mail:
> >> docbook-apps-help@lists.oasis-open.org
> >>
> >>
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: 
> docbook-apps-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: docbook-apps-help@lists.oasis- 
> > open.org
> >
> 
>