diff options
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.tex | 453 |
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 |