summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/generic/FAQ-en/faq-bits+pieces.tex
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-dist/doc/generic/FAQ-en/faq-bits+pieces.tex')
-rw-r--r--Master/texmf-dist/doc/generic/FAQ-en/faq-bits+pieces.tex453
1 files changed, 207 insertions, 246 deletions
diff --git a/Master/texmf-dist/doc/generic/FAQ-en/faq-bits+pieces.tex b/Master/texmf-dist/doc/generic/FAQ-en/faq-bits+pieces.tex
index b8fade922fa..a6ed86b6617 100644
--- a/Master/texmf-dist/doc/generic/FAQ-en/faq-bits+pieces.tex
+++ b/Master/texmf-dist/doc/generic/FAQ-en/faq-bits+pieces.tex
@@ -1,120 +1,30 @@
-% $Id: faq-bits+pieces.tex,v 1.18 2011/08/28 10:13:19 rf10 Exp rf10 $
+% $Id: faq-bits+pieces.tex,v 1.23 2011/10/25 21:30:42 rf10 Exp rf10 $
\section{Bits and pieces of \AllTeX{}}
-\Question[Q-ctan]{What is \acro{CTAN}?}
-
-The acronym stands for ``Comprehensive \tex{} Archive Network'', which
-more-or-less specifies what it's \emph{for}:
-\begin{itemize}
-\item The aim is to offer a comprehensive collection of \tex{} resources.
-\item The content is to be made publicly accessible, via the internet.
-\item \acro{CTAN} is a \emph{network} of archives, which strive to
- stay in step with one another.
-\end{itemize}
-The basic framework was developed by a \acro{TUG} working group set up
-to resolve the (then existing) requirement for users to \emph{know} on
-which archive site a particular package might be found.
-
-Actual implementation offers three distinct types of host:
-\begin{description}
-\item[\emph{Core} archives]Which form a small, tightly-coupled set of
- machines, which perform management functions as well as serving
- files, and
-\item[\emph{Mirror} archives]Which do no more than take regular copies
- of core archives.
-\item[Archive selector]Which is a meta-service, which routes requests
- to an apparently ``local'' source (mirror or archive).
-\end{description}
-Note that there is nothing to prevent any archive from supporting
-other functions, so a \acro{CTAN} mirror may also operate as a
-\acro{CPAN} (Perl) mirror and as a SourceForge (general free software)
-mirror, and \dots{}
-
-Functions that distinguish core archives are:
-\begin{itemize}
-\item Uploads: users may submit new (or updated) material, and
- significant changes to the archive are reported via the mailing list
- \Email{ctan-ann@dante.de}
-\item Weak consistency: changes to the content of the archives are
- rapidly distributed to all core archives.
-\item Providing distribution (\texlive{} and \miktex{}) support.
-\item Catalogue maintenance.
-\item Mirror monitoring.
-\end{itemize}
-Not all core archives offer all of these functions.
-
-Users may contact the maintainers of the core archives via the mailing
-list \mailto{ctan@dante.de}
-
-Users who have new material for the archive may submit it using the
-\href{http://dante.ctan.org/upload/}{German} or
-\href{http://www.tex.ac.uk/upload/}{UK} archive.
-
-Users should ordinarily download material from \acro{CTAN} via the
-\href*{http://mirror.ctan.org/}{archive selector}: this uses the
-mirror monitor's database, and uses the caller's geographical location to
-offer an efficient choice of ``sufficiently up-to-date'' mirror site for
-you to connect to. Note that all the download links, given in the web
-representation of these \acro{FAQ}s, are set up to use the mirror
-selector.
-\LastEdit*{2011-04-21}
-
-\Question[Q-catalogue]{The (\acro{CTAN}) catalogue}
-
-Finding stuff on networks was always difficult, but in recent years,
-search engines have become amazingly good at digging out unconsidered
-trifles from the myriad items of information available on the net.
-
-Sadly, in the \tex{} context, search engines seem to excel in locating
-out-of-date material, while the service users need a means of finding
-relevant material on \acro{CTAN}~--- on the grounds that such material
-is most likely to be up-to-date. The need to find such items, thus
-alleviating tendency to end up with out-of-date \alltex{} material,
-was the motivation for developing a specialised information source:
-the \acro{CTAN} catalogue. The aim is that they contain enough
-relevant information that they will appear early in a search engine's
-evaluation.
-
-The basis of the catalogue is a collection of small
-articles; each shows basic information about a package on \acro{CTAN},
-and includes pointers to download address, documentation and related
-packages. Every \acro{CTAN} mirror holds a copy of the catalogue,
-presented as a series of web pages; indexes (both alphabetic and
-category-based) are provided.
-
-The core \acro{CTAN} sites also offer a simple text search of the
-catalogue. This is a tolerable means of finding a package you need,
-but it is not really a substitute for a good information retrieval
-system: the problem of providing such a system has not yet been solved.
-\begin{ctanrefs}
-\item[\nothtml{\rmfamily}The CTAN catalogue]\CTANref{Catalogue}
-\end{ctanrefs}
-\LastEdit*{2011-05-19}
-
\Question[Q-dvi]{What is a \acro{DVI} file?}
A \acro{DVI} file (that is, a file with the type or extension
\extension{dvi}) is \TeX{}'s main output file, when we use
-``original'' \TeX{} (later \TeX{} systems, such as
-\begin{flatversion}
- \PDFTeX{}~--- see \Qref[question]{\PDFTeX{}}{Q-whatpdftex}~---
-\end{flatversion}
-\begin{hyperversion}
- \Qref{\PDFTeX{}}{Q-whatpdftex}
-\end{hyperversion}
-may use other formats).
-
-`\acro{DVI}' is supposed to
-be an acronym for \acro{D}e\acro{V}ice-\acro{I}ndependent, meaning
-that the file can be processed for printing or viewing on most
-kinds of typographic output device or display. The \acro{DVI} file
-may be processed by a \Qref*{DVI driver}{Q-driver} to produce
-further output designed specifically for a particular printer, or it
-may be used by a previewer for display on a computer screen.
-\acro{DVI} files use an internal coding designed for \TeX{}; a \TeX{}
-input file should produce the same \acro{DVI} file regardless of which
-implementation of \TeX{} is used to produce it.
+``original'' \TeX{}; later \TeX{} systems, such as
+ \Qref*{\PDFTeX{}}{Q-whatpdftex}
+may use other formats. \Qref*{\xetex}{Q-xetex} (released some time
+after \pdftex{}) uses an
+``extended \acro{DVI} format'' (\acro{XDV}) to send its output to its
+close-coupled \Qref*{\acro{DVI} driver}{Q-driver},
+\ProgName{xdvipdfmx}.
+
+`\acro{DVI}' is supposed to be an acronym for
+\acro{D}e\acro{V}ice-\acro{I}ndependent, meaning that the file can be
+processed for printing or viewing on most kinds of typographic output
+device or display. The \acro{DVI} file may be processed by a
+\Qref*{DVI driver}{Q-driver} to produce further output designed
+specifically for a particular printer, or it may be used by a
+previewer for display on a computer screen. The character encoding of
+a \acro{DVI} file is determined by the document itself~--- see % line break
+``\Qref*{what are encodings}{Q-whatenc}'' for an explanation of what A
+\TeX{} input file should produce the same \acro{DVI} file regardless
+of which implementation of \TeX{} is used to produce it.
A \acro{DVI} file contains all the information that is needed for printing
or previewing except for the actual bitmaps or outlines of fonts, and
@@ -123,58 +33,65 @@ possibly material to be introduced by means of
The canonical reference for the structure of a \acro{DVI} file is the
source of Knuth's program \ProgName{dvitype} (whose original purpose,
-as its name implies, was to view the content of a \acro{DVI} file).
+as its name implies, was to view the content of a \acro{DVI} file),
+and a partially complete ``standard'' for the way they should be
+processed may offer further enlightenment.
\begin{ctanrefs}
+\item[\nothtml{rmfamily}DVI processing standard]\CTANref{dvistd}
\item[dvitype]\CTANref{dvitype}
\end{ctanrefs}
-\LastEdit{2011-07-01}
+\LastEdit{2011-10-10}
\Question[Q-driver]{What is a \acro{DVI} driver?}
A \acro{DVI} driver is a program that takes as input a
-\begin{flatversion}
- \acro{DVI} file (see \Qref[question]{}{Q-dvi})
-\end{flatversion}
-\begin{hyperversion}
- \Qref{\acro{DVI} file}{Q-dvi}
-\end{hyperversion}
-and (usually) produces a file that can be sent to a typographic
-output device (which we will call a printer, for short), or to another
-format.
-
-A driver will usually be specific to a particular printer,
-although any \PS{} printer ought to be able to print
-the output from a \PS{} driver.
-% (these are also called \PS{} conversion programs).
-
-As well as the \acro{DVI} file, the driver also needs font information.
-Font information may be held as bitmaps or as outlines, or simply as a
-set of pointers into the fonts that the printer itself `has'.
-Each driver will expect the font information in
-a particular form. For more information on the forms of font information,
-see \Qref[questions]{\acro{PK} files}{Q-pk},
+\Qref*{\acro{DVI} file}{Q-dvi}
+and (usually) produces a file in a format that something \emph{other}
+than a \TeX{}-related program can process.
+
+A driver may be designed for producing output for printing (e.g.,
+\PS{}), for later processing (e.g., \PS{} for inclusion in a later
+document), or for document exchange (e.g., \acro{PDF}).
+
+As well as the \acro{DVI} file, the driver typically also needs font
+information. Font information may be held as bitmaps or as outlines,
+or simply as a set of pointers into the fonts that a printer itself
+provides. Each driver will expect the font information in a particular
+form.
+
+For more information on the forms of font information, see
+\Qref[questions]{\acro{PK} files}{Q-pk},
% ! line break
\Qref[]{\acro{TFM} files}{Q-tfm},
\Qref[]{virtual fonts}{Q-virtualfonts}
and \Qref[]{Using \PS{} fonts with \TeX{}}{Q-usepsfont}.
+\LastEdit{2011-10-10}
\Question[Q-pk]{What are \acro{PK} files?}
-\acro{PK} files (packed raster) contain font bitmaps. The output
-from \Qref*{\MF{}}{Q-useMF} includes a generic font (\acro{GF}) file
-and the utility \ProgName{gftopk} produces the \acro{PK} file from
-that. There are a lot of \acro{PK} files, as one is needed for each
-font, that is each magnification (size) of each design (point) size
-for each weight for each family. Further, since the \acro{PK} files
-for one printer do not necessarily work well for another, the whole
-set needs to be duplicated for each printer type at a site. In a
-modern \TeX{} distribution, files are arranged according to the \TeX{}
-directory structure \Qref*{\acro{TDS}}{Q-tds}, which has provision for
-all this variety.
+\acro{PK} files (packed raster) are the canonical form of font
+bitmaps. The output from \Qref*{\MF{}}{Q-useMF} includes a generic
+font (\acro{GF}) file and the utility \ProgName{gftopk} produces the
+\acro{PK} file from that.
+
+There are a lot of \acro{PK} files, as one
+is needed for each font, that is each magnification of each
+design (point) size for each weight for each font in each family.
+
+Further, since the \acro{PK} files for one printer do not necessarily
+work well for another, the whole set needs to be duplicated for each
+printer type at a site.
+
+While this menagerie of bitmaps can (in principle) provide fonts that
+are closely matched to the capabilities of each printer, the size of
+the collection (and the resulting difficulty of maintaining it) has
+been a potent driver to the move towards outline fonts such as
+\Qref*{Adobe Type 1 fonts}{Q-adobetypen}.
+\LastEdit{2011-10-10}
\Question[Q-tfm]{What are \acro{TFM} files?}
-\acro{TFM} stands for \TeX{} Font Metrics; \acro{TFM} files hold
+\acro{TFM} is an acronym for `\TeX{} Font Metrics'; \acro{TFM} files hold
information about the sizes of the characters of the font in question,
and about ligatures and kerns within that font. One \acro{TFM} file is
needed for each font used by \TeX{}, that is for each design (point)
@@ -191,7 +108,7 @@ Note that TrueType and OpenType fonts contain the necessary metrics,
so that \Qref{\xetex{}}{Q-xetex} and \Qref{\luatex{}}{Q-luatex}, using
such fonts, have no need of \acro{TFM} files. A corollary of this is
that setting up fonts for use by these engines is far \emph{easier}.
-\LastEdit{2011-07-10}
+\LastEdit{2011-10-10}
\Question[Q-virtualfonts]{Virtual fonts}
@@ -200,29 +117,25 @@ to make the glyphs of a font: the bits and pieces may be other glyphs,
rules and other ``basic'' typesetting commands, and the positioning
information that specifies how everything comes together.
-Things that match the concept of virtual fonts for \TeX{} were first
-implemented by David Fuchs in the very early days. However, for practical
-purposes for the rest of us, virtual fonts date from when Knuth
+An early instance of something like virtual fonts for \TeX{} was
+implemented by David Fuchs to use an unusual printer. However, for
+practical purposes for the rest of us, virtual fonts date from when Knuth
specified a format and wrote some support software, in 1989 (he
-published an article in \textsl{TUGboat} at the time, and a plain text
-copy is available on \acro{CTAN}).
+published an % ! line break
+\href{http:/tug.org/TUGboat/tb11-1/tb27knut.pdf}{article in \textsl{TUGboat}}
+at the time; a plain text copy is available on \acro{CTAN}).
Virtual fonts provide a way of telling \TeX{} about something more
-complicated than just a one-to-one character mapping. The entities you
-define in a virtual font look like characters to \TeX{} (they appear
-with their sizes in a \acro{TFM} file), but the \acro{DVI} processor may
-expand them to something quite different.
-
-From the virtual font file, the \acro{DVI} processor learns
-details of what is in the virtual font, so as to know ``what to draw,
-where''. The virtual font may contain commands:
+complicated than just a one-to-one character mapping. \TeX{} reads a
+\acro{TFM} file of the font, just as before, but the \acro{DVI}
+processor will read the \acro{VF} and use its content to specify how
+each glyph is to be processed.
+
+The virtual font may contain commands:
\begin{itemize}
-\item just to remap the glyphs of a single font,
-\item to make a composite font with glyphs drawn from several
- different fonts, or
-\item to build up an effect in arbitrarily complicated ways (since a
- virtual font may contain anything which is legal in a \acro{DVI}
- file).
+\item to `open' one or more (real) fonts for subsequent use,
+\item to remap a glyph from one of the (real) fonts,
+\item to build up a more complicated effect (using \acro{DVI} commands).
\end{itemize}
% !this has to be generated as a new paragraph by the translator, so
@@ -237,16 +150,16 @@ remapping and fragments of \acro{DVI} for single-glyph `accented
characters', were the first ``Type~1 format'' Cork-encoded Computer
Modern fonts available.
-Virtual fonts are normally created in a single \acro{ASCII}
-\acro{VPL} (Virtual Property List) file, which includes both sets of
-information. The \ProgName{vptovf} program is then used to the create
+Virtual fonts are normally created in a single \acro{ASCII} \acro{VPL}
+(Virtual Property List) file, which includes two sets of information.
+The \ProgName{vptovf} utility will use the \acro{VPL} file to create
the binary \acro{TFM} and \acro{VF} files.
A ``how-to'' document, explaining how to generate a \acro{VPL},
describes the endless hours of fun that may be had, doing the job by
-hand. Despite the pleasures to be had of the manual method, the
-commonest way (nowadays) of generating \acro{VPL} files is to use the
-\ProgName{fontinst} package, which is described in detail
+hand. Despite the pleasures to be had, the commonest way (nowadays)
+of generating an \acro{VPL} file is to use the
+\ProgName{fontinst} package, which is described in more detail
\htmlonly{together with the discussion of}
\Qref[in answer]{\PS{} font metrics}{Q-metrics}.
\Package{Qdtexvpl} is another utility for creating ad-hoc virtual
@@ -258,6 +171,7 @@ fonts (it uses \TeX{} to parse a description of the virtual font, and
\item[\nothtml{\rmfamily}Virtual fonts ``how to'']\CTANref{vf-howto}
\item[qdtexvpl]\CTANref{qdtexvpl}
\end{ctanrefs}
+\LastEdit{2011-10-12}
\Question[Q-whatmacros]{What are (\TeX{}) macros}
@@ -269,7 +183,8 @@ generation one might expect.
Macros are a \emph{good thing}, since they allow the user to
manipulate documents according to context. For example, the macro
-\csx{TeX} is usually defined to produce ``TEX'' with the `E' lowered,
+\csx{TeX} is usually defined to produce ``TEX'' with the `E' lowered
+(the original idea was Knuth's),
but in these \acro{FAQ}s the default definition of the macro is
overridden, and it simply expands to the letters ``TeX''. (\emph{You}
may not think this a good thing, but the author of the macros has his
@@ -300,7 +215,7 @@ protecting users from themselves, but basically does the same thing:
\newcommand{\foo}{bar}
\end{verbatim}
\end{quote}
-Macros may have ``arguments'', which are used to substitute for marked
+Macros may have ``arguments'' , which are used to substitute for marked
bits of the macro expansion:
\begin{quote}
\begin{verbatim}
@@ -327,13 +242,19 @@ which produces:
\end{quote}
(\latex{} users waltz through life, perhaps?)
+You will have noticed that the arguments, above, were enclosed in
+braces (\texttt{\obracesymbol{}\dots{}\cbracesymbol{}}); this is the
+normal way of typing arguments, though \TeX{} is enormously flexible,
+and you may find all sorts of other ways of passing arguments (if you
+stick with it).
+
Macro writing can get very complicated, very quickly. If you are a
beginner \AllTeX{} programmer, you are well advised to read something
along the lines of the \Qref*{\TeX{}book}{Q-tex-books}; once you're under
way, \Qref*{\TeX{} by Topic}{Q-ol-books} is possibly a more satisfactory
choice. Rather a lot of the answers in these \acro{FAQ}s tell you
about various issues of how to write macros.
-\LastEdit{2011-07-10}
+\LastEdit{2011-10-12}
\Question[Q-specials]{\csx{special} commands}
@@ -369,6 +290,7 @@ Note that \csx{special} behaves rather differently in \PDFTeX{}, since
there is no device driver around. There \emph{is} a concept of
\acro{PDF} specials, but in most cases \csx{special} will provoke a
warning when used in \PDFTeX{}.
+\LastEdit{2011-10-15}
\Question[Q-write]{Writing (text) files from \tex{}}
@@ -392,7 +314,7 @@ out.
Now, there are times when you want to write something straight away:
for example, to interact with the user. \TeX{} captures that
-requirement, too, with the primitive \csx{immediate}:
+requirement, too, with the primitive command \csx{immediate}:
\begin{quote}
\begin{verbatim}
\immediate\write\terminal{I'm waiting...}
@@ -410,6 +332,7 @@ its equivalent) is the first output stream ever set up (in most macro
packages): it is never attached to a file, and if \tex{} is asked to
write to \emph{any} stream that isn't attached to a file it will send
the output to the terminal (and the log).
+\LastEdit{2011-10-15}
\Question[Q-spawnprog]{Spawning programs from \AllTeX{}: \csx{write18}}
@@ -435,7 +358,7 @@ exact way it's done.
However, there is a security issue. If you download some \alltex{} code from
the Internet, can you be sure that there is not some command in it
(perhaps in a hidden way) to do stuff that might be harmful to your
-\acro{PC} (let's say: delete everything on the hard disk!)? In the
+computer (let's say: delete everything on the hard disk!)? In the
face of this problem, both \miktex{} and \tex{}~Live have, for some
time, disabled \csx{write18} by default. To turn the facility on,
both distributions support an additional argument when starting \tex{}
@@ -483,6 +406,7 @@ when it starts.
\item[epstopdf.sty]Distributed with Heiko Oberdiek's packages
\CTANref{oberdiek}[epstopdf-pkg]
\end{ctanrefs}
+\LastEdit{2011-10-15}
\Question[Q-hyphen]{How does hyphenation work in \TeX{}?}
@@ -510,7 +434,8 @@ persuaded to think of as letters); things such as \TeX{}'s
Sets of hyphenation patterns are usually derived from analysis of
a list of valid hyphenations (the process of derivation, using a tool
-called \Package{patgen}, is not ordinarily a participatory sport).
+called \Package{patgen}, is not ordinarily a sport to be played by
+ordinary mortals).
The patterns for the languages a \TeX{} system is going to deal with
may only be loaded when the system is installed. To change the set of
@@ -738,42 +663,37 @@ nearly so well, and the two packages provide the sort of symmetry the
\Question[Q-ECfonts]{What are the \acro{EC} fonts?}
-A font consists of a number of \emph{glyphs}. In order that the
-glyphs may be printed, they are \Qref*{\emph{encoded}}{Q-whatenc}, and
-the encoding is used as an index into tables within the font. For
-various reasons, Knuth chose deeply eccentric encodings for his
-Computer Modern family of fonts; in particular, he chose different
-encodings for different fonts, so that the application using the fonts
-has to remember which font of the family it's using before selecting a
+A font provides a number of \emph{glyphs}. In order that the glyphs
+may be printed, they are \Qref*{\emph{encoded}}{Q-whatenc}, and the
+encoding is used as an index into tables within the font. For various
+reasons, Knuth chose deeply eccentric encodings for his Computer
+Modern family of fonts; in particular, he chose different encodings
+for different fonts, so that the application using the fonts has to
+remember which font of the family it's using before selecting a
particular glyph.
-When \TeX{} version 3 arrived, most of the excuses for the
+When \TeX{} version 3 arrived, most of the drivers for the
eccentricity of Knuth's encodings went away, and at \acro{TUG}'s Cork
meeting, an encoding for a set of 256 glyphs, for use in \TeX{} text,
was defined. The intention was that these glyphs should cover `most'
European languages that use Latin alphabets, in the sense of including
all accented letters needed. (Knuth's \acro{CMR} fonts missed things
-necessary for Icelandic and Polish, for example, but the Cork
-fonts have them. Even Cork's coverage isn't complete: it misses
-letters from Romanian, Eastern and Northern Sami, and Welsh, at
-least. The Cork encoding does contain ``\acro{NG}'' glyphs that
-allows it to support Southern Sami.) \LaTeX{} refers to the
-Cork encoding as \acro{T}1, and
-provides the means to use fonts thus encoded to avoid problems with
-the interaction of accents and hyphenation % ! line break
+necessary for Icelandic and Polish, for example, which the Cork fonts
+do have, though even Cork encoding's coverage isn't complete.)
+\latex{} refers to the Cork encoding as \acro{T}1, and provides the
+means to use fonts thus encoded to avoid problems with the interaction
+of accents and hyphenation % ! line break
(see \Qref[question]{hyphenation of accented words}{Q-hyphenaccents}).
-The only \MF{}-fonts that conform to the Cork encoding are the
-\acro{EC} fonts. They look \acro{CM}-like, though their metrics
-differ from \acro{CM}-font metrics in several areas. The fonts are
-now regarded as `stable' (in the same sense that the \acro{CM} fonts
-are stable: their metrics are unlikely ever to change). Their serious
-disadvantages for the casual user are their size (each \acro{EC} font
-is roughly twice the size of the corresponding \acro{CM} font), and
-there are far more of them than there are \acro{CM} fonts. The simple
-number of fonts proved problematic in the production of Type~1
-versions of the fonts, but \acro{EC} or \acro{EC}-equivalent fonts in
-Type~1 or TrueType form (the latter only from
+The first \MF{}-fonts to conform to the Cork encoding were the \acro{EC}
+fonts. They look \acro{CM}-like, though their metrics differ from \acro{CM}-font
+metrics in several areas. They have long been regarded as `stable' (in
+the same sense that the \acro{CM} fonts are stable: their metrics are
+unlikely ever to change). Each \acro{EC} font is, of course, roughly twice the
+size of the corresponding \acro{CM} font, and there are far more of them than
+there are CM fonts. The simple number of fonts proved problematic in
+the production of Type~1 versions of the fonts, but \acro{EC} or
+\acro{EC}-equivalent fonts in Type~1 or TrueType form (the latter only from
\begin{wideversion}
\Qref{commercial suppliers}{Q-commercial}).
\end{wideversion}
@@ -781,64 +701,105 @@ Type~1 or TrueType form (the latter only from
% ( <- paren matching
commercial suppliers~--- \Qref{question}{Q-commercial}).
\end{narrowversion}
-Free \Qref*{auto-traced versions}{Q-textrace}~--- the \acro{CM}-super
-and the \acro{LGC} fonts, and the Latin Modern series (rather
-directly generated from \MF{} sources), are available.
-
-%% Unfortunately, until corresponding fonts for mathematics are produced,
-%% the \acro{CM} fonts must be retained, since some mathematical symbols
-%% are drawn from text fonts in the \acro{CM} encodings.
-Note that the Cork encoding doesn't cover mathematics (and neither do
-``\acro{T}1-encoded'' font families, of course). If you're using
+Free \Qref*{auto-traced versions}{Q-textrace}~--- the \acro{CM}-super and
+the \acro{LGC} fonts, and the Latin Modern series (rather directly generated
+from Metafont sources), are available.
+
+Note that the Cork encoding doesn't cover mathematics (so that no
+``T1-encoded'' font families can not support it). If you're using
Computer-Modern-alike fonts, this doesn't actually matter: your system
-will have the original Computer Modern mathematical fonts (or the those
-distributed with the Latin Modern set), which cover `basic'
-\TeX{} mathematics; more advanced mathematics are likely to need
-separate fonts anyway. Suitable mathematics fonts for use with other
-font families are discussed in % ! line break
+will have the original Computer Modern mathematical fonts (or the
+those distributed with the Latin Modern set), which cover `basic' \TeX{}
+mathematics; more advanced mathematics are likely to need separate
+fonts anyway. Suitable mathematics fonts for use with other font
+families are discussed in % ! line break
``\Qref*{choice of scalable fonts}{Q-psfchoice}''.
-The \acro{EC} fonts are distributed with a
-set of `Text Companion' (\acro{TC}) fonts that provide glyphs for
-symbols commonly used in text. The \acro{TC} fonts are encoded
-according to the \LaTeX{} \acro{TS}1 encoding, and are not viewed as
-`stable' in the same way as are the \acro{EC} fonts are.
+The \acro{EC} fonts are distributed with a set of `Text Companion' (\acro{TC}) fonts
+that provide glyphs for symbols commonly used in text. The \acro{TC} fonts
+are encoded according to the \latex{} \acro{TS}1 encoding, and are not
+necessarily as `stable' are the \acro{EC} fonts are. Note that modern
+distributions tend not to distribute the \acro{EC} fonts in outline format, but
+rather to provide Latin Modern for \acro{T}1-encoded Computer Modern-style
+fonts. This can sometimes cause confusion when users are recompiling
+old documents.
The Cork encoding is also implemented by virtual fonts provided in the
-\Qref*{\acro{PSNFSS} system}{Q-usepsfont}, for Adobe Type~1 fonts, and
-also by most other such fonts that have been developed (or otherwise
-made available) for use with \AllTeX{}.
+\acro{PSNFSS} system, for Adobe Type 1 fonts, and also by most other such
+fonts that have been developed (or otherwise made available) for use
+with \alltex{}.
+
+Note that \acro{T}1 (and other eight-bit font encodings) are superseded in
+the developing \TeX{}-family members \Qref*{\xetex{}}{Q-xetex} and
+\Qref*{\luatex{}}{Q-luatex}, which use Unicode as their base encoding,
+and use Unicode-encoded fonts (typically in \FontFormat{ttf} or
+\FontFormat{otf} formats). The \Package{cm-unicode} fonts carry the
+flag in this arena, along with the Latin Modern set.
\begin{ctanrefs}
\item[CM-super fonts]\CTANref{cm-super}
\item[CM-LGC fonts]\CTANref{cm-lgc}
+\item[CM unicode fonts]\CTANref{cm-unicode}
\item[EC and TC fonts]\CTANref{ec}
\item[Latin Modern fonts]\CTANref{lm}
\end{ctanrefs}
+\Question[Q-unicode]{Unicode and \tex{}}
+
+Unicode is a character code scheme that has the capacity to express
+the text of the languages of the world, as well as important symbols
+(including mathematics). Any coding scheme that is directly
+applicable to \tex{} may be expressed in single bytes (expressing up
+to 256 characters); Unicode characters may require several bytes, and
+the scheme may express a very large number of characters.
+
+For ``old-style'' applications (\tex{} or \pdftex{}) to deal with
+Unicode input, the sequence of bytes to make up Unicode character is
+processed by a set of macros, and converted to an 8-bit number
+representing a character in an appropriate font (in practice, only the
+standard \acro{UTF}-8 byte sequences are supported). \tex{} code that
+reads these bytes is complicated, but works well enough; there is an
+\pkgoption{utf8} option for the \latex{} distribution
+\Package{inputenc} package. The separate package \Package{ucs}
+provides wider, but less robust, coverage via an \Package{inputenc}
+option \pkgoption{utf8x}. Broadly, the difference is that
+\pkgoption{utf8} deals with ``standard \latex{} fonts'' (those for
+which \latex{} has a defined encoding), while \pkgoption{utf8x} deals
+with pretty much anything for which it knows a mapping of a Unicode
+range to a font.
+
+The up-and-coming \tex{}-alike applications, \Qref*{\xetex{}}{Q-xetex}
+and \Qref*{\luatex{}}{Q-luatex} read \acro{UTF}-8 representations of
+Unicode as standard. They also use TrueType or OpenType fonts for
+output; each such font ``declares'' which part(s) of the Unicode space
+it covers, so that the \tex{}-alike engines can decide which font to
+use for which character.
+\begin{ctanrefs}
+\item[inputenc.sty]Part of the \CTANref{latex} distribution
+\item[ucs.sty]\CTANref{unicode}
+\end{ctanrefs}
+
\Question[Q-tds]{What is the \acro{TDS}?}
- \acro{TDS} stands for the \TeX{} Directory Structure, which is a standard
-way of organising all the \TeX{}-related files on a computer system.
-
- Most modern distributions conform to the \acro{TDS}, which
-provides for both a `distribution' and a (set of) `local' directory
-trees containing \TeX{}-related files. The \acro{TDS} reserves the
-name \texttt{texmf} as the name of the root directory (folder) of the
-hierarchies, and most distributions use that name for their `own'
-trees. Files supplied as part of the distribution are put into the
-distribution's tree. The location of the distribution's hierarchy is
-system dependent, but on a Unix system it might be at
-\path{/usr/share/texmf} or
-\path{/opt/texmf}, or
-a similar location, but in each case the \TeX{} files will be in the
-tree starting at the \path{/texmf} subdirectory.
+\acro{TDS} is an acronym for ``\TeX{} Directory Structure''; it
+specifies a standard way of organising all the \TeX{}-related files on
+a computer system.
+
+Most modern distributions arrange their \tex{} files in conformance
+with the \acro{TDS}, using both a `distribution' directory tree and a
+(set of) `local' directory trees, each containing \TeX{}-related
+files. The \acro{TDS} recommends the name \texttt{texmf} for the name
+of the root directory (folder) of an hierarchy; in practice there are
+typically several such trees, each of which has a name that compounds
+that (e.g., \texttt{texmf-dist}, \texttt{texmf-var}).
+
+Files supplied as part of the distribution are put into the
+distribution's tree, but the location of the distribution's hierarchy is
+system dependent. (On a Unix system it might be at
+\path{/usr/share/texmf} or \path{/opt/texmf}, or a similar location.)
There may be more than one `local' hierarchy in which additional files
-can be stored. In the extreme an installation can have a local
-hierarchy and each user can also have an individual local hierarchy.
-The location of any local hierarchy is not only system dependent but
-also user dependent. Again, though, all files should be put under a
-local \path{/texmf} directory.
+can be stored. An installation will also typically offer a local
+hierarchy, while each user may have an individual local hierarchy.
The \acro{TDS} itself is published as the output of a \acro{TUG} % ! line break
\Qref*{Technical Working Group}{Q-TUG*}. You may browse an