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

[Geraint North <geraint@transitive.com>]

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