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

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

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
> 
>