summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/generic/FAQ-en/faq-hyp+pdf.tex
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-dist/doc/generic/FAQ-en/faq-hyp+pdf.tex')
-rw-r--r--Master/texmf-dist/doc/generic/FAQ-en/faq-hyp+pdf.tex564
1 files changed, 564 insertions, 0 deletions
diff --git a/Master/texmf-dist/doc/generic/FAQ-en/faq-hyp+pdf.tex b/Master/texmf-dist/doc/generic/FAQ-en/faq-hyp+pdf.tex
new file mode 100644
index 00000000000..018157e04bf
--- /dev/null
+++ b/Master/texmf-dist/doc/generic/FAQ-en/faq-hyp+pdf.tex
@@ -0,0 +1,564 @@
+% $Id: faq-hyp+pdf.tex,v 1.1 2009/06/13 20:56:41 rf10 Exp rf10 $
+
+\section{Hypertext and \acro{PDF}}
+
+\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 Direct \Qref{\AllTeX{} conversion to \acro{HTML}}{Q-LaTeX2HTML};
+% beware line break
+\item Use \Qref*{\Package{Texinfo}}{Q-texinfo},
+ and use the \ProgName{info} viewer, or convert the \Package{texinfo}
+ to \acro{HTML};
+\item Use Adobe Acrobat, which will preserve your typesetting
+ perfectly
+ \Qref*{Making Acrobat \acro{PDF} documents from \LaTeX{}}{Q-acrobat};
+\item The hyper\TeX{} conventions (standardised \csx{special}
+ commands); there are supporting macro packages for \plaintex{} and
+ \LaTeX{}).
+\end{itemize}
+
+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:<a href = "href_string">|
+\item[name:] |html:<a name = "name_string">|
+\item[end:] |html:</a>|
+\item[image:] |html:<img src = "href_string">|
+\item[base\_name:] |html:<base href = "href_string">|
+\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-acrobat]{Making Acrobat \acro{PDF} documents from \AllTeX{}}
+
+There are three general routes to \acro{PDF} output: Adobe's original
+`distillation' route (via \PS{} output), conversion of a
+\acro{DVI} file, and the use of a direct \acro{PDF} generator such as
+\Qref*{\PDFTeX{}}{Q-whatpdftex}) or
+MicroPress's V\TeX{} (which comes both as a % ! line break
+\Qref*{commercial version}{Q-commercial} for Windows PCs, and as a
+\Qref*{`free' version)}{Q-TeXsystems} for \acro{OS}/2 and Linux systems).
+
+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 the appropriate Adobe
+ tools installed) pass the output through the
+ \acro{PDF}writer in place of a printer driver (this route is a dead
+ end: the \acro{PDF}writer cannot create hyperlinks);
+\item process the document in the normal way 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{} or
+ V\TeX{}. \PDFTeX{} has
+ the advantage of availability for a wide range of platforms, V\TeX{}
+ (available commercially for Windows, or free of charge, but
+ unsupported, for Linux or \acro{OS/}2) has wider graphics
+ capability, dealing with encapsulated \PS{} and some in-line \PS{}.
+\end{itemize}
+
+To translate all the \LaTeX{} cross-referencing into Acrobat
+links, you need a \LaTeX{} package to suitably 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
+its 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]browse
+ \URL{ftp://ftp.adobe.com/pub/adobe/acrobatreader}
+\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}
+
+\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 the recently released version~6).
+
+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
+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{verbatim}
+ dvips -Ppdf myfile -o myfile.ps
+\end{verbatim}
+This may produce a warning message about failing to find the
+configuration file:
+\begin{verbatim}
+ dvips: warning: no config file for `pdf'
+\end{verbatim}
+or something similar, or about failing to find a font file:
+\begin{verbatim}
+ dvips: ! Couldn't find header file cmr10.pfb
+\end{verbatim}
+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{verbatim}
+ dvips -Pcmz -Pamz myfile -o myfile.ps
+\end{verbatim}
+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 it confuses
+\Package{hyperref} since there are pages which seem (to
+\Package{hyperref}) to have the same page number. Fortunately, there are
+configuration options to make \Package{hyperref} ``do the right
+thing''.
+
+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'.
+ (If the option is set `\texttt{true}'~--- the default~---
+ \Package{hyperref} writes page anchors as the arabic form of the
+ absolute page number, rather than the formatted form.)
+\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}
+