1 files changed, 174 insertions, 50 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 be1a21ba66b..06851bbc665 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,15 +1,15 @@
-% $Id: faq-bits+pieces.tex,v 1.24 2012/03/10 13:56:18 rf10 Exp rf10 $
+% $Id: faq-bits+pieces.tex,v 1.31 2012/12/07 19:34:33 rf10 Exp rf10 $
 
 \section{Bits and pieces of \AllTeX{}}
 
 \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
-  \Qref*{\PDFTeX{}}{Q-whatpdftex}
-may use other formats.  \Qref*{\xetex}{Q-xetex} (released some time
-after \pdftex{}) uses an
+\extension{dvi}) is the main output file of ``original'' \tex{}; later
+\tex{}-like 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}.
@@ -22,25 +22,25 @@ device or display.  The \acro{DVI} file may be processed by a
 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.
+``\Qref*{what are encodings}{Q-whatenc}'' for an explanation of
+encodings.  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 
-possibly material to be introduced by means of
+any material to be introduced by means of
 \Qref*{\csx{special} commands}{Q-specials}.
 
 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),
-and a partially complete ``standard'' for the way they should be
+as its name implies, was to view the content of a \acro{DVI} file).
+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-10-10}
+\LastEdit{2012-10-20}
 
 \Question[Q-driver]{What is a \acro{DVI} driver?}
 
@@ -69,13 +69,13 @@ and \Qref[]{Using \PS{} fonts with \TeX{}}{Q-usepsfont}.
 
 \Question[Q-pk]{What are \acro{PK} files?}
 
-\acro{PK} files (packed raster) are the canonical form of font
+\acro{PK} files (packed raster) are the canonical form of \tex{} font
 bitmaps.  The output from \Qref*{\MF{}}{Q-useMF} includes a generic
-font (\acro{GF}) file and the utility \ProgName{gftopk} produces the
+font (\acro{GF}) file and the utility \ProgName{gftopk} produces a
 \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
+There are potentially a lot of \acro{PK} files, as one
+is needed for each font: that is for 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
@@ -87,7 +87,7 @@ 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}
+\LastEdit{2012-10-20}
 
 \Question[Q-tfm]{What are \acro{TFM} files?}
 
@@ -97,8 +97,9 @@ 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)
 size for each weight for each family; each \acro{TFM} file serves for all
 magnifications of `its' font, so that there are (typically) fewer
-\acro{TFM} files than there are \acro{PK} files.  \TeX{} (\LaTeX{}, etc.\@)
-itself needs only to know about the sizes of characters and their
+\acro{TFM} files than there are \Qref*{\acro{PK}}{Q-pk} files.  \TeX{},
+\LaTeX{}, etc.\@
+themselves need only know about the sizes of characters and their
 interactions with each other, but not what characters look like.  By
 contrast, \acro{TFM} files are not, in principle, needed by the
 \acro{DVI} driver, which only needs to know about the glyphs that each
@@ -108,21 +109,22 @@ 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-10-10}
+\LastEdit{2012-10-20}
 
-\Question[Q-virtualfonts]{Virtual fonts}
+\Question[Q-virtualfonts]{What are virtual fonts?}
 
 Virtual fonts provide a means of collecting bits and pieces together
-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.
+to make the glyphs of a font: the bits and pieces may be glyphs from
+``other'' fonts, rules and other ``basic'' typesetting commands, and
+the positioning information that specifies how everything comes
+together.
 
 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 % ! line break
-\href{http:/tug.org/TUGboat/tb11-1/tb27knut.pdf}{article in \textsl{TUGboat}}
+\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
@@ -134,7 +136,8 @@ each glyph is to be processed.
 The virtual font may contain commands:
 \begin{itemize}
 \item to `open' one or more (real) fonts for subsequent use,
-\item to remap a glyph from one of the (real) fonts,
+\item to remap a glyph from one of the (real) fonts for use in the
+  virtual font,
 \item to build up a more complicated effect (using \acro{DVI} commands).
 \end{itemize}
 
@@ -171,7 +174,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}
+\LastEdit{2012-10-20}
 
 \Question[Q-whatmacros]{What are (\TeX{}) macros}
 
@@ -373,7 +376,8 @@ editor, so to use \csx{write18} for a file the editor's settings must
 be changed.  Of course, the settings need restoring after the file is
 processed: you defeat the point of the original protection, that way.
 
-The latest \miktex{} (version 2.9), and \tex{}~Live (2010 release) get
+The latest \miktex{} (version 2.9), and recent \tex{}~Live (from the
+2010 release) get
 around this by having a special ``limited'' version of \csx{write18}
 enabled `out of the box'.  The idea is to allow only a pre-set list of
 commands (for example, \BibTeX{}, \progname{epstopdf}, \tex{} itself,
@@ -406,7 +410,7 @@ when it starts.
 \item[epstopdf.sty]Distributed with Heiko Oberdiek's packages
   \CTANref{oberdiek}[epstopdf-pkg]
 \end{ctanrefs}
-\LastEdit{2011-10-15}
+\LastEdit{2012-12-03}
 
 \Question[Q-hyphen]{How does hyphenation work in \TeX{}?}
 
@@ -429,8 +433,14 @@ selects grossly wrong ones.  The
 algorithm matches candidates for hyphenation against a set of
 ``hyphenation patterns''.  The candidates for hyphenation must be
 sequences of letters (or other single characters that \TeX{} may be
-persuaded to think of as letters); things such as \TeX{}'s
-\csx{accent} primitive interrupt hyphenation.
+persuaded to think of as letters).  Non-letters interrupt hyphenation;
+this applies to \TeX{}'s \csx{accent} primitive (as in `syst\`eme')
+just as much as the exclamation in`syst!eme'.
+
+(Hyphenation takes place on the characters ``sent to the printer''.
+The problem with \csx{accent} is avoided~---in \latex{}~--- by the use
+of the \Package{fontenc} package, as discussed in % ! line break
+``\Qref*{Accented words aren t hyphenated}{Q-hyphenaccents}''.)
 
 Sets of hyphenation patterns are usually derived from analysis of
 a list of valid hyphenations (the process of derivation, using a tool
@@ -456,7 +466,7 @@ it is very thoroughly managed by the \Package{babel} package; use of
 \end{wideversion}
 % beware line wrap
 \Qref[question]{hyphenation failure}{Q-nohyph}.
-\LastEdit{2011-06-06}
+\LastEdit{2012-12-03}
 
 \Question[Q-clsvpkg]{What are \LaTeX{} classes and packages?}
 
@@ -512,6 +522,124 @@ option'').  It doesn't really matter that the nomenclature has
 changed: the important requirement is to understand what other people
 are talking about.
 
+\Question[Q-whatenv]{What are \latex{} ``environments''}
+
+While \tex{} makes direct provision for commands, \latex{} adds a
+concept of ``environment''; environments perform an action on a block
+(of something or other) rather than than just doing something at one
+place in your document.
+
+A totally trivial environment could change the font in use for a chunk
+of text, as
+\begin{quote}
+\begin{verbatim}
+\newenvironment{monoblock}%
+  {\ttfamily}%
+  {}
+\end{verbatim}
+\end{quote}
+which defines a \environment{monoblock} which may be used as
+\begin{quote}
+\begin{verbatim}
+\begin{monoblock}
+  some text set in monospace
+\end{monoblock}
+\end{verbatim}
+\end{quote}
+which will look like:
+\begin{quote}
+  \texttt{some text set in monospace}
+\end{quote}
+so it is a particularly simple example.  A rather complicated
+environment is introduced by \cmdinvoke{begin}{document}; it looks
+simple, but needs all sorts of special \tex{} code to make it work
+`transparently'; most environments are more elaborate than
+\environment{monoblock} and \emph{much} simpler than
+\environment{document}.
+
+An environment puts its content inside a \tex{} \emph{group}, so that
+commands used inside the environment don't `leak out'~--- the
+\environment{monoblock} environment, above, restricts its effect to
+its own contents (the stuff between the \cmdinvoke{begin}{monoblock}
+and \cmdinvoke{end}{monoblock}), which is just what you need for this
+sort of thing.
+
+So that's ``simple'' environments; the \environment{monoblock}, above
+doesn't actually gain us much over
+\begin{quote}
+\begin{verbatim}
+{\ttfamily some text set in monospace}
+\end{verbatim}
+\end{quote}
+though in fact many useful environments are just as simple (to look
+at).  Some, such as \environment{verbatim}, look simple but are
+actually very tricky inside.
+
+\latex{} also allows arguments to an environment:
+\begin{quote}
+\begin{verbatim}
+\newenvironment{fontblock}[1]%
+  {#1\selectfont}%
+  {}
+\end{verbatim}
+\end{quote}
+and use of \environment{fontblock} as:
+\begin{quote}
+\begin{verbatim}
+\begin{fontblock}{\ttfamily}
+\end{verbatim}
+\end{quote}
+would produce the same effect as the \environment{monoblock}
+environment.
+
+Environments may also have optional arguments, in much the same way as
+commands:
+\begin{quote}
+\begin{verbatim}
+\newenvironment{normaltext}[1][\itshape]%
+  {#1}%
+  {}
+\end{verbatim}
+\end{quote}
+which will ordinarily set its body in italic, but
+\begin{quote}
+\begin{verbatim}
+\begin{normaltext}[\ttfamily]
+  ...
+\end{normaltext}
+\end{verbatim}
+\end{quote}
+will observe its optional argument, and behave the same as the
+\environment{monoblock} we started with.
+
+Note that an environments argument(s) (mandatory or optional) are
+\emph{not} passed to the `\csx{end}' text of the environment~--- that
+is specified as a macro with no arguments, so that
+\begin{quote}
+\begin{verbatim}
+\newenvironment{normaltext}[1][\itshape]%
+  {#1}%
+  {\typeout{what was #1, again?}
+\end{verbatim}
+\end{quote}
+produces an error message
+\begin{quote}
+\begin{verbatim}
+! Illegal parameter number in definition of \endnormaltext.
+\end{verbatim}
+\end{quote}
+So, if you need to pass an environment argument to the end-code, you
+have to wrap it in a macro of its own:
+\begin{quote}
+\begin{verbatim}
+\newenvironment{normaltext}[1][Intro]%
+  {#1%
+   \newcommand{\foo}{#1}}%
+  {\typeout{what was \foo{}, again?}
+\end{verbatim}
+\end{quote}
+\LastEdit*{2013-02-20}
+
 \Question[Q-dtx]{Documented \LaTeX{} sources (\extension{dtx} files)}
 
 \LaTeXe{}, and most contributed macro packages, are now written in a
@@ -753,21 +881,17 @@ 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.  As a general rule, you should never use
-\Package{ucs}/\pkgoption{utf8x} until you have convinced yourself that
-\Package{inputenc}/\pkgoption{utf8} can not do the job for you.
+Unicode input, the sequence of bytes to make up Unicode character are
+processed by a set of macros that deliver a glyph number in an
+appropriate font.  The macros that read these bytes is complicated,
+and manifests as \pkgoption{utf8} option for the \latex{} distribution
+\Package{inputenc} package; the coverage of that option is limited to
+Unicode characters that can be represented using ``\latex{} standard
+encodings''.  The separate package \Package{ucs} provides wider, but
+less robust, coverage via an \Package{inputenc} option
+\pkgoption{utf8x}.  As a general rule, you should never use
+\pkgoption{utf8x} until you have convinced yourself that
+\pkgoption{utf8} can not do the job for you.
 
 `Modern' \tex{}-alike applications, \Qref*{\xetex{}}{Q-xetex} and
 \Qref*{\luatex{}}{Q-luatex} read their input using \acro{UTF}-8
@@ -778,9 +902,9 @@ enable the engines to decide which font to use for which character
 (assuming there is any choice at all).
 \begin{ctanrefs}
 \item[inputenc.sty]Part of the \CTANref{latex} distribution
-\item[ucs.sty]\CTANref{unicode}
+\item[ucs.sty]\CTANref{ucs}
 \end{ctanrefs}
-\LastEdit{2011-03-07}
+\LastEdit{2012-04-20}
 
 \Question[Q-tds]{What is the \acro{TDS}?}