diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /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.tex | 780 |
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. |