Subject: TeXhax Digest V90 #11 From: TeXhax Digest Errors-To: TeXhax-request@cs.washington.edu Maint-Path: TeXhax-request@cs.washington.edu To: TeXhax-Distribution-List:; Reply-To: TeXhax@cs.washington.edu TeXhax Digest Sunday, January 14, 1990 Volume 90 : Issue 11 Moderators: Tiina Modisett and Pierre MacKay %%% The TeXhax digest is brought to you as a service of the TeX Users Group %%% %%% in cooperation with the UnixTeX distribution service at the %%% %%% University of Washington %%% Today's Topics: Implementers: change file depository psfig macros Virtual fonts: More fun for Grand Wizards --------------------------------------------------------------------------- Date: Mon, 08 Jan 90 19:16:27 -0500 From: mrd@image.soe.clarkson.edu Subject: Implementers: change file depository Keywords: information, change file, depository There currently isn't any one place where change files are stored; they are scattered among the machines of the various authors. This is confusing so I want to set up a depository for change files. The disk space is easy, so is the archive end but I don't have the time to keep track of who has the newest change file for xxx.web; therefore, I need your help. If you are the author of a change file(s) that can be stored here at Clarkson than please let me know about it. version of xxx.web your change file is for (eg. tex.web 2.992): machine that xxx.ch is for (eg. BSD 4.3): where it lives and how to get it (eg. on xxx.yyy.edu anonymous ftp in pub/tex or "I will email it to you") I would apprete it if the above information was at the top of the change file and a date or version number. Finally when ever you update your change files, you let me know about it so that my archive is always up to date. Since I have your attention is a top level list of TeX like stuff here at the archive. There is a lot more stuff so I encourage you to look around. Files are available via anonymous ftp to sun.soe.clarkson.edu or email. Email to archive-server@sun.soe.clarkson.edu mail a message that contains: help path a_domain-style_path_from_Clarkson_to_you amstex The AMSTeX macros amstex-style style files for AMSTeX archive-server A electronic mail Archive Server bibtex The .web, documentation and styles from Leslie Lamport bibtex-style style files for BibTeX version 0.99 bibtex-style-0.98 style files for BibTeX version 0.98 canon300 TeX pk fonts for canon based printers cm-fonts The .mf sources for the cm fonts dvi-standard Digests from the DVI driver standard committee errata TeX error logs for programs and documentation fonts118 TeX pk fonts at 118 dpi fonts96 TeX pk fonts at 96 dpi lamport style files and .mf files by Leslie Lamport latex-style style files for LaTeX mf the .web files for Metafont mfware MetaFont utilities pictex source for PiCTeX richof300 TeX pk fonts for richof based printers tex-fonts contributed mf fonts tex-programs Assorted useful program for TeX tex-sources The .web files for TeX tex-style style files for TeX texhax Collection of TeXhax's by Pierre MacKay (Malcolm Brown) texlib Assorted .mf and .tex files used by TeX texmag Collection of TeXMaG's by Don Hosek texware TeX utilities tfm TeX tfm files transfig translate fig code to other graphics languages tugboat files from TugBoat uktex Collection of UKTeX's by Peter Abbott web The WEB system (for TeX) web2c Converts web files to C ---------------------------------------------------------------------- Date: Mon, 8 Jan 90 13:20:03 MST From: hammond@solary.colorado.edu (Anne Hammond) Subject: psfig macros Keywords: psfig/TeX We are looking for the psfig/TeX macro package, as documented by Trevor Darrell, January 1987. We would appreciate receiving a copy, plus any comments from your usage of the package. Anne M. Hammond Solar Research Group University of Colorado, Boulder 303-492-5578 --------------------------------------------------------------------------- %%Moderators' note: Due to its length, the following submission %%is continued in TeXhax Digest Issue 12. Date: 08 Jan 90 1727 PST From: Don Knuth Subject: Virtual fonts: More fun for Grand Wizards Keywords: fonts Many writers to TeXhax during the past year or so have been struggling with interfaces between differing font conventions. For example, there's been a brisk correspondence about mixing oldstyle digits with a caps-and-small-caps alphabet. Other people despair of working with fonts supplied by manufacturers like Autologic, Compugraphic, Monotype, etc.; still others are afraid to leave the limited accent capabilities of Computer Modern for fonts containing letters that are individually accented as they should be, because such fonts are not readily available in a form that existing TeX software understands. There is a much better way to solve such problems than the remedies that have been proposed in TeXhax. This better way was first realized by David Fuchs in 1983, when he installed it in our DVI-to-APS software at Stanford (which he also developed for commercial distribution by ArborText). We used it, for example, to typeset my article on Literate Programming for The Computer Journal, using native Autologic fonts to match the typography of that journal. I was expecting David's strategy to become widely known and adopted. But alas --- and this has really been the only significant disappointment I've had with respect to the way TeX has been propagating around the world --- nobody else's DVI-to-X drivers have incorporated anything resembling David's ideas, and TeXhax contributors have spilled gallons of electronic ink searching for answers in the wrong direction. The right direction is obvious once you've seen it (although it wasn't obvious in 1983): All we need is a good way to specify a mapping from TeX's notion of a font character to a device's capabilities for printing. Such a mapping was called a "virtual font" by the AMS speakers at the TUG meetings this past August. At that meeting I spoke briefly about the issue and voiced my hope that all DVI drivers be upgraded within a year to add a virtual font capability. Dave Rodgers of ArborText announced that his company would make their WEB routines for virtual font design freely available, and I promised to edit them into a form that would match the other programs in the standard TeXware distribution. The preparation of TeX Version 3 and MF Version 2 has taken me much longer than expected, but at last I've been able to look closely at the concept of virtual fonts. (The need for such fonts is indeed much greater now than it was before, because TeX's new multilingual capabilities are significantly more powerful only when suitable fonts are available. Virtual fonts can easily be created to meet these needs.) After looking closely at David Fuchs's original design, I decided to design a completely new file format that would carry his ideas further, making the virtual font mechanism completely device-independent; David's original code was very APS-specific. Furthermore I decided to extend his notions so that arbitrary DVI commands (including rules and even specials) could be part of a virtual font. The new file format I've just designed is called VF; it's easy for DVI drivers to read VF files, because VF format is similar to the PK and DVI formats they already deal with. The result is two new system routines called VFtoVP and VPtoVF. These routines are extensions of the old ones called TFtoPL and PLtoTF; there's a property-list language called VPL that extends the ordinary PL format so that virtual fonts can be created easily. In addition to implementing these routines, I've also tested the ideas by verifying that virtual fonts could be incorporated into Tom Rokicki's dvips system without difficulty. I wrote a C program (available from Tom) that converts Adobe AFM files into virtual fonts for TeX; these virtual fonts include almost all the characteristics of Computer Modern text fonts (lacking only the uppercase Greek and the dotless j) and they include all the additional Adobe characters as well. These virtual fonts even include all the "composite characters" listed in the AFM file, from `Aacute' to `zcaron'; such characters are available as ligatures. For example, to get `Aacute' you type first `acute' (which is character 19 = ^S in Computer Modern font layout, it could also be character 194 = Meta-B if you're using an 8-bit keyboard with the new TeX) followed by `A'. Using such fonts, it's now easier for me to typeset European language texts in Times-Roman and Helvetica and Palatino than in Computer Modern! [But with less than an hour's work I could make a virtual font for Computer Modern that would do the same things; I just haven't gotten around to it yet.] [A nice ligature scheme for dozens of European languages was just published by Haralambous in the November TUGboat. He uses only ASCII characters, getting Aacute with the combination |. \yskip\hang|@!fnt_def4| 246 |k[4]| |c[4]| |s[4]| |d[4]| |a[1]| |l[1]| |n[a+l]|. Define font |k|, where |@t$-2^{31}$@><=k<@t$2^{31}$@>|. \yskip\noindent These font numbers |k| are ``local''; they have no relation to font numbers defined in the \.{DVI} file that uses this virtual font. The dimension~|s|, which represents the scaled size of the local font being defined, is a |fix_word| relative to the design size of the virtual font. Thus if the local font is to be used at the same size as the design size of the virtual font itself, |s| will be the integer value $2^{20}$. The value of |s| must be positive and less than $2^{24}$ (thus less than 16 when considered as a |fix_word|). The dimension~|d| is a |fix_word| in units of printer's points; hence it is identical to the design size found in the corresponding \.{TFM} file. @d id_byte=202 @= @!vf_file:packed file of 0..255; @ The preamble is followed by zero or more character packets, where each character packet begins with a byte that is $<243$. Character packets have two formats, one long and one short: \yskip\hang|long_char| 242 |pl[4]| |cc[4]| |tfm[4]| |dvi[pl]|. This long form specifies a virtual character in the general case. \yskip\hang|short_char0..short_char241| |pl[1]| |cc[1]| |tfm[3]| |dvi[pl]|. This short form specifies a virtual character in the common case when |0<=pl<242| and |0<=cc<256| and $0\le|tfm|<2^{24}$. \yskip\noindent Here |pl| denotes the packet length following the |tfm| value; |cc| is the character code; and |tfm| is the character width copied from the \.{TFM} file for this virtual font. There should be at most one character packet having any given |cc| code. The |dvi| bytes are a sequence of complete \.{DVI} commands, properly nested with respect to |push| and |pop|. All \.{DVI} operations are permitted except |bop|, |eop|, and commands with opcodes |>=243|. Font selection commands (|fnt_num0| through |fnt4|) must refer to fonts defined in the preamble. Dimensions that appear in the \.{DVI} instructions are analogous to |fix_word| quantities; i.e., they are integer multiples of $2^{-20}$ times the design size of the virtual font. For example, if the virtual font has design size $10\,$pt, the \.{DVI} command to move down $5\,$pt would be a \\{down} instruction with parameter $2^{19}$. The virtual font itself might be used at a different size, say $12\,$pt; then that \\{down} instruction would move down $6\,$pt instead. Each dimension must be less than $2^{24}$ in absolute value. Device drivers processing \.{VF} files treat the sequences of |dvi| bytes as subroutines or macros, implicitly enclosing them with |push| and |pop|. Each subroutine begins with |w=x=y=z=0|, and with current font~|f| the number of the first-defined in the preamble (undefined if there's no such font). After the |dvi| commands have been performed, the |h| and~|v| position registers of \.{DVI} format are restored to their former values, and then |h| is increased by the \.{TFM} width (properly scaled)---just as if a simple character had been typeset. @d long_char=242 {\.{VF} command for general character packet} @d set_char_0=0 {\.{DVI} command to typeset character 0 and move right} @d set1=128 {typeset a character and move right} @d set_rule=132 {typeset a rule and move right} @d put1=133 {typeset a character} @d put_rule=137 {typeset a rule} @d nop=138 {no operation} @d push=141 {save the current positions} @d pop=142 {restore previous positions} @d right1=143 {move right} @d w0=147 {move right by |w|} @d w1=148 {move right and set |w|} @d x0=152 {move right by |x|} @d x1=153 {move right and set |x|} @d down1=157 {move down} @d y0=161 {move down by |y|} @d y1=162 {move down and set |y|} @d z0=166 {move down by |z|} @d z1=167 {move down and set |z|} @d fnt_num_0=171 {set current font to 0} @d fnt1=235 {set current font} @d xxx1=239 {extension to \.{DVI} primitives} @d xxx4=242 {potentially long extension to \.{DVI} primitives} @d fnt_def1=243 {define the meaning of a font number} @d pre=247 {preamble} @d post=248 {postamble beginning} @d improper_DVI_for_VF==139,140,243,244,245,246,247,248,249,250,251,252, 253,254,255 @ The character packets are followed by a trivial postamble, consisting of one or more bytes all equal to |post| (248). The total number of bytes in the file should be a multiple of~4. ----------------------------------------------------------------------- %%% Further information about the TeXhax Digest, the TeX %%% Users Group, and the latest software versions is available %%% in every tenth issue of the TeXhax Digest. %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% %%% BITNET: send a one-line mail message to LISTSERV@xxx %%% SUBSCRIBE TEX-L % to subscribe %%% or UNSUBSCRIBE TEX-L %%% %%% Internet: send a similar one line mail message to %%% TeXhax-request@cs.washington.edu %%% JANET users may choose to use %%% texhax-request@uk.ac.nsf %%% All submissions to: TeXhax@cs.washington.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% JUNE.CS.WASHINGTON.EDU TeXhax/TeXhaxyy.nn %%% yy = last two digits of current year %%% nn = issue number %%% %%%\bye %%% End of TeXhax Digest ************************** -------