[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Font used for hyphenation-character
In the end, I couldn't find an arrow quite how I liked, so I built my own font (using the open-source 'fontforge' application), and embedded it in the PDF. I also hacked the verbatim rendering to get the indentation I wanted. Overall, it was quite a painless process, but I am stunned at some of the more unusual symbols I came across when browsing the Unicode tables! Geraint North Principal Engineer Transitive On 27 Nov 2007, at 16:24, David Cramer wrote: > 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>↲</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 >>> >> >> > > --------------------------------------------------------------------- > 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]