[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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>↲</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 ↲ 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]