TeXhax Digest Tuesday, August 16, 1988 Volume 88 : Issue 73 Moderator: Malcolm Brown Today's Topics: TeXhax Digest V88 #70 Wide Labels and BibTeX METAFONT answers \halign and \obeyspaces gftopk.c a) LW II NTX modes b) two column LaTeX Token-by-token processing of macro arguments Re: TeXhax Digest V88 #70 Question about math in 'Huge' size "multi-hyphen patch" Need of a TeX previewer and driver Help with pk files on vms Putting a QED box at the end of a Proof Page-breaks in LaTeX eqnarray environments. software for multiple change files TP4 TeX VMS WEAVE The best way to do pictures in TeX compiling C TeX with Gcc version 1.21 ---------------------------------------------------------------------- Date: Sat, 6 Aug 88 15:14:25 PDT From: mackay@june.cs.washington.edu (Pierre MacKay) Subject: TeXhax Digest V88 #70 There was a bug in the mode_specials sent out both through TeXhax and in the Unix TeX distribution U_Wash.mf file. It prevents the use of smode, because it assumes that mode is always an integer. Fortunately, the fix is easy: Just substitute this revised section at the end of the U_Wash.mf file or whatever mode_def file you use. It includes the Xerox world stuff as well. % Macros to add mode information specials to fonts. def mode_special(suffix $) = string s,d; s:=str$; d:=decimal scantokens s; special s&":="&d&";" enddef; def font_mode_specials = p_p_i=pixels_per_inch/mag; if fontmaking > 0: begingroup; save d,s,p; save pixels_per_inch; string p; pixels_per_inch:=p_p_i; special jobname; mode_special(mag); if string mode: p:=mode; else: p:=substring(0,length(mode_name[mode])-1) of mode_name[mode]; fi special "mode:="&p&";"; mode_special(pixels_per_inch); mode_special(blacker); mode_special(fillin); mode_special(o_correction); endgroup; fi enddef; % Finally, here are macros for Xerox-world font info. % These can be useful even if you never use a Xerox printer. % For instance, crudetype uses the |coding_scheme| % and it is nice to have the font family on record. Some % of this goes into the TFM, rather than the GF file. def font_family expr s = % string s names the font family, e.g., "CMR" headerbyte 49: BCPL_string(s,20); special "identifier "&s enddef; def coding_scheme expr s = % string s names the scheme, e.g. "TEX TEXT" headerbyte 9: BCPL_string(s,40); special "codingscheme "&s enddef; def font_face_byte expr x = % integer x gives the family member number, headerbyte 72: x; % which should be between 0 and 255 special "fontfacebyte"; numspecial x enddef; def BCPL_string(expr s,n)= % string s becomes an n-byte BCPL string for l:=if length(s)>=n: n-1 else: length(s) fi: l for k:=1 upto l: , substring (k-1,k) of s endfor for k:=l+2 upto n: , 0 endfor endfor enddef; Xerox_world:=1; % users can say `if known Xerox_world:...fi' inner end; def bye= if fontmaking > 0: font_family font_identifier_; coding_scheme font_coding_scheme_; font_face_byte max(0,254-round 2designsize); font_mode_specials; fi end enddef; outer bye,end; ------------------------------ Date: Sat, 6 Aug 88 19:20 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: Wide Labels and BibTeX In a recent TeXhax, I pointed out an apparent problem in BibTeX's algorithm for choosing the largest label in a bibliography. Oren Patashnik convinced me that BibTeX was, in fact, correct, given that I was "fooling" it by a misuse of \etalchar. After more hacking, I've found a workaround of sorts. What it does is ensure that \etalchar really does expand to what BibTeX thought it would, at least withint \thebibliography. The resulting spacing may be too wide, but it should be pretty close if the spacing WITHOUT the hack was too narrow: @preamble{"\let\BIBITEM=\bibitem" # "\def\bibitem{\def\etalchar##1{}\let\bibitem\BIBITEM \bibitem}" } In the process of doing this, I did find a limitation in BibTeX (which Oren tells me will be fixed in the final version): BibTeX tries to keep the lines in the BBL file short (<79 characters or thereabouts). It can almost always do this by breaking at a space, which has no effect. But if you use @preamble's with no spaces, you can get a random break that won't work. That's why there's a space after \BIBITEM in the second line above - it gives BibTeX soemthing to grab onto. BibTeX may also do the wrong thing if comments appear in @preamble text. Avoid them for now. -- Jerry ------------------------------ Subject: METAFONT answers From: adk1%FSU.BITNET@CUNYVM.CUNY.EDU Date: Sun, 7-AUG-1988 22:23 TeXhax Digest Friday, August 5, 1988 Volume 88 : Issue 70 From: Subject: Metafont question ... I modified the existing local.mf file... and I put this into my own directory. I then used mf "\mode=localfont; mag=1; input cmr10" to create cmr10 at magstep 1... it didn't work. The above command originally produced a file CMR10.300GF for the ln03 and with the new local.mf it should (I think) have produced a new file CMR10.somethingelseGF, instead I got CMR10.300GF again. What am I doing wrong??? I should be getting a different size GF file, shouldn't I??? -------- You never told METAFONT to look at your LOCAL.MF file! Try using the command line mf "\input local; mode=localfont; mag=1; input cmr10;" This has the disadvantage that your output files will be called LOCAL.GF, LOCAL.TFM etc., but will do what you want. The "proper" way to solve your problem is to do as the METAFONT book says: run INIMF, input PLAIN, then input LOCAL, and then use the DUMP command to produce a new base file. This file can then be used by typing "&plain" at METAFONT's "**" prompt, or presumably by using the command line mf "&plain; mode=localfont; mag=1; input cmr10;" To avoid having to load the PLAIN.BAS file everytime some implementations allow you to create a version of METAFONT with your new base file preloaded. The details of how to do this depend on whose VAX/VMS port of METAFONT you are using, as do the details of command line syntax (that is why the METAFONT book always tells you what to type at it's "**" or "*" prompts even though we all input the file name on the command line in reality). ------------------------------ Date: 7 Aug 88 23:58 -0500 From: Michael Doob Subject: \halign and \obeyspaces In TeXhax v88/67 Gavin Burnage raises the following problem: < Date: Wed, 20 Jul 88 13:42 N < From: < Subject: Problems combining \tt, \obeyspaces, and \halign < < I'm trying to typeset `tables' which represent the menu screens in a user < interface display. Because the typewriter type font characters have < identical widths, I figured the easiest way to do this (experienced but < sensitive Wizards please brace yourselves) would be with the < \obeyspaces command: I can copy the menu display straight into the file < as it appears on screen. < < The macro below almost works. < < However, on the left hand side of the table, between the vertical bar and < the text, mysterious spaces are inserted. I don't know why they appear, < so naturally, I don't know how to get rid of them. Can anyone explain and < resolve this problem, or point me to the (thus far elusive) appropriate < TeXbook reference? < < $${\vbox{ < \tt < \obeyspaces < \frenchspacing < \offinterlineskip < \hrule height 1.5pt < \halign {&\vrule width1.5pt#& < \strut#\cr < height10pt&\omit&\cr < &{ MAIN MENU }&\cr < &{ }&\cr < &{ Lexicon: Application: Environment: }&\cr < &{ LIST SHOW SQL*PLUS }&\cr < &{ CREATE TABLE VMS }&\cr < &{ MODIFY UNLOAD }&\cr < &{ DROP LOAD INSTALL }&\cr < height10pt&\omit&\cr < \noalign{\hrule height 1.5pt} < } < } < } < $$ < < < Gavin Burnage < CELEX -- Centre for Lexical Information Reply: < University of Nijmegen GAVIN@HNYMPI52.BITNET < Wundtlaan 1 < 6525 XD NIJMEGEN < The Netherlands < < ------------------------------ < The source of the problem is the interaction of \halign and \obeyspaces. The spaces are caused by the template, which obeys the unwanted spaces before the \strut. The problem can be avoided by placing the template on one line, or by putting the & directly before the \strut. Michael ------------------------------ Date: Sun, 7 Aug 88 22:44:23 PDT From: mackay@june.cs.washington.edu (Pierre MacKay) Subject: gftopk.c The programs in the Unix TeX subdirectory ./tex82/METAFONT/CMFware, (formerly ./mf84/CMFware) are of particular importance while web2c change files for the MFware webs are being prepared. It is therefore important to note that Tom Rokicki has corrected a bug in gftopk.c which has shown up in processing fonts with zero-length rasters, such as the latex invisible fonts. The repair is in a single line. Here it is, with lots of context. *** /u4/mackay/gftopk.c Sat Aug 6 14:14:09 1988 --- /u4/mackay/Gftopk.c Sat Aug 6 14:18:05 1988 *************** *** 296,306 **** putptr = 0 ; rowptr = 2 ; repeatflag = 0 ; state = true ; buff = 0 ; ! while ( row [ rowptr ] == ( - 99998 ) ) incr ( rowptr ) ; while ( row [ rowptr ] != ( - 99998 ) ) { i = rowptr ; if ( ( row [ i ] != ( - 99999 ) ) && ( ( row [ i ] != extra ) || ( row [ i + 1 ] != width ) ) ) --- 296,306 ---- putptr = 0 ; rowptr = 2 ; repeatflag = 0 ; state = true ; buff = 0 ; ! while ( row [ rowptr ] == ( - 99999 ) ) incr ( rowptr ) ; while ( row [ rowptr ] != ( - 99998 ) ) { i = rowptr ; if ( ( row [ i ] != ( - 99999 ) ) && ( ( row [ i ] != extra ) || ( row [ i + 1 ] != width ) ) ) -------------------------------cut here---------------------------------- Email: mackay@june.cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Group TUG Site Coordinator for Lewis Hall, Mail Stop DW10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 ------------------------------ Date: Fri, 05 Aug 88 11:42:05 BST From: CMI011%IBM.SOUTHAMPTON.AC.UK@Forsythe.Stanford.EDU Subject: a) LW II NTX modes b) two column LaTeX A) Can anyone supply me, or point me at, suitable MF definitions for a Canon SX laser engine, such as wot is in the LaserWriter II NTX? DOes anyone have any feelings on whether I should rebuilt all the fonts I have been using on an old LaserWriter? B) I have been trying to set a book in two column mode with LaTeX (dont ask why, I think I just decided not to after all). Anyway, I thought in my innocence that a figure or table which spanned two columns (asked for with figure* or table*) would coexist with two column text. It doesn't - the smallest table occupies a page by itself. Is this a feature or a bug? (and yes I have spent some hours in the book looking for an answer!) Either way, can anyone suggest a workaround? It really is rather silly to have really quite short (but wide) tables occupying a whole lonely page. All in all, that twocolumn mode is what we used to call a 'bummer'... (sorry Dr L, but the rest is wunnerful) sebastian rahtz, computer science, southampton ------------------------------ Date: Mon, 8 Aug 88 08:57 PST From: "Jim Seidman" Subject: Token-by-token processing of macro arguments I've been trying (without much success) to generate a TeX macro which will automatically typeset chemical formulas for me. For example, I could just say "\chemical{(CH3)3(CH2)12MgBr}" and all the digits would be automatically subscripted. At first I thought I could do something like this: \def\chemical#1{\chemchar{\aftergroup#1}} \def\chemchar#1#2{\appropriatelytypeset#2\chemical#1} \def\appropriatelytypeset#1{%Code to figure out if the character is a number, %and typeset it accordingly. Not only is this probably a terribly inefficient way of doing this, but it doesn't work either, nor does any combination of \expandafter's, \edef's, etc. seem to help. I know that if I want to do something like place a "\\" between each two characters I can just do list processing as described in the TeXbook, but I'm hoping there's a more elegant solution to getting a character at a time. Any suggestions? ------------------------------ Date: Mon, 08 Aug 88 09:14:37 PLT From: Dean Guenther Subject: Re: TeXhax Digest V88 #70 > From: "Jim Seidman, Reanimator-in-training" > Subject: Question concerning Hershey fonts > (Yes, I realize part 1 was actually 2 questions... so sue me.) Does > anybody know of a program to covert Hersey fonts into METAFONT input? If > not, does anybody know of a program to make TFM files for Hersey fonts, > or even an algorithm to do so? Scott Guthery, 512-258-0785 has the Hershey fonts with TFMs for a nominal fee. $20-$30 I think. Dean Guenther TeX IBM VM/CMS Site Coordinator Washington State University Pullman, Wa. 99164-1220 phone: 509-335-0411 BITnet: GUENTHER@WSUVM1 ------------------------------ Date: Mon, 8 Aug 88 09:22:26 PDT From: chase#lila%c.mfenet@NMFECC.ARPA Subject: Question about math in 'Huge' size I see the sizes are set in lfonts.tex. Why is it for 25 pt that When math is done in size "Huge", the integral limits are out of proportion. I believe poor choices are made in lfonts.tex. Shouldn't they be changed? ------------------------------ Date: Mon, 8 Aug 88 12:07:59 PDT From: mackay@june.cs.washington.edu (Pierre MacKay) Subject: "multi-hyphen patch" The multi-hyphen patch sent over by Antti Louko came with some character damage cause by trans-Atlantic travel, but I think I have it in shape. Although it passes trip, and can masquerade as TeX, it is not fully interchangeable with TeX (input files for this version would not run through TeX) and a new name is required. Ftex or Finntex would in some ways be appropriate, but what Antti Louko has done is more general than just to provide a Finnish TeX. How about mhtex (mhinitex mhvirtex mhtex.pool)? Scarcely pronounceable even in Irish, but fairly informative. I will add to the received patch the lines that will rename the program and the pool file. There was one minor adjustment found in the multihyph patch that really belongs in the base ctex.ch file. X_make_name_string ought to be in pascal verticals---|X_make_name_string| I haven't really tested mhtex yet. If anyone has a multilingual problem that could use it, pick it up by ftp from our pub directory. As soon as I am sure that all obvious bugs are gone, I will send the corrected file back for the MULTIHYPH.TXH file on SCORE. Email: mackay@june.cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Group TUG Site Coordinator for Lewis Hall, Mail Stop DW10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 ------------------------------ Date: Tue, 9 Aug 88 14:07 N From: Subject: Need of a TeX previewer and driver Hi from Crete. I am in a need of TeX previewer for Vax/Vms that uses gf font files. (for Vt125 Regis,Vt240's Tektronic modes mainly) Does anyone out there know something about it? Thanks for your time. I am also in a need of TeX driver for a HP7475 pen plotter. Also I search for a TeX driver for an LA100 or Epson printer. Thanks for your time and help. p.s.I am speaking for Vax/Vms. ------------------------------ Date: 9 Aug 88 11:07 -0600 From: Jim Walker Subject: Help with pk files on vms Can somebody PLEASE help me obtain/generate pk font files. I would like to use Ed Bell's latest version of dvi2ln3, which means that I have to obtain or generate the pk format files. I have the ams TeX distribution tape, so I have the gf format files. I think I tangled GFTOPK successfully (no .ch file), but GFTOPK.PAS file wouldn't compile because of undeclared identifiers. Can anybody help me please; i.e. tell me what I'm doing wrong, provide me with GFTOPK.PAS, give me a .com file to generate all the pk files, anything! ------------------------------ From: BICKIS%SASK.USask.CA@Forsythe.Stanford.EDU Date: Tue, 9 Aug 88 16:38 CST Subject: Putting a QED box at the end of a Proof Joachim Schrod's solution (11 June) to putting a QED box at the end of a proof is very comprehensive, but it may fail in one situation: If the proof ends with a displayed equation. In this case it may happen that the proof ends at the bottom of a page, and the QED symbol appears at the top of the next page. Suppressing a pagebreak doesn't work as part of the \QED macro, since TeX considers a pagebreak penalty to be the * minimum * of all penalties at that point. Moreover, an \unskip will not remove glue in the main vertical list. A way around this is to explicitly set \postdisplaypenalty=10000 before the displayed equation that ends the proof. However, this cannot be done inside the \QED macro itself, since by the time it is invoked, the current value of \postdisplaypenalty has already been placed in the vbox. This solution appears to work acceptably, except that in some cases it would look nicer if the QED box appeared on the same line as the displayed equation. This can be achieved by preceding the \QED macro with a negative \vspkip of the appropriate dimension. In plain TeX, one could also pretend that the the QED box is an equation number, using it as the argument of \eqno. This latter tactic will not work in LaTeX however. I see of no way that such tactics can be automated as part of a \QED macro itself. Mik Bickis Dept. of Mathematics University of Saskatchewan BICKIS@SASK.NETNORTH ------------------------------ From: BICKIS%SASK.USask.CA@Forsythe.Stanford.EDU Date: Tue, 9 Aug 88 16:56 CST Subject: Page-breaks in LaTeX eqnarray environments. I notice that inside an eqnarray environment LaTeX ignores any explicit commands about pagebreaks, either in its own dialect (\pagebreak or \nopagebreak) or in terms of TeX \penalty's. Does anyone know if this is a "known bug" or a "design feature"? Although LaTex will break long eqnarray's across pages, it does not always put the break in the best place semantically. I have not been able to figure out how LaTeX decides on such breaks, so I am not able to override its choice. Any suggestions would be appreciated. Mik Bickis Dept. of Mathematics University of Saskatchewan BICKIS@SASK.NETNORTH ------------------------------ Date: Tue, 9 Aug 88 15:40:55 PDT From: Jeff Copeland Subject: software for multiple change files Where can I obtain a copy of one of the change file merge programs that have been discussed in TUGboat in the past year? (KNIT and TWIST as described by Appelt and Horn in vol 7 #1; TIE, discussed by Guntermann and R\"ulling in vol 7 #3; or WEBMERGE as described by Sewell in vol 8, #2.) Unfortunately, I am unable to FTP. However, if one of these is on the current Unix distribution, we are about due for an update anyway, and will get it then. Jeffrey Copeland ...!uunet!ism780c!jeff ------------------------------ Date: Wed, 10 Aug 88 17:24:31 GMT From: WSULIVAN%IRLEARN.BITNET@Forsythe.Stanford.EDU Subject: TP4 TeX I am currently working on a Turbo Pascal 4.0 version of TeX for IBM PC's and compatibles, which I shall make freely available when it is in reasonable shape. At the moment a rather strict implementation is running and giving what I believe to be pretty good trip.log and trip.typ. A fair bit of work involving IO and checking remains, as well as optimization. Is there anyone interested in helping? Please do not contact me unless you are seriously interested in helping and have a fair knowledge of WEB, TeX and TP4. The main problem for a practical version is memory limitation. I should like to include the following modifications which would improve utilization of the bare 640K that the designers decided upon. I should appreciate advice on whether there are technical objections to any of these, and whether the inclusion of any would make the program no longer TeX. 1. Is dynamic determination of mem_top and mem_max O.K.? 2. It would be convenient to store the information now in the array of font arrays in specialized records in font_info immediately before the TFM data. An array of pointers would indicate the location of the font records and data. 3. For the auxiliary trie arrays used when iniTeX computes new patterns I should like to use space in the mem array between lo_mem_max and hi_mem_min. I have a hunch that the mem array is not needed while new patterns are being computed, but could new nodes be generated at this time? 4. I should like to use nodes from mem as control-block-buffers for the 16 read and 16 write files. For many applications the definition of these files as global variables results in wasted space. Is there anything wrong with using a node size of 65 for the cb-buffer? 5. For virTex (not iniTeX) it would be convenient to be able to use mem to store new font data when the font_info array is full. Here the node size would be about 350. One could select the size of font_info so that a mem_max of about 64k would be possible for a 640K PC with no resident utilities. For programs with lots of fonts, space for fonts could be taken from mem. One would include a few extra words in the node in case new font parameters were to be defined. I should be grateful for comments on these points. Wayne Sullivan ------------------------------ Date: Wed, 10 Aug 88 19:45:45 BST From: David Barfoot Subject: VMS WEAVE There is a bug in the VMS changes to WEAVE 2.8 which causes mishandling of the `::' type cast operator. A glance at module 27 of the VMS TeX changes reveals anomalous gaps between the colons, and, more seriously, accumulating anomalous indentations (which become considerable in so long a module). The following additions to WEAVE.CH appear to solve the problem (the numbers after @x are module numbers): ----------------------------------------------------------------------- @x [15] @d carriage_return=@'15 {ASCII code used at end of line} @y @d carriage_return=@'15 {ASCII code used at end of line} @d type_cast=@'27 {equivalent to `::'} @z @x [97] ":": if buffer[loc]="=" then compress(left_arrow); @y ":": if buffer[loc]="=" then compress(left_arrow) else if buffer[loc]=":" then compress(type_cast); @z @x [186] ":": sc1(":")(colon); @y ":": sc1(":")(colon); type_cast: sc2(":")(":")(math); @z I can mail the complete change file to anyone who wishes it. | David Barfoot | Phone: 0223 334709 | | University of Cambridge | Telex: via 81240 CAMSPL G | | Computer Laboratory | Fax: via 0223 334748 | | New Museums Site | | | Pembroke St | BITNET: DTB10%PHX.CAM.AC.UK | | Cambridge CB2 3QG | ARPANET: DTB10%PHX.CAM.AC.UK@CUNYVM.CUNY.EDU | | United Kingdom | | ------------------------------ Date: Thu, 11 Aug 88 10:56:14 CDT From: William LeFebvre Subject: The best way to do pictures in TeX I was just talking to one of my fellow grad students, and came up with what I think would be the best way to do graphics/pictures in TeX. This solution would require no \special support by the DVI translator, and it would even be previewable with a conventional previewer. And unlike PicTeX, it probably wouldn't require a gargantuan sized TeX image. I wanted to bounce this off of the TeX community to see what people think.... The solution? Use MetaFont, of course. Draw your graph, flowchart, circles, arrows, etc., in MetaFont. I have actually done something along these lines already: let MF produce it's largest sized gf file (2602 dpi) and convert that bitmap into an imPress bitmap (I had to write a program to do this step), then print it. You get a huge blowup of the bitmap (2602/300) but it looks great. Unfortunately, that still requires some \special to include a "native bitmap". So here's an even better solution: have MF produce an entire font for the picture by tiling it into small chunks. Then to print it in a TeX file, one only needs to switch to that font and print the characters in their appropriate places. Poof! No \special support needed, because it's all done in fonts. This still requires some fancy footwork, because there is an upper limit on the size of a character that MF can produce. I was thinking that you could set MF's working resolution very high (like, say 2600 dpi) to get a large work area, and then use the actual resolution of the device only when tiling. CAre would have to be taken to make sure that the image was still portable to any resolution device (this would introduce some more problems if the device was a very high resolution). But there are some great advantages: the document would be reproducible on any machine running both TeX and MF and on (most) any printer. Metafont is as maleable as TeX, which means that one could emulate one's favorite picture drawing environment (such as "pic") on top of it. That way, your metafont file would look more like pic than metafont, but for graphics drawing it would be all that you need. Only three problems need to be solved: 1) make metafont tile an image, producing many characters for one image 2) positioning text correctly in the image (I haev some ideas for this, too) 3) deal with widely differing printer resolutions gracefully. What'cha think? I wish I had the time to do it right now! William LeFebvre Department of Computer Science Rice University ------------------------------ Date: Thu, 11 Aug 88 17:56:18 BST From: CMI011%IBM.SOUTHAMPTON.AC.UK@Forsythe.Stanford.EDU Has anyone succeeded in compiling TeX with Gnu CC? I just tried, out of curiosity, and tho it compiles I get a crash on reading in the 'hyphen.tex', apparently because Gnu C can't allocate the memory for the string pool. I haven't pursued it because I cam not competent to do so, but does anyone have any thoughts on the matter? My web2c is 2.17, my Gnu is 1.21 (I think) and I'm on a Sun sebastian rahtz computer science, southampton ------------------------------ Date: Thu, 11 Aug 88 11:22:22 -0700 From: Tim Morgan Subject: compiling C TeX with Gcc version 1.21 I was first able to compile C TeX with Gcc version 1.21 by defining schar to be "int" in site.h. With gcc 1.24, I was able to compile the gargantuan version of C TeX without making this change (i.e., schar was typed "signed char"), and it passed the trip test even when compiled with optimization turned on. The current distribution includes support for TeX, all the TeXware programs, Metafont, and BibTeX 0.99c. A version of gftype in C is provided for the trap test. There are people actively working on the MFware programs. Tim Morgan UC Irvine ICS Dept. ------------------------------ %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% BITNET: send a one-line mail message to LISTSERV@TAMVM1.BITNET: %%% SUBSCRIBE TEX-L % to subscribe %%% %%% All others: send mail to %%% texhax-request@score.stanford.edu %%% please send a valid arpanet address!! %%% %%% %%% All submissions to: texhax@score.stanford.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% [SCORE.STANFORD.EDU]TEXHAXnn.yy %%% nn = issue number %%% yy = last two digits of current year %%%\bye %%% ------------------------------ End of TeXhax Digest ************************** -------