>>> 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+FontsThey are also mentioned in the xpdf (a non Adobe PDF reader) docs:
http://www.foolabs.com/xpdf/problems.htmlFont 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.