% $Id: faq-hyp+pdf.tex,v 1.5 2011/12/24 23:13:57 rf10 Exp rf10 $ \section{Hypertext and \acro{PDF}} \Question[Q-acrobat]{Making \acro{PDF} documents from \AllTeX{}} There are three general routes to \acro{PDF} output: Adobe's original `distillation' route (via \PS{} output), direct conversion of a \acro{DVI} file, and the use of a direct \tex{}-like \acro{PDF} generator such as \Qref*{\PDFTeX{}}{Q-whatpdftex}. For simple documents (with no hyper-references), you can either \begin{itemize} \item process the document in the normal way, produce \PS{} output and distill it; \item (on a Windows or Macintosh machine with appropriate tools installed) pass the output through a \acro{PDF}writer in place of a printer driver. This route is only appropriate for simple documents: \acro{PDF} writers cannot create hyperlinks; \item process the document with ``vanilla'' \latex{} and generate \acro{PDF} direct from the \acro{DVI} using \ProgName{dvipdfm}/\ProgName{dvipdfmx}; or \item process the document direct to \acro{PDF} with \PDFTeX{}, \Qref{\luatex{}}{Q-luatex}, \Qref{\xetex{}}{Q-xetex} or V\TeX{}. \PDFTeX{}, \luatex{} and \xetex{} have the advantage of availability for a wide range of platforms, but V\TeX{} is available only for Windows (as a commercial product), or free of charge, but unsupported, for Linux or \acro{OS/}2. \end{itemize} To translate all the \LaTeX{} cross-referencing into Acrobat links, you need a \LaTeX{} package to redefine the internal commands. There are two of these for \LaTeX{}, both capable of conforming to the \Qref{Hyper\TeX{} specification}{Q-hyper}: Heiko Oberdiek's \Package{hyperref}, and Michael Mehlich's \Package{hyper}. (In practice, almost everyone uses \Package{hyperref}; \Package{hyper} hasn't been updated since 2000.) \Package{Hyperref} can often determine how it should generate hypertext from its environment, but there is a wide set of configuration options you can give via \csx{usepackage}. The package can operate using \PDFTeX{} primitives, the hyper\TeX{} \csx{special}s, or \acro{DVI} driver-specific \csx{special} commands. Both \ProgName{dvips} and \YandY{}'s \acro{\ProgName{DVIPSONE}} can translate the \acro{DVI} with these \csx{special} commands into \PS{} acceptable to Distiller, and \ProgName{dvipdfm} and \ProgName{dvipdfmx} have \csx{special} commands of their own. If you use \plaintex{}, the \Qref*{\Eplain{} macros}{Q-eplain} can help you create \acro{PDF} documents with hyper-references. It can operate using \PDFTeX{} primitives, or \csx{special} commands for the \ProgName{dvipdfm}/\ProgName{dvipdfmx} \acro{DVI} drivers. While there is no free implementation of all of \ProgName{Adobe} \ProgName{Distiller}'s functionality, any but the very oldest versions of \ProgName{Ghostscript} provide pretty reliable distillation (but beware of the problems with \Qref*{\ProgName{dvips} output for distillation}{Q-dvips-pdf}). For viewing (and printing) the resulting files, Adobe's \ProgName{Acrobat} \ProgName{Reader} is available for a fair range of platforms; for those for which Adobe's reader is unavailable, remotely current versions of \ProgName{ghostscript} combined with \ProgName{gv} or \ProgName{GSview} can display and print \acro{PDF} files, as can \ProgName{xpdf}. In many circumstances, \ProgName{Ghostscript} combined with a viewer application is actually preferable to Acrobat Reader. For example, on Windows Acrobat Reader locks the \extension{pdf} file it's displaying: this makes the traditional (and highly effective) \AllTeX{} development cycle of ``Edit\arrowhyph{}Process\arrowhyph{}Preview'' become rather clumsy~--- \ProgName{GSview} doesn't make the same mistake. \begin{ctanrefs} \item[\nothtml{\rmfamily}Acrobat Reader]download from \URL{http://get.adobe.com/reader} \item[dvipdfm]\CTANref{dvipdfm} \item[dvipdfmx]\CTANref{dvipdfmx} \item[ghostscript]Browse \CTANref{ghostscript} \item[GSview]Browse \CTANref{gsview} \item[gv]Browse \CTANref{gv} \item[hyper.sty]\CTANref{hyper} \item[hyperref.sty]\CTANref{hyperref} \end{ctanrefs} \LastEdit{2012-03-28} \Question[Q-hyper]{Making hypertext documents from \TeX{}} If you want on-line hypertext with a \AllTeX{} source, probably on the World Wide Web, there are four technologies to consider: \begin{itemize} \item start from \alltex{}, and use one of a number of techniques to translate (more or less) directly to \Qref{\acro{HTML}}{Q-LaTeX2HTML}; % beware line break \item Start from \Qref*{\Package{texinfo}}{Q-texinfo} source, and use the \ProgName{info} viewer, or convert the \Package{texinfo} source to \acro{HTML} using \ProgName{texi2html}; \item Start from \alltex{}; use \pdftex{}, \xetex{} or \luatex{} to produce \acro{PDF}, using \Package{hyperref} to construct hyperlinks. \item Start from (unconventional) \alltex{} which use the % ! line break \Qref*{hyper\TeX{} conventions}{Q-hypertex}. \end{itemize} \begin{ctanrefs} \item[texinfo]\CTANref{texinfo} \end{ctanrefs} \Question[Q-hypertex]{The \emph{hyper\tex{}} project} The \emph{hyper\tex{}} project extended the functionality of all the \LaTeX{} cross-referencing commands (including the table of contents) to produce \csx{special} commands which are parsed by \acro{DVI} processors conforming to the Hyper\TeX{} guidelines; it provides general hypertext links, including those to external documents. The Hyper\TeX{} specification says that conformant viewers/translators must recognize the following set of \csx{special} commands: \begin{description} \item[href:] |html:| \item[name:] |html:| \item[end:] |html:| \item[image:] |html:| \item[base\_name:] |html:| \end{description} The \emph{href}, \emph{name} and \emph{end} commands are used to do the basic hypertext operations of establishing links between sections of documents. Further details are available on \URL{http://arXiv.org/hypertex/}; there are two commonly-used implementations of the specification, a modified \ProgName{xdvi} and (recent releases of) \ProgName{dvips}. Output from the latter may be used in recent releases of \ProgName{ghostscript} or Acrobat Distiller. \Question[Q-dvips-pdf]{Quality of \acro{PDF} from \PS{}} \keywords{blurry fuzzy crippled} Any reasonable \PS{}, including any output of \ProgName{dvips}, may be converted to \acro{PDF}, using (for example) a sufficiently recent version of \ProgName{ghostscript}, Frank Siegert's (shareware) \href{http://www.pstill.com/}{\ProgName{PStill}}, or Adobe's (commercial) \ProgName{Distiller}. But, although the job may (almost always) be done, the results are often not acceptable: the most frequent problem is bad presentation of the character glyphs that make up the document. The following answers offer solutions to this (and other) problems of bad presentation. Issues covered are: \begin{itemize} \item \Qref*{Wrong type of fonts used}{Q-fuzzy-type3}, which is the commonest cause of fuzzy text. \item \Qref*{\ProgName{Ghostscript} too old}{Q-fuzzy-gs}, which can also result in fuzzy text. % beware line breaks \item \Qref*{Switching to font encoding \acro{T}1 encoding}{Q-fuzzy-T1}, which is yet another possible cause of fuzzy text. \item Another problem~--- missing characters~--- arises from an % beware line breaks \Qref*{aged version of \ProgName{Adobe}~\ProgName{Distiller}}{Q-distill-prob}. \item Finally, there's the common confusion that arises from using the \ProgName{dvips} configuration file \texttt{-Ppdf}, the % ! line br \Qref*{weird characters}{Q-charshift}. \end{itemize} It should be noted that \ProgName{Adobe} % \ProgName{Acrobat} no longer % part of the name \ProgName{Reader}~6 (released in mid-2003, and later versions) does not exhibit the ``fuzziness'' that so many of the answers below address. This is of course good news: however, it will inevitably be a long time before every user in the world has this (or later) versions, so the remedies below are going to remain for some time to come. The problems are also discussed, with practical examples, in Mike Shell's \Package{testflow} package, which these FAQs recommend as a ``\Qref*{specialised tutorial}{Q-tutbitslatex}. \begin{ctanrefs} \item[testflow]\CTANref{testflow} \end{ctanrefs} \Question[Q-fuzzy-type3]{The wrong type of fonts in \acro{PDF}} \keywords{crippled blurry} This is far the commonest problem: the symptom is that text in the document looks ``fuzzy''. Most people use \ProgName{Adobe} \ProgName{Acrobat} \ProgName{Reader} to view their \acro{PDF}: \ProgName{Reader} is distributed free of charge, and is widely available, for all its faults. One of those faults is its failure to deal with bitmap fonts (at least, in all versions earlier than version~6, all of which copies are pretty old, now~\dots{} but some are occasionally found). So we don't want bitmap fonts in our \PS{}: with them, characters show up in \ProgName{Reader}'s display as blurred blobs which are often not even recognisable as the original letter, and are often not properly placed on the line. Nevertheless, even now, most \TeX{} systems have \ProgName{dvips} configured to use \Qref*{\extension{pk} files}{Q-pk} in its output. Even \PDFTeX{} will use \extension{pk} files if it can see no alternative for a font in the document it is processing. Our remedy is to use ``\Qref*{Adobe Type~1}{Q-adobetypen}'' versions of the fonts we need. Since Adobe are in the business of selling Type~1 fonts, \ProgName{Reader} was of course made to deal with them really rather well, from the very beginning. Of course, if your document uses nothing but fonts that came from Adobe in the first place~--- fonts such as \FontName{Times} that appear in pretty much every \PS{} printer, or such as Adobe \FontName{Sabon} that you pay extra for~--- then there's no problem. But most people use \FontName{Computer} \FontName{Modern} to start with, and even those relative sophisticates who use something as exotic as \ProgName{Sabon} often find themselves using odd characters from \acro{CM} without really intending to do so. Fortunately, rather good versions of the \acro{CM} fonts are available from the \acro{AMS} (who have them courtesy of % ! line break \Qref{Blue Sky Research}{Q-commercial} and \YandY{}). Most modern systems have the fonts installed ready to use; and any system installed less than 3~years ago has a \ProgName{dvips} configuration file `\texttt{pdf}' that signals the use of the \acro{CM} fonts, and also sets a few other parameters to improve \ProgName{dvips}' output. Use this configuration as: \begin{quote} \begin{verbatim} dvips -Ppdf myfile -o myfile.ps \end{verbatim} \end{quote} This may produce a warning message about failing to find the configuration file: \begin{quote} \begin{verbatim} dvips: warning: no config file for `pdf' \end{verbatim} \end{quote} or something similar, or about failing to find a font file: \begin{quote} \begin{verbatim} dvips: ! Couldn't find header file cmr10.pfb \end{verbatim} \end{quote} Either of these failures signals that your system doesn't have the fonts in the first place. A way of using the fonts that doesn't involve the sophistication of the \texttt{-Ppdf} mechanism is simply to load maps: \begin{quote} \begin{verbatim} dvips -Pcmz -Pamz myfile -o myfile.ps \end{verbatim} \end{quote} You may encounter the same warning messages as listed above. If your system does not have the fonts, it won't have the configuration file either; however, it might have the configuration file without the fonts. In either case, you need to \Qref*{install the fonts}{Q-inst1cm}. \Question[Q-fuzzy-gs]{Fuzzy fonts because \ProgName{Ghostscript} too old} \keywords{crippled blurry} So you've done everything the \acro{FAQ} has told you that you need, correct fonts properly installed and appearing in the \ProgName{dvips} output, but \emph{still} you get fuzzy character output after distilling with \ProgName{ghostscript}. The problem could arise from too old a version of \ProgName{ghostscript}, which you may be using directly, or via a script such as \ProgName{ps2pdf} (distributed with \ProgName{ghostscript} itself), \ProgName{dvipdf}, or similar. Though \ProgName{ghostscript} was capable of distillation from version~5.50, that version could only produce bitmap Type~3 output of any font other than the fundamental 35~fonts (\FontName{Times}, \FontName{Helvetica}, etc.). Later versions added `complete' distillation, but it wasn't until version~6.50 that one could rely on it for everyday work. So, if your \acro{PDF} output still looks fuzzy in \ProgName{Acrobat} \ProgName{Reader}, upgrade \ProgName{ghostscript}. The new version should be at least version~6.50, of course, but it's usually good policy to go to the most recent version (version~8.12 at the time of writing~--- 2003). \Question[Q-fuzzy-T1]{Fonts go fuzzy when you switch to \acro{T}1} \keywords{crippled blurry} You've been having problems with hyphenation, and someone has suggested that you should use ``\cmdinvoke{usepackage}[T1]{fontenc}'' to help sort them out. Suddenly you find that your final \acro{PDF} has become fuzzy. The problem may arise whether you are using \PS{} output and then distilling it, or you are using \PDFTeX{} for the whole job. In fact, this is the same problem as most others about the \Qref*{quality of \acro{PDF}}{Q-dvips-pdf}: you've abandoned your previous setup using Type~1 versions of the \acro{CM} fonts, and \ProgName{dvips} has inserted Type~3 versions of the \acro{EC} fonts into your document output. (See % beware line break ``\Qref*{Adobe font types}{Q-adobetypen} for details of these font types; also, note that the font \emph{encoding}~\acro{T}1 has nothing directly to do with the font \emph{format}~Type~1). However, as noted in % beware line break \htmlonly{``}\Qref[question]{8-bit Type~1 fonts}{Q-type1T1}\htmlonly{''}, Type~1 versions of \acro{CM}-like fonts in \acro{T}1 (or equivalent) encoding are now available, both as ``real'' fonts, and as virtual font sets. One solution, therefore, is to use one of these alternatives. The alternative is to switch font family altogether, to something like \FontName{Times} (as a no-thought default) or one of the many more pleasing Adobe-encoded fonts. The default action of \Package{fontinst}, when creating metrics for such a font, is to create settings for both \acro{OT}1 and \acro{T}1 encodings, so there's little change in what goes on (at the user level) even if you have switched to \acro{T}1~encoding when using the fonts. \Question[Q-distill-prob]{Characters missing from \acro{PDF} output} If you're using \ProgName{Acrobat} \ProgName{Distiller} to create your \acro{PDF} output, you may find characters missing. This may manifest itself as messed-up maths equations (missing ``\latexhtml{\ensuremath{-}}{-}'' signs, for example), or bits missing from large symbols. Early versions of \ProgName{Distiller} used to ignore character positions 0--31 and 128--159 of every font: Adobe's fonts never use such positions, so why should \ProgName{Distiller}? Well, the answer to this question is ``because Adobe don't produce all the world's fonts''~--- fonts like \FontName{Computer} \FontName{Modern} were around before Adobe came on the scene, and \emph{they} use positions 0--31. Adobe don't react to complaints like that in the previous sentence, but they do release new versions of their programs; and \ProgName{Distiller}, since at least version~4.0, \emph{has} recognised the font positions it used to shun. Meanwhile, \TeX{} users with old versions of \ProgName{Distiller} need to deal with their fonts. \ProgName{Dvips} comes to our aid: the switch \texttt{-G1} (``remap characters''), which moves the offending characters out of the way. The \acro{PDF} configuration file (\texttt{-Ppdf}), recommended % beware line break \latexhtml{above}{in ``\Qref{the wrong type of fonts}{Q-fuzzy-type3}''}, includes the switch. The switch is not without its problems; pre-2003 versions of \ProgName{dvips} will apply it to Adobe fonts as well, causing \Qref*{havoc}{Q-charshift}, but fortunately that problem is usually soluble. However, a document using both \acro{CM} and Adobe-specified fonts is stuck. The only real solution is either to upgrade \ProgName{dvips}, or to spend money to upgrade \ProgName{Distiller}. \Question[Q-type1T1]{Finding `8-bit' Type~1 fonts} \keywords{eight} Elsewhere, answers to these \acro{FAQ}s recommend that you use an `8-bit' font to permit % line break!! \Qref*{accentuation of inflected languages}{Q-hyphenaccents}, and also recommend the use of Type~1 fonts to ensure that you get \Qref*{good quality \acro{PDF}}{Q-fuzzy-type3}. These recommendations used to be contradictory: one could not just ``switch'' from the free \acro{CM} fonts to free Cork- (or similarly) encoded Type~1 fonts. The first approach that started to alleviate these problems, was the development of virtual fonts that make a good approach to the Cork encoding (see below). Now, however, we have ``true'' Type~1 fonts available: as always, we have an embarrassment of riches with three free alternatives, and one commercial and one shareware version. \Package{CM-super} is an auto-traced set which encompasses all of the \acro{T}1 and \acro{TS}1 encodings as well as the \acro{T}2* series (the family of encodings that cover languages based on Cyrillic alphabets). These fonts are pretty easy to install (the installation instructions are clear), but they are huge: don't try to install them if you're short of disc space. \Package{CM-LGC} is a similar ``super-font'' set, but of much more modest size; it covers \acro{T}1, \acro{TS}1 and \acro{T}2{A} encodings (as does \Package{CM-super}, and also covers the \acro{LGR} encoding (for typesetting Greek, based on Claudio Beccari's \MF{} sources). \Package{CM-LGC} manages to be small by going to the opposite extreme from \Package{CM-super}, which includes fonts at all the sizes supported by the original \acro{EC} (a huge range); \Package{CM-LGC} has one font per font shape, getting other sizes by scaling. There is an inevitable loss of quality inherent in this approach, but for the disc-space-challenged machine, \Package{CM-LGC} is an obvious choice. \Package{Tt2001} is a simple scan of the \acro{EC} and \acro{TC} fonts, and has some virtues~--- it's noticeably smaller than \Package{CM-super} while being less stark than \Package{CM-LGC}. \Package{Latin} \Package{Modern} is produced using the program \Qref*{\ProgName{MetaType1}}{Q-textrace}. The \Package{Latin} \Package{Modern} set comes with \acro{T}1, \acro{TS}1 \acro{LY}1 encoded variants (as well as a variant using the Polish \acro{QX} encoding); for the glyph set it covers, its outlines seem rather cleaner than those of \Package{CM-super}. \Package{Latin} \Package{Modern} is more modest in its disc space demands than is \Package{CM-super}, while not being nearly as stark in its range of design sizes as is \Package{CM-LGC}~--- \Package{Latin} \Package{Modern}'s fonts are offered in the same set of sizes as the original \Package{CM} fonts. It's hard to argue with the choice: Knuth's range of sizes has stood the test of time, and is one of the bases on which the excellence of the \TeX{} system rests. \Qref*{Virtual fonts}{Q-virtualfonts} help us deal with the problem, since they allow us to map ``bits of \acro{DVI} file'' to single characters in the virtual font; so we can create an ``\'e'' character by recreating the \acro{DVI} commands that would result from the code ``\csx{'}\texttt{e}''. However, since this involves two characters being selected from a font, the arrangement is sufficient to fool \ProgName{Acrobat} \ProgName{Reader}: you can't use the program's facilities for searching for text that contains inflected characters, and if you \emph{cut} text from a window that contains such a character, you'll find something unexpected (typically the accent and the `base' characters separated by a space) when you \ProgName{paste} the result. However, if you can live with this difficulty, virtual fonts are a useful and straightforward solution to the problem. There are two virtual-font offerings of \acro{CM}-based 8-bit fonts~--- the \Package{ae} (``almost \acro{EC}'') and \Package{zefonts} sets; the \Package{zefonts} set has wider coverage (though the \Package{ae} set may be extended to offer guillemets by use of the \Package{aeguill} package). Neither offers characters such as \texttt{eth} and \texttt{thorn} (used in, for example, in Icelandic), but the \Package{aecompl} package works with the \Package{ae} fonts to provide the missing characters from the \acro{EC} fonts (i.e., as bitmaps). The sole remaining commercial \acro{CM}-like 8-bit font comes from Micropress, who offer the complete \acro{EC} set in Type~1 format, as part of their range of outline versions of fonts that were originally distributed in \MF{} format. See \Qref[question]{``commercial distributions''}{Q-commercial}. The shareware % ! line break \Qref*{BaKoMa \TeX{} distribution}{Q-TeXsystems} offers a set of Type~1 \acro{EC} fonts, as an extra shareware option. (As far as the present author can tell, these fonts are \emph{only} available to users of BaKoMa \TeX{}: they are stored in an archive format that seems not to be publicly available.) Finally, you can use one of the myriad text fonts available in Type~1 format (with appropriate \acro{PSNFSS} metrics for \acro{T}1 encoding, or metrics for some other 8-bit encoding such as \acro{LY}1). However, if you use someone else's text font (even something as simple as Adobe's Times family) you have to find a matching family of mathematical fonts, which is a non-trivial undertaking~--- \htmlonly{see }\Qref{``choice of scalable fonts''}{Q-psfchoice}. \begin{ctanrefs} \item[\nothtml{\rmfamily}ae fonts]\CTANref{ae} \item[aecompl.sty]Distributed with \CTANref{ae} \item[aeguill.sty]\CTANref{aeguill} \item[\nothtml{\rmfamily}BaKoMa fonts]Browse \CTANref{bakoma-texfonts} \item[\nothtml{\rmfamily}CM-LGC fonts]\CTANref{cm-lgc} \item[\nothtml{\rmfamily}CM-super fonts]\CTANref{cm-super} (beware: very large download) \item[\nothtml{\rmfamily}Latin Modern fonts]\CTANref{lm} \item[\nothtml{\rmfamily}tt2001 fonts]\CTANref{tt2001} \item[\nothtml{\rmfamily}zefonts]\CTANref{zefonts} \end{ctanrefs} \Question[Q-pkfix]{Replacing Type 3 fonts in \PS{}} One often comes across a \PS{} file generated by \ProgName{dvips} which contains embedded \acro{PK} fonts; if you try to generate \acro{PDF} from such a file, the quality will be poor. Of course, the proper solution is to regenerate the \PS{} file, but if neither the sources nor the \acro{DVI} file are available, one must needs resort to some sort of patching to replace the bitmap fonts in the file by outline fonts. The program \ProgName{pkfix} (by Heiko Oberdiek) will do this patching, for files created by ``not too old versions'' of \ProgName{dvips}: it finds the fonts to be replaced by examining the \PS{} comments \ProgName{dvips} has put in the file. For each font, \ProgName{pkfix} puts appropriate \TeX{} commands in a file, which it then processes and runs through \ProgName{dvips} (with switch \texttt{-Ppdf}) to acquire an appropriate copy of the font; these copies are then patched back into the original file. If your source file is older than \ProgName{pkfix} can deal with, there's still a modicum of hope: \ProgName{pkfix-helper} examines the bitmap fonts in a document, compares them with the metric (\extension{tfm}) fonts on your system and comes to a view of which font might be which. The program reports on ``poor'' matches, and there are options for confirming, or replacing, its guesses. The technique (which sounds implausible) is successful enough to be worth a try. A further option is Frank Siegert's (shareware) \href{http://www.pstill.com}{PStill}, which is capable of processing the \PS{} it is distilling, and one option is to replace bitmap fonts in the file with Type~1 versions. \begin{ctanrefs} \item[pkfix]\CTANref{pkfix} \item[pkfix-helper]\CTANref{pkfix-helper} \end{ctanrefs} \Question[Q-pdfpagelabels]{\Package{Hyperref} and repeated page numbers} The \Class{book} class (and its friends and relations) automatically changes the display of page numbers in the frontmatter of the document to lower-case roman. This is fine for human readers, but if \Package{hyperref} has been misconfigured, the existence of pages have the same page number can cause problems. Fortunately, the configuration options to make \Package{hyperref} ``do the right thing'' are (by default) set up to avoid problems. The two options in question are: \begin{description} \item[\pkgoption{plainpages=false}] Make page anchors using the formatted form of the page number. With this option, \Package{hyperref} writes different anchors for pages `ii' and `2'. (This is the default value for the option, which is a % ! line break \emph{good thing}\dots) If the option is set `\texttt{true}' \Package{hyperref} writes page anchors as the arabic form of the page number, rather than the formatted form that gets printed; this is not usually appropriate. \item[\pkgoption{pdfpagelabels}] Set \acro{PDF} page labels; i.e., write the value of \csx{thepage} to the \acro{PDF} file so that \Package{Acrobat Reader} can display the page number as (say) `ii (4 of 40)' rather than simply `4 of 40'. \end{description} The two should be used whenever page numbering is not just `1\texttt{..}\ensuremath{n}'; they may be used independently, but usually are not. The recipe isn't perfect: it relies on \csx{thepage} being different for every page in the document. A common problem arises when there is an unnumbered title page, after which page numbers are reset: the \PDFTeX{} warning of ``\Qref*{duplicate destinations}{Q-hyperdupdest}'' will happen in this case, regardless of the options. \begin{ctanrefs} \item[hyperref.sty]\CTANref{hyperref} \end{ctanrefs} \Question[Q-srchpdf]{Searching \acro{PDF} files} In principle, you can search a \acro{PDF} file: the text of the file is available to the viewer, and at least some viewers provide a search facility. (It's not the fastest thing in the world, but it does help in some circumstances.) However, there is a problem: the viewer wants to look at Unicode text, but no ordinary \TeX{}-based system deals in Unicode text. Fortunately for us Anglophones, this is is hardly ever a problem for our text, since even Knuth's ``\acro{OT}1'' encoding matches ASCII (and hence the lowest 128 characters of Unicode) for most things printable. However, using the inflected characters of Continental European languages, or anything that doesn't use a Latin alphabet, there is potential for problems, since \TeX{}'s view of what a font is doesn't map \acro{PDF}'s and the reader won't understand\dots{} \dots{} Unless you use the \Package{cmap} package with \PDFLaTeX{}, that is. The package will instruct \PDFTeX{} to load character maps into your \acro{PDF} for output fonts encoded according to the \acro{T}1 (Western European Languages), T2A, T2B, or T2C (Cyrillic Languages), or T5 (Vietnamese) encodings. If your document uses such encodings, viewers that can search will use the maps to interpret what they find in the file. Unfortunately, the package only works with fonts that are directly encoded, such as the \FontName{cm-super} distribution. Fonts like Adobe Times Roman (which are encoded for \AllTeX{} use via virtual fonts) are not amenable to this treatment. \begin{ctanrefs} \item[cmap.sty]\CTANref{cmap} \item[cm-super \nothtml{\rmfamily}fonts]\CTANref{cm-super} \end{ctanrefs} % \Question[Q-hypertex]{The Hyper\tex{} project} % % The Hyper\TeX{} project extended the functionality of all the % \LaTeX{} cross-referencing commands (including the table of contents) % to produce \csx{special} commands which are parsed by \acro{DVI} processors % conforming to the Hyper\TeX{} guidelines; % it provides general hypertext links, including those % to external documents. % % The Hyper\TeX{} specification says that conformant viewers/translators % must recognize the following set of \csx{special} commands: % \begin{description} % \item[href:] |html:| % \item[name:] |html:| % \item[end:] |html:| % \item[image:] |html:| % \item[base\_name:] |html:| % \end{description} % % The \emph{href}, \emph{name} and \emph{end} commands are used to do % the basic hypertext operations of establishing links between sections % of documents. % % Further details are available on \URL{http://arXiv.org/hypertex/}; there % are two commonly-used implementations of the specification, a % modified \ProgName{xdvi} and (recent releases of) % \ProgName{dvips}. Output from the latter may be used in recent % releases of \ProgName{ghostscript} or Acrobat Distiller.