summaryrefslogtreecommitdiff
path: root/usergrps/uktug/baskervi/4_2/sieben.tex
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /usergrps/uktug/baskervi/4_2/sieben.tex
Initial commit
Diffstat (limited to 'usergrps/uktug/baskervi/4_2/sieben.tex')
-rw-r--r--usergrps/uktug/baskervi/4_2/sieben.tex780
1 files changed, 780 insertions, 0 deletions
diff --git a/usergrps/uktug/baskervi/4_2/sieben.tex b/usergrps/uktug/baskervi/4_2/sieben.tex
new file mode 100644
index 0000000000..6aee0dfda4
--- /dev/null
+++ b/usergrps/uktug/baskervi/4_2/sieben.tex
@@ -0,0 +1,780 @@
+\title{Using virtual fonts with Textures}
+\author[Laurent Siebenmann]{Laurent Siebenmann\\
+\texttt{lcs@matups.matups.fr}}
+\begin{Article}
+\MakeShortVerb{|}
+\newenvironment{smalldesc}{\par\bgroup\small\description}{\par\egroup\par
+\enddescription}
+\section{Introduction}
+
+Virtual font support was first provided in mid 1993 in two popular
+implementations of \TeX\ for the Macintosh, namely
+Textures and Oz\TeX.
+
+For Textures users, virtual fonts offer the first oportunity to
+exploit the high performance of the scalable CM/PS fonts, which
+Textures provides, in a way that permits perfect linebreaking and
+kerning for accented west European languages.
+
+This article\footnote{Peter Galko
+ (\texttt{galko@trix.genie.uottawa.ca}) spurred this didactic effort
+ by requesting consumer oriented information on virtual fonts for
+ Textures. Special thanks are due to him for reading and criticizing.
+ Thanks also to Peter and Nicolas Jungers (\texttt{nj@fusl.ac.be})
+ for sharing the work to package and post the DM virtual fonts for
+ Textures.}
+%Indeed, Tutorial~3 is essentially our joint announcement
+% posted on the |Info-TeX| list in March 1994.
+%}
+is very much
+user-oriented in the sense that the main point is to deliver
+performance we have we have been dreaming of since Knuth\rq{}s virtual
+font standard was unveiled in 1989, using just the equipment and
+software we have today. In particular its sections are called
+ \lq{}tutorials\rq{}.
+
+ Users of other \TeX\ installations may find some \lq{}window shopper\rq{}
+interest in the following pages. Textures is one of the first
+implementations of \TeX\ to have made a living reality of
+\lq{}electronic paper\rq{} in the sense that through most of the \TeX\
+production cycle it is more pleasant to use preview than printed
+copy. This results from a number of features:
+
+\begin{itemize}
+\item Smooth linkage of editor and preview and \TeX. Typically
+just a couple of seconds separates typing from preview.
+\item Graphics preview (albeit bitmapped).
+\item Scalable fonts of high quality. The ATM (Adobe Type Manager)
+system for screen rendition of \lq{}hinted\rq{} Adobe Type~1 fonts is
+the secret here along with the CM/PS fonts.
+\item Fast preview. The user passes from one A4 preview page to the
+next in about .5 sec on a Mac with 33mhz, 68040 microprocessor.
+Compared with other previewers, Textures has a speed advantage
+factor of 2 or more (processor power considered).
+That can be
+expressed as an advantage of 4 years progress since average
+computer speed doubles in about that period.
+\end{itemize}
+Unfortunately this delightful environment has not been well
+adapted to use with European languages using accents, quite simply
+because there have been no (ready-made) accented characters
+attached to the CM/PS fonts --- until finally virtual fonts have
+made this possible as the tutorials will explain.
+
+ The issue of preview speed is troublesome to developers of
+virtual font previewers. The problem is very evident with Textures
+where a slowing factor of two is currently observed. It was
+recently mentioned by Berthold Horn [\BV\ 4.1,
+page 10] as a possible argument against virtual fonts. Since it
+tends to spoil the \lq{}electronic paper\rq{} feature of Textures that I
+value so highly, I was very concerned.
+
+ After having had a closer look I am reassured. The devices
+presented in this tutorial will suffice to skirt this difficlty,
+\emph{and}/\emph{or} a frontal attack will surely be launched to recover lost
+preview speed by reprogramming. Textures users should take heart
+and employ virtual fonts forthwith.
+
+
+\section{Tutorial 1: Textures virtual font resources}
+
+ A \lq{}virtual font\rq{} is in essence a \lq{}collage\rq{} of character
+images or \lq{}glyphs\rq{} taken from other fonts (virtual or ordinary).
+Its shapes are composites rather than distinctly new.
+
+ For example, the virtual font dmr10 contains a composite
+glyph |Eacute| made up of an acute accent |acute| from cmr10
+combined with |E| also from cmr10, each precisely positioned in a
+way specified by the virtual font. One might object that the same
+result on paper can always be produced by \TeX\ without virtual
+fonts. True, but to produce the result without can be painful.
+Particular painful would be the hyphenation of words containing
+|Eacute| and the kerning (or ligature) of |Eacute| with other
+letters.\footnote{Experts know that virtual font glyphs can contain a bit
+more than the DM fonts do : rules and specials --- the same sort
+of extras one finds in \TeX\rq{}s |dvi| output files. For more
+details, see Knuth\rq{}s article in TUGboat.}
+
+ Virtual fonts are ideal for efficiently building fonts
+with accented characters for French and other European
+languages. The first were perhaps the DM fonts of Nicolas
+Brouard and Wayne Sullivan, created for the 1990 GUTenberg PC
+\TeX\ distribution; they extend the CM fonts by adding accented
+characters in the positions specified by the layout standard
+referred to as \lq{}ISOLatin1\rq{}, essentially the top quarter
+(i.e., the 192--255 positions) of the \lq{}Cork\rq{} European norm
+(alias the DC font layout).
+
+ In standard \TeX\ implementations, virtual fonts are
+defined by two files: a |.tfm| binary file which \TeX\ uses in
+the typesetting phase to determine character sizes, kerning
+and ligatures; and a |.vf| binary file which the print driver
+uses to find out how to render a character in the virtual
+font.
+
+ The virtual font specification adopted by Textures is
+non-standard. But for good reasons: on current hard discs the minimal
+file size is 5K octets, which is usually significantly larger than a
+|.vf| and |.tfm| file combined, and the number of files the operating
+system can handle efficiently is often \lq{}too small\rq{}. This causes much
+time and disk space to be wasted. Imagine one wants to introduce 200
+virtual fonts. With standard \TeX\ this costs 400 files and say 2M
+octets (M for million) of disk space plus time costs for handling the
+files.
+
+ What about Textures? Textures puts the information contained
+in the |.vf| and |.tfm| files into a |*TFM| resource which is then made
+part of a font suitcase file. Thus to include these 200 virtual
+fonts, you add \emph{one} font suitcase file containing 200 |*TFM|
+resources, each of which combines .tfm and .vf information. Each
+tends to be 1--5K octet so the suitcase file will be less than
+1M octet. Very neat, and worth the change.
+
+
+\section{Tutorial 2: Textures \lq{}Type~1\rq{} virtual \TeX\ fonts}
+
+ Adobe Type~1 fonts are scalable PostScript fonts that contain
+\lq{}hints\rq{} for optimal rasterization on screen via ATM, and on
+paper via PostScript printers. The quality of a rasterized images
+that ATM produces, operating at interactive speeds, is
+comparable to that produced by \MF. Furthermore the speed of
+screen display via ATM is essentially the same as for bitmapped
+fonts --- after a moderate startup time, even though ATM
+never stores bitmaps permanently.
+
+ Users should beware however that the good speed
+performance quoted is only realized when sufficient memory
+has been allocated to ATM. A typical \TeX\ user needs about
+700Kb. The sign that you need to allocate more RAM to ATM is
+continual hard disk access when you are scrolling back over
+material you have already previewed.
+
+Since Textures switched to using Adobe Type~1 versions of CM fonts,
+users of ATM have benefitted from the possibility of previewing these
+fonts at any size. Unfortunately, these fonts do not include any
+characters with accents, which is a significant impediment to
+Europeans (the use of \TeX\rq{}s |\accent| primitive leaves much to be
+desired where hyphenation, kerning, ligatures and beauty are
+concerned.)
+
+Although there is still no extended set of CM-face fonts with accented
+characters in Adobe Type~1 format, ordinary extensions of the CM fonts
+are available in bitmapped form (notably the DC fonts of Schwartz that
+use the Cork encoding, and the TM fonts of Taupin that are fully
+compatible with CM---both freely available). \emph{However}, bitmapped
+screen fonts for prose are unreadable at most sizes, so they are
+disqualified in the ATM world that Blue Sky research has so
+wholeheartedly embraced by distributing its excellent CM/PS fonts as a
+standard part of Textures.
+
+ A few extended CM fonts in the form of virtual fonts have been in
+circulation since 1990, notably the DM fonts of Brouard-Sullivan.
+As implemented by Blue Sky research in Textures 1.6 of 1993 and
+later, the virtual font notion marries smoothly with Adobe Type~1
+fonts and ATM---to the point where there is no obvious way for
+the user to see the difference between virtual and non-virtual
+Type~1 font. Thus a virtual font is for \TeX\rq{}s purposes \lq{}of Adobe
+Type~1\rq{} as soon as the regular fonts on which it is based are
+themselves Adobe Type~1.
+
+ Often one understands by \emph{extended CM font} any font that is
+encoded (essentially) like a CM font in the segment 0--127 and
+(essentially) according to the Cork norm in the range 128--255.
+One has potentially an enormous class of such virtual extensions
+for Adobe Type~1 prose fonts. As matters stand these can be
+generated by Ji\v r\'\i\ Zlatu\v ska\rq{}s |accents| package available on
+the CTAN servers. Unfortunately |accents| has to my knowlege been
+compiled only on PC\rq{}s (no other binary has been posted).
+To my knowlege no virtual font produced by |accents|
+has ever been posted. This should be remedied.
+
+ What about Cork norm fonts? They disagree with CM
+fonts in the range 0--127. Consequently, they are not currently
+used in conjunction with (extended) CM encoding. (They could be
+--- as explained in my article in the 1992 Euro\TeX\ proceedings ---
+but there has not been sufficient demand.) I know of three
+Cork encoded virtual font series for Adobe Type~1 fonts, and all
+can be adapted to Textures using EdMetrics:
+\begin{enumerate}
+\item a series posted by Haralambous on |ftp.dmi.ens.fr|
+and derived from his Vulcano utility. This covers only
+the range 192--255.
+\item a series posted by Nicolas Jungers on |matups.matups.fr|.
+It includes a sprinkling of characters in the range 128--191,
+notably |section| and |pounds| plus letters with \lq{}hacek\rq{} accent.
+\item a series generated using |fontinst| by Sebastian Rahtz on CTAN
+ (in |fonts/metrics|)
+\end{enumerate}
+All these postings cover a selection of commonly used
+fonts including the basic LaserWriter series.
+
+
+
+\section{Tutorial 3: Textures DM virtual fonts}
+
+Apart from some sample files, only one virtual font was distributed
+with Textures in 1993, namely MTMI, the MathTime math italic that
+builds on Times Italic and a \lq{}raw\rq{} math font RMTMI. Obviously
+it would be a healthy thing for more virtual fonts to become available
+in Textures format. Blue Sky Research, the makers of Textures provide
+a tool called EdMetrics that (with version 0.7 or later) is capable of
+converting a virtual font specified in its human readable text form as
+a \lq{}.vpl\rq{} file into a Textures |*TFM| resource format and
+placing the resource in a suitcase. The \lq{}.vpl\rq{} file is, in
+\TeX\rq{}s standard font administration, used to construct both the
+.vf and .tfm files for the font using a utility \lq{}vptovf\rq{}.
+EdMetrics includes something like \lq{}pltovf\rq{}. Recall the
+etymologies:
+\lq{}.tfm\rq{}=\lq{}TeX font metric\rq{}; \lq{}.vf\rq{}= \lq{}virtual font\rq{} and
+\lq{}.vpl\rq{}=\lq{}virtual property list\rq{}.
+
+To introduce Textures users to virtual fonts, we have made available
+the original series of DM virtual fonts in Textures format. There are 55
+of them. We provide them in a Textures font suitcase called \lq{}DM
+metrics\rq{} occupying 210Kb. They are packaged as a binhexed
+self-extracting Macintosh archive file whose name begins DM-VFs
+(see \lq{}References\rq{} below).
+
+Install these VF\rq{}s by simply pushing the suitcase into the
+\lq{}TeX Metrics\rq{} or \lq{}TeX Fonts\rq{} folder. More on
+exploiting them in later tutorials.
+
+If you examine one of these |*TFM|\rq{}s with EdMetrics you will see
+that nothing tricky is involved (it seems); we have done nothing
+original---such as create a new virtual font. For that you would be
+well advised to join the Metafont email list.
+
+Even without further coaching, you will manage to produce more VFs for
+Textures starting from generic virtual fonts posted on the CTAN \TeX\
+archives. It\rq{}s worth trying. EdMetrics may cause crashes --- but be
+assured that Blue Sky Research is working on it. Soon the whole
+process will be dispatched with a few mouse clicks.
+
+\section{Tutorial 4: Trying out extended CM fonts for Textures}
+
+The following tutorial will let you try out
+the Textures DM virtual fonts presented in the
+previous tutorial. It is framed for Plain \TeX\ and
+its direct extensions. You will probably find that it works in
+any environment that: (a) is able use virtual
+fonts, (b)~uses Computer modern fonts, and (c) uses
+the font nomenclature of Plain \TeX. In particular,
+NFSS users are advised to revert to Plain TeX for the trials.
+
+Try the following instructive exercises.
+A later tutorial will propose an efficient
+working setup (valid for NFSS).
+\begin{enumerate}
+\item Install these VF\rq{}s by simply pushing the suitcase into
+the \lq{}TeX Metrics\rq{} or \lq{}TeX Fonts\rq{} folder
+\item Put these fonts into service in place of the similar CM
+fonts by the command |\DMtext| defined as follows:
+\begin{verbatim}
+\def\gobble#1{}
+\def\repeatfont{\edef\temp{%
+ \expandafter\string\the\font}%
+ \csname\expandafter\gobble\temp\endcsname}
+
+\def\DMtext{%
+ \font\tenrm=dmr10
+ \font\ninerm=dmr9
+ \font\tenbx=dmbx10
+ \font\ninebx=dmbx9
+ \font\tenti=dmti10
+ \font\nineti=dmti9
+ \font\tensl=dmsl10
+ \font\ninesl=dmsl9
+ \repeatfont}
+\end{verbatim}
+and return by using |\CMtext|:
+\begin{verbatim}
+\def\CMtext{%
+ \font\tenrm=cmr10
+ \font\ninerm=cmr9
+ \font\tenbx=cmbx10
+ \font\ninebx=cmbx9
+ \font\tenti=cmti10
+ \font\nineti=cmti9
+ \font\tensl=cmsl10
+ \font\ninesl=cmsl9
+ \repeatfont}
+\end{verbatim}
+The greatest potential weakness of these provisional macros is their
+dependence on Plain \TeX\rq{}s nomenclature. In other formats |\tenrm|
+(etc.) may become another control sequence. The above DM fonts are
+the main prose fonts of the first DM distribution for Textures. If
+you have more DM fonts installed you can extend the list at the cost
+of slowing the macros. By
+using the command |\showthe\font| you can see whether the new fonts
+are being used.
+\begin{smalldesc}
+\item[\TeX\ user:] Where do I put these macro definitions,
+and how do I use them?
+\item[The Lion:] Your style file for your current article
+would be a natural place.
+\end{smalldesc}
+\item To see the characters available in any font (say dmr10)
+compile the file |FontTable256Hack.tex| after decommenting the line
+\begin{verbatim}
+ \def\fontname{dmr10 scaled 1720}
+\end{verbatim}
+Just one line of this sort should be active. Preview and print to
+learn what characters the DM fonts offer.
+\item To be able to access the new accented characters using
+Knuth\rq{}s syntax |\'e| for |e-acute| etc. put
+|\input caesarcm| at the head of your typescript.
+
+\begin{smalldesc}
+ \item[\TeX\ user:] But that syntax already works \emph{without} CaesarCM!
+ \item[The Lion:] Yes, but it has been giving you \emph{composite}
+characters in \TeX\ and they slightly damage kerning, ligatures, and
+hyphenation. To see a modest objective difference, typeset
+\begin{verbatim}
+ \CMtext \'ex\'ex\'ex\'ex\'ex\'ex\'ex\'ex\par
+ \DMtext \'ex\'ex\'ex\'ex\'ex\'ex\'ex\'ex\par
+\end{verbatim}
+|\DMtext| provides extra kerning; this is possible since |\'e| yields
+a true letter in the DM fonts and this letter appears in kerning tables
+of dmr10 etc; but not in those of cmr10 etc.
+
+ \item[\TeX\ user:] I am pleased enough to have these fine adjustments
+which dmr10, etc., offer. But I don\rq{}t want to have pay a heavy price.
+In particular I do not want to type |\'e|; that is a big pain. For
+quite some time a macro file called |option_keys| has let me
+instead type the regular Macintosh e-acute character (call it
+|Mac-e-acute|.
+
+ \item[The Lion:] In just a moment, you will be able to type either
+way! The service Caesar \emph{alone} provides is to assure that \emph{for
+the output} the best form of |e-acute| the font has available is
+used, and it makes that |e-acute| behave as best one can.
+All \emph{automatically}.
+\end{smalldesc}
+
+\item To be able to directly type Mac 8-bit characters put
+|\input Active8MacCM.tex|
+ at the head of your typescript, following |\input caesarcm|.
+\begin{smalldesc}
+ \item[\TeX\ user:] But isn\rq{}t |\input option_keys| recommended instead
+by Blue Sky Research.
+ \item[The Lion:] The |option_keys| file of the current Textures
+distribution (maybe the name is slightly different) is a valid
+alternative (in the presence of CaesarCM) provided you are
+willing and able to avoid the \TeX\ primitives |\lowercase| and
+|\uppercase|, which misbehave outrageously under |option_keys|.
+|Active8MacCM.tex| does not really maintain good behaviour of
+the \TeX\ primitives |\lowercase| and |\uppercase|, but it provides
+good replacement macros instead: |\Lowercase| or |\eLowercase|
+and |\Uppercase| or |\eUppercase|.
+
+ \item[\TeX\ user:] But please, even if |Active8MacCM.tex| does better
+than |option_keys| for alphabetical material, I would like to keep
+the performance of |option_keys| for non-alphabetical stuff.
+ \item[The Lion:] |\input option_keys| followed by (the order matters!)
+|\input Active8MacCM.tex| should do the trick.
+\end{smalldesc}
+\item To enjoy (say) French hyphenation, rename the French 8-bit
+hyphenation file (say |fr8hyph.ck| --- see references) as
+hyphen.tex and then recompile plain.tex and when \TeX\ gives you its *
+prompt, type |\dump| and |return| to get (say) fPlain format. This
+requires initex for generic implementations. For Textures
+(version 1.6 or later, please), one uses the format \lq{}Virtex\rq{}.
+\begin{smalldesc}
+ \item[\TeX\ user:] I have never used virtex or initex or any of
+that jazz. Maybe this is where I get |\dump|\rq{}ed!
+ \item[The Lion:] Wait a minute. This is where, in reality, the
+fattest dividend comes: hyphenation for good linebreaking in
+just about any European language. Learning to understand
+how \TeX\ works, will pay enormous dividends in the long run;
+indeed \TeX\ is truly an open system whose secrets can be had for
+the asking. But OK, so many things get mixed up in the matter of
+format building that we all need help. Check your local
+documentation on initex/virtex. Some day there will be powerful
+assistants available for format building; for a prototype
+(concentrating on French and English) see \lq{}format-dumper-cm\rq{}.
+\end{smalldesc}
+\item To see why a virtual font deserves the epithet \lq{}virtual\rq{},
+activate the \lq{}Save as\ldots \rq{} menu choice while the font table\rq{}s
+preview window is active, and save in Illustrator88 format. The
+result is a PostScript file that Adobe Illustrator can open
+directly. If you peek inside this file with a text editor after
+changing its type to TEXT you will find that the font dmr10 is
+\emph{absent}; in its stead you find cmr10 listed in the font roster.
+If you are fortunate enough to have a recent version of Adobe
+Illustrator (issued after the appearance of ATM), you will see
+something much more dramatic by simply opening the Illustrator
+file. When you zoom in on the letter |eacute|, its composite
+nature becomes visible. It is made up of two text records both
+from the font cmr10: one for the |e| and one for the acute accent.
+Each can be independently edited within Illustrator. Blue Sky has
+thus concealed in the Textures\rq{} \lq{}Save as\ldots\rq{} option
+a \lq{}dvi-to-postscript\rq{} converter of a particularly useful sort: the
+output can be reprocessed! Professionals prize this feature for
+interactively inserting labels composed by \TeX\ into figures
+produced by Illustrator.
+\begin{smalldesc}
+\item[\TeX\ user:] I have glimpsed tempting features but I am worried
+about the effort required to put the whole act together in a form
+suitable for everyday use with Textures.
+\item[The Lion:] For that, a different sort of tutorial is needed.
+Come back tomorrow.
+\end{smalldesc}
+\end{enumerate}
+And the Lion stretched out to take a nap in the shade
+of the hyphenation trie.
+
+\section{Tutorial 5: Tutorial on setting up DM fonts for Textures 1.6.X}
+
+ The aim of this tutorial is to discuss every-day use of the
+virtual DM fonts to improve on the hyphenation and kerning offered
+by the CM/PS fonts distributed with Textures. The main task is to
+set up a bilingual format under Textures, letting one take
+advantage of the accented characters in the DM fonts. The term
+\lq{}bilingual\rq{} should initially be read here as \lq{}French and English\rq{}.
+With the help of the Babel package, it will be possible
+progressively to deal with any small collection of European
+languages; it is a matter of ironing out isolated difficulties
+--- and that has already been done fairly thoroughly for French
+and English.
+\begin{enumerate}
+\item Use the format-dumper-cm directory (see \lq{}References\rq) to
+compile one of the basic formats Plain, \LaTeX, \AmSTeX or \LamsTeX\
+in bilingual form. To start the process, it suffices to launch the
+file \lq{}initex.me\rq{} under Textures\rq{}s version of initex, which has the
+form of a \TeX\ format called \lq{}virtex\rq{}. (This initex presentation is
+nonstandard but \emph{very} convenient.) As accent administration
+package, choose CaesarCM rather than HyAccCM. Choose CM fonts if a
+choice is offered; this will not prevent the use of DM fonts.
+Other choices are up to you.
+
+ Name the resulting format and place it in the folder
+(=directory) |TeX Formats|. When you want to enjoy DM fonts,
+remember to select this format.
+
+\item To permit Macintosh 8-bit typing of accented characters
+ optionally add
+Active8MacCM.tex to the above format. Do this by compiling the
+following tiny file with the above format:
+\begin{verbatim}
+%\input option.keys %% optional
+\input Active8MacCM.tex
+\dump
+\end{verbatim}
+and have the new format replace the above format.
+\item Place the suitcase of Textures DM fonts into your \TeX\ Fonts
+folder. To prevent confusion and duplications, you should have
+only one such suitcase for DM fonts.
+\item Load the macro file |dmview.sty| in the usual way.
+
+This file contains slightly modified definitions of the macro
+commands |\DMtext| and |\CMtext| discussed in the last tutorial. Recall
+that the command |\DMtext| switches in the basic DM text fonts
+hopefully in a way making them replace the corresponding CM fonts.
+|\CMtext| switches back.
+
+ There is additionally a convenient and powerful command |\DMpar|, roughly
+equivalent to |\DMtext| now, followed by |\CMtext| at the next end of
+paragraph. Whereas these two fail if the fonts are changed
+by non-standard commands like |\smallroman|, |\DMpar| deals optimally
+with whichever font is current. Hence |\DMpar| should be used almost
+exclusively.
+
+ The accompanying file |dmview.tst| will let you test these
+macros with the format you have compiled.
+\end{enumerate}
+
+\begin{smalldesc}
+ \item[\TeX\ user:] Why not switch to DM fonts from the outset and
+never return?
+
+ \item[The Lion:] Some day that will surely be the thing to do; indeed
+DM fonts would then be preloaded in place of CM fonts. At present
+however, it is a simple problem of preview speed that argues for using
+CM fonts most of the time. In February 1994, the virtual DM fonts
+consume \emph{twice} the time for previewing; and that is a big time
+sacrifice that few users are happy to make all the time.
+
+
+ \item[\TeX\ user:] How unfortunate. I use a Macintosh SI
+that requires about 2 seconds to preview an A4 page.
+I would like to see the preview move faster not slower!
+I recall that Adobe Type~1 fonts such as
+CM/PS were a joy from the day I got them because previewing
+remained just as fast as for non-scalable bitmapped fonts.
+Admittedly, there is a time penalty of few seconds when the
+previewing begins, but thereafter nothing noticeable.
+ Are you suggesting I can use the DM fonts effectively while
+avoiding time wastage?
+
+ \item[The Lion:] Indeed you can, and |dmview.sty| is there to
+assist you. To begin with, so long as you print rather than
+preview, you can use the DM fonts as much as you like without
+paying a time penalty. This is because the printer is then
+the bottleneck, not the virtual fonts.
+
+ Where previewing is concerned, a flexible strategy is
+required to avoid losing half your preview speed. Basically,
+you use CM fonts until the preview reveals inadequate
+hyphenation and then insert |\DMpar| at the beginning of any
+paragraph needing better hyphenation. Since the use of DM
+fonts is thus restricted to the few paragraphs with an added
+|\DMpar|, the slowing of preview should be slight, typically 5\%
+to 10\%.
+
+
+ \item[\TeX\ user:] Inserting |\DMpar| may not be too difficult in
+itself; but no one will be happy to learn a new typesetting
+procedure.
+
+ \item[The Lion:] Ah, but cleaning up bad linebreaks is is a
+quite inevitable part of typesetting! The bad breaks
+entailed in starting out with CM/PS rather than DM will
+normally be a modest fraction of the total --- from
+mathematics, from accidents of page design, from neologisms,
+and (surprisingly important) from words spelled with an
+explicit hyphen. Better learn to concentrate this inevitable
+job at a single late stage of typesetting, say by initially
+using plenty of |\emergencystretch|. Then do the job
+efficiently, say with instant preview (via Lino\TeX) of
+difficulty paragraphs. There is more on this
+in the last tutorial.
+
+
+\item[\TeX\ user:] I will have to see what works best. Long
+ago, I used preview very little; so I know I can get the best
+possible results without preview, provided, in proofing, I
+splurge and use a good deal of extra paper. Since the coming
+of the CM/PS fonts and ATM, I always insist on previewing
+even when I have a printer beside me.
+ In previewing, is a big time disadvantage of virtual fonts
+inevitable? I mean for users who do not resort to tricks like
+|\DMpar|.
+
+ \item[The Lion:] I should hope not; the future of \TeX\rq{}s font
+system depends on it! One \TeX\ previewer has cut the time
+disadvantage of virtual fonts to under 20 percent.
+
+ \item[\TeX\ user:] I would bet on Textures taking up the
+challenge. Textures has the best record for speed among \TeX\
+implementations on the Macintosh, and speed is one of the
+best features of Textures.
+
+ \item[The Lion:] With substantial parts of Textures in
+assembly language, Textures has a headstart in speed
+analysis. But these things take time, even when there is a
+good idea available such as one sees in Oz\TeX{} 1.6x. Better
+not to hold your breath while waiting.
+
+
+ \item[\TeX\ user:] Overall, this DM setup sounds neat, I grant you,
+at least if I manage to learn the tricks you mention. But I
+cannot help thinking how much simpler it would be to use new
+extended Macintosh encoded CM/PS fonts that mesh perfectly with
+the recently distributed Macintosh encoded Adobe Times, etc.
+Thanks anyhow.
+
+ \item[The Lion:] Wishful thinking! No Macintosh encoded
+extension of the CM/PS fonts has been announced as of February
+1994. Nor acknowledged as a project. Further, use of Macintosh
+encoding (really Textures\rq{} own idiosyncratic version of Mac
+encoding) requires a good deal of special parametering of
+existing \TeX\ software (CaesarCM, NFSS, all hyphenation packages,
+etc.). As things stand, you the \TeX\ user will have to put your
+shoulder to the wheel to make Textures work smoothly with the
+Macintosh encoding.
+
+
+ \item[\TeX\ user:] OK, but to be perfectly frank, I am still uneasy
+about using a system that is out of line with Times, Helvetica,
+etc. as currently distributed with Textures.
+
+ \item[The Lion:] Only a demanding user will notice that anything
+whatever is out of line! That is because CaesarCM already does a
+remarkably good job using just the segment 0--127 where the
+Macintosh and CM encodings essentially agree. Better, it is
+possible to make the 8-bit Type~1 fonts distributed by Adobe
+mesh perfectly with the DM fonts, indeed without any sacrifice of
+preview speed; see the \lq{}xAdobeTextures\rq{} font posting on the CTAN
+servers.
+
+\end{smalldesc}
+
+\section{Tutorial 6 Maintaining preview speed with Textures\rq{} virtual fonts}
+
+ The following indicates in more detail how to start with CM/PS
+fonts and land up with irreproachable linebreaking and kerning
+using DM fonts while nevertheless avoiding substantial slowing of
+Textures\rq{} preview (version 1.6.x).
+
+ There are a number of settings that will permit you to delay
+the cleanup of line breaking problems (involving introduction
+of DM fonts) until the article\rq{}s content is complete and stable:
+\begin{verbatim}
+\emergencystretch=25pt %% Plain default is 0pt
+ %% suppresses underfull line complaints
+\tolerance=10000 %% default is 100
+\overfullrule=0pt %% default is 10pt
+ %% makes line overruns less visible
+\hfuzz=\hsize %% default is 0pt
+ %% suppresses overfull line complaints
+\end{verbatim}
+
+The comments here are mere hints about complex behaviour; see the
+\TeX book for an accurate account. The complexity can however be
+handled empirically (athletically!) by varying the parameters.
+
+\begin{smalldesc}
+ \item[\TeX\ user:] How does this square with the uncompromising quality
+\TeX\ boasts of?
+ \item[The Lion:] Everything in its due time! Demanding perfection at
+an early stage can be counterproductive in many typesetting
+environments.
+\end{smalldesc}
+
+ When the time for cleanup of linebreaking comes, return
+toward the default values. Perhaps not all the way if the lines
+are short. And perhaps by stages since many complaints in the
+log confuse the mind and slow \TeX\ down.
+
+Experience suggests that, in French for example, most of your
+line-breaking problems will have nothing to do with the failings of
+CM/PS fonts as administered by CaesarCM. To scan efficiently for
+these problems, the maximum Textures preview speed is a blessing not
+to be abandoned lightly. Further, use of some sort of instant preview
+of modified paragraphs is highly desirable because several successive
+corrections are often required. This is provided by Textures\rq{}
+\lq{}Lightning\rq{} mechanism if the typescript has just a few pages. But in
+general one should seriously consider using LinoTeX (see \lq{}References\rq{}
+below) to get recomposition of single paragraphs in just a couple of
+seconds (Lino\TeX\ serves Textures and Oz\TeX.).
+
+ Every five pages or so, you can expect a line breaking
+problem of the sort that will be fixed by using DM fonts rather
+than CM/PS. Not more often because CaesarCM incorporated
+Desarmenien\rq{}s device for allowing hyphenation far from accents
+with CM fonts. Recall that one inserts the command |\DMpar| at the
+beginning of each troublesome paragraph to bring DM fonts unto
+play for just that paragraph. If your font system is exotic, you
+may also have to insert |\DMpar| after font switches within the
+paragraph. In this way you should be able to get linebreaking as
+good as you please at an average cost of something like a 5\% or
+10\% slowing of the preview.
+
+\begin{smalldesc}
+ \item[\TeX\ user:] Instead, why not simply hand hyphenate the the
+word causing trouble, using |\-|. That is what I have been doing
+for years!
+
+ \item[The Lion:] Not too bad a solution if you really know the
+rules of hyphenation of the language. Remember though that you
+should then always take the time to provide the complete
+hyphenation; otherwise you risk causing bad breaks later on.
+Indeed a word containing |\-| is not further hyphenated by \TeX.
+Popping in |\DMpar| is a solution unrivaled for simplicity. Also it
+produces statistically better results. Indeed many new line break
+points become available throughout the paragraph; and \TeX\ can
+often use these to overcome the difficulty without breaking the
+word you would guess!
+\end{smalldesc}
+ After linebreaking has been perfected, comes the time to
+perfect pagebreaking --- and not before since the former
+significantly influences the latter. This pagebreaking again
+calls for the fast previewing you hopefully will have preserved.
+
+ Perfectionists will want to switch globally to DM fonts
+before final printing --- not so much to further improve
+linebreaking as to assure perfect kerning between an accented
+character and an immediately preceding character. Such kerning is
+not available with the unextended CM fonts. If high resolution is
+to be used for final printing, such a switch perhaps justifies the
+extra time required to recheck pagebreaks.
+
+ With Textures there is a convincing trick that lets one see
+many small differences that the improved kerning of DM fonts will
+bring. Begin with a chapter with many accents prepared as above;
+put |\DMtext| in the header and recomposes; but immediately upon
+launching composition, click on the preview window of page 2
+(say) of the first version which will still be on view; shortly, the
+the change to the DM font version will be clearly visible; more
+likely than not there will be no change of linebreaks and
+pagebreaks; but you are almost sure to see slight lateral motion of
+many characters in response to new kerning around accented
+characters.
+
+\begin{smalldesc}
+ \item[\TeX\ user:] So far so good. But I know from experience there
+is bad trouble ahead, at least in the case of a big job like a
+book. Final checking of pagebreaks and even linebreaks is
+absolutely obligatory after switching fonts; otherwise the
+insistance on typographic quality may backfire badly. But the
+Textures preview is now twice as slow, just when one wishes it were
+twice as fast. Reverting to printed copy at this point is a dreadful
+waste of paper, and not particularly efficient at that. The time
+loss here is not worrysome for a small job because it is moderate
+compared with other delays, notably various startup times. But for
+a big job I wonder whether I would be willing to attempt the full
+switch to DM fonts!
+
+ \item[The Lion:] A lion\rq{}s pride demands uncompromising quality.
+Your scenario for big jobs seems to call for a \emph{deus ex machina}!
+\end{smalldesc}
+ The idea is to pass the Textures .dvi file(s) through P.
+Breitenlohner\rq{}s DVIcopy utility; that will replace each virtual DM
+character by the corresponding array of non-virtual CM characters.
+The resulting .dvi file is without virtual fonts and will preview
+at top speed in Textures (Textures version 1.6.4 and
+later, please; earlier versions have a bug from faulty
+optimization causing displacement of many accents to the
+right.). Oz\TeX{}, in versions 1.6x, includes in its
+driver a fast and reliable version of this utility, serving as
+the basis of Oz\TeX{}\rq{}s use of virtual fonts. It can conveniently be
+conscripted for the task, provided generic DM virtual fonts have
+been installed for Oz\TeX. Thus the \emph{deus ex machina} for
+big jobs --- is Oz\TeX{}!
+
+ This detour via Oz\TeX{} brings an extra benefit: the resulting
+CM based |dvi| files are highly portable because the CM fonts are
+Knuth\rq{}s standard fonts for \TeX. Users are fortunate that Oz\TeX{}
+and Textures have adopted different approaches to virtual fonts!
+
+ Perhaps some day Textures too will have the \lq{}DVIcopy\rq{}
+feature; that would make life simpler for Textures users. In the
+interim this tutorial should help users get the best possible
+results from DM fonts --- at the moderate price of being well
+informed!
+
+\section{References}
+The software described in this article, Textures excepted, has its
+current master posting on |matups.matups.fr| and most of it is
+mirrored on the CTAN anonymous ftp servers.
+The current locations on |matups.matups.fr|
+are |/pub/TeX/| followed by:
+\par{\small\begin{verbatim}
+Fonts.dir
+ FontTable256*, xAdobe-Textures*, K-PS.dir
+Fonts.dir/DM.dir
+ dm-table.txt, dmview*
+Fonts.dir/DM.dir/TexturesDMs.dir
+ DM-VFs*, TexturesDM-VFs.readme
+format-dumper-cm.dir
+ caesarcm.tex, fr8hyph.ck, initexme.tex
+LinoTeX.dir
+oztex.dir (version 1.6) shareware at $30
+TypingTeX.dir
+ Active8MacCM.tex
+\end{verbatim}
+For Textures utilities such as EdMetrics consult the anonymous
+ftp site |ftp.bluesky.com|. There is also an email help address
+|help@bluesky.com|.
+}
+
+\end{Article}
+\endinput
+
+
+I believe that speeds
+of up to a physiological limit of about 30 pages per second will
+bring benefit to the user; thats how fast I scan through a paper
+book with paper edges cleanly cut to facilitate this.
+Progressively, we will be doing a
+a lot of reading on \TeX-formatted electronic paper.