From "TeX-Euro Distribution List for European TeX Users" Wed Dec 31 17:00:00 1969 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Fri 20 Jul 90 15:44:27-MDT Received: from VM.BYU.EDU by CC.UTAH.EDU; Fri, 20 Jul 90 15:24 MDT Received: by BYUVM (Mailer R2.05) id 1539; Fri, 20 Jul 90 09:47:34 MDT Date: Mon, 16 Jul 90 16:07:54 CET From: Rainer Schoepf Subject: lplain and splain for TeX 3 Sender: TeX-Euro Distribution List for European TeX Users To: "Nelson H.F. Beebe" Reply-to: TeX-Euro Distribution List for European TeX Users Message-id: <60A3231C0EBF4001B8@CC.UTAH.EDU> X-To: texhax@cs.washington.edu, German Tex Users Communication List , infotex@ASTON.AC.UK, tex-euro@DHDURZ1 X-Envelope-to: Beebe@SCIENCE.UTAH.EDU I have just installed new versions of the lplain.tex and splain.tex files that work with TeX version 3.0 as well as with version 2.x. These files will eventually become part of the standard distribution. Up to this date they can be found in the LTOOLS FILELIST on LISTSERV at DHDURZ1 under the names of LPLAIN3 TEX and SPLAIN3 TEX. To order them send a command of the form GET LPLAIN3 TEX LTOOLS to LISTSERV@DHDURZ1.BITNET. Note: if your mail goes via one of these character mangling gateways you should not try it. This applies especially to those in the UK who are connected via JANET. I will make sure that these files will be installed at the Aston archive server. Rainer Sch\"opf From "Don Hosek " Thu Jun 28 01:10:54 1990 Flags: 000000000001 Return-Path: Received: from ARGON.CLAREMONT.EDU by science.utah.edu with TCP; Thu 28 Jun 90 00:59:31-MDT Date: Wed, 27 Jun 1990 23:53 PDT From: Don Hosek Subject: Thoughts on a TUG archive To: tex-archive@science.utah.edu Message-id: <8D91248D97E0600FA3@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: IN%"tex-archive@science.utah.edu" Here are my thoughts on the topic of TeX archives: 1. The purpose of a TeX archive There are two central needs for such a service: (a) the distribution of the latest version of the core TeX system (this is what labrea is doing right now) and (b) a central source for the coordination of the great mass of public domain software currently available. Currently, the archive at labrea meets point a (I have a few complaints about the organization of the archive, but according to Joe Weening, the organization is set up as it is at DEK's request so...). Where TUG's coordination is sorely needed is under point b. At present there are at least half a dozen archives containing various subsets of what's available for TeX. Aston comes closer than anyone else to being complete although they still have a few gaps here and there. 2. Management of a TeX archive 2.1 Personnel One of the reasons that the Aston archive is as successful as it is is the fact that the task of maintaining the archive does not fall on a single person. Speaking from the perspective of someone who has attempted to single-handedly get a reasonable archive going, I can safely say that no person can effectively do this without devoting at least 40 hours a week to the effort and seeing a therapist. The organizational model of the Aston archive, with several volunteers each maintaining a section of the archive is a good approach. Each person would work on some section that they feel comfortable with and have a task small enough to manage in spare time. 2.2 Accessibility The archive needs to be directly accessible from (at least) the Internet and Bitnet. In an ideal world, the following means of access would be provided: 1. Anonymous FTP 2. Mail server capability 3. Bitnet file serving (cf. Listserv, netserv, vmsserv...) 4. DECnet/SPAN access 5. Anonymous UUCP 6. Dial-in BBS access I have attempted to list these in order of decreasing importance (individuals without internet access might dispute the relative rankings of 1 & 2, but my experience has been that the two are almost always available together anyway, at least for major archives). Binary transfer is in my experience most reliable with methods 1&6 (I have no experience with 4&5). Method 3 works only if the sending and receiving machine are of the same type and running the same network transfer software (e.g., a binary file cannot be transferred via bitnet from ymir, a VAX/VMS system running Jnet, to uicvm, a VM/CMS system running RSCS, or fnal, a VAX/VMS system running its own NJE protocol system. To deal with this problem, some encoding mechanism must be used. At present the most common techniques are uuencode, xxencode, and btoa. Each has its difficulties, but they are all fairly widespread. The people who design internet standards, in their infinite wisdom are designing a new format for binary encoding in text e-mail (this piece of intelligence courtesy of Ned Freed) which will not be any of the abovementioned formats. It is expected to be available on various platforms by summer's end. 2.3 Acquisitions This is one of the most difficult problems for archive management: new products come into public awareness through several channels including, but not limited to: - AmigaTeX BBS - Channel 1 BBS - Dante and its publications & e-mail groups - GUTenberg and its publications & e-mail groups - IVRITEX - NTG and its publications & e-mail groups - PCTeX BBS - RUSTeX-L - TeXhax - TeXline - TeXMaG - TUGboat (including conference presentations) - UKTeX - Usenet newsgroups comp.fonts, comp.laser-printers, comp.lang.postscript, comp.text, comp.text.tex A good comprehensive archive will have all of these channels monitored to check for new product releases. 2.4 Quality control Most packages need a bit more work to be in a decent enough shape to be redistributed: fonts should be checked to make sure there are no name conflicts (let's be nice to the poor souls running CMS) and are unique to the first 8 characters. Each file should be checked to guarantee that it has adequate internal documentation (cf. my article on portable MF guidelines in TUGboat 10#2) and that no corruption has occurred. Also, care should be taken to insure that there is no duplication of functionality in the archive (cf. subeqn.sty and subequations.sty both currently in the ymir archive (sigh)). Particularly in this area, we need to have a group officially sanctioned by TUG for handling this. In addition, the archive group needs to regularly contact the suppliers of items to the archive to check to see if there have been any changes to their contributions. 3 Some concrete suggestions Here are my proposals for dealing with this whole issue. - Some site on the internet should serve as the official TUG archive of TeX software. This system should be either a Unix machine or a VMS machine. Tops-20 and VM/CMS pose too many problems to be useful for this task. - This site should have guest accounts for all of the archive volunteers. Whether those volunteers directly have write access to the actual archive or the local director is responsible for the updates to the distribution is a debatable point. - The archive maintainers should, when adding a new item to the archive, announce it to the tex-archive list. Major items should also be announced in TeXhax, UKTeX and comp.text.tex (and the more specialized lists if applicable). -dh From "Don Hosek " Thu Jun 28 01:12:05 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU ([134.173.4.149]) by SCIENCE.UTAH.EDU with TCP; Thu 28 Jun 90 01:11:13-MDT Date: Thu, 28 Jun 1990 00:03 PDT From: Don Hosek Subject: Re: TeX archive mailing list---addresses which are humans: To: tex-archive@science.utah.edu Message-id: <8D92825AD940600FA3@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: IN%"tex-archive@science.utah.edu" Well, this list could have used some cleaning... I've noted the addresses below which are actually humans and should be added to the list. --fisica@39003.span --fisica@astrpd.infn.it This is one of the contacts for the Italian DECnet source. The latter address is more likely to get through from outside SPAN/HEPNET. --rmcs_tex@kirk.aston.ac.uk This is the address of Brian Hamilton Kelly and Christopher Neil Kempson, two of the maintainers for the Aston archive. Actually we should probably add the whole archive group. Those who should not be added (all others are servers, mailing lists or example addresses) --abbottp@aston.ac.uk You've already got Peter on your list. --AnnaB@11.DAS.NET Merely the contact person for DASnet --jonradel@bogey.princeton.edu This address no longer works. -dh From "Karl Berry " Thu Jun 28 16:50:51 1990 Flags: 000000000011 Return-Path: <@RELAY.CS.NET:karl@aten.umb.edu> Received: from RELAY.CS.NET by science.utah.edu with TCP; Thu 28 Jun 90 16:50:30-MDT Received: from relay2.cs.net by RELAY.CS.NET id ad00688; 28 Jun 90 18:12 EDT Received: from umb.edu by RELAY.CS.NET id ab27075; 28 Jun 90 18:07 EDT Received: by umb.umb.edu (5.51/5.17) id AA01156; Thu, 28 Jun 90 17:51:41 EDT Received: by aten.cs.umb.edu (3.2/5.17) id AA02585; Thu, 28 Jun 90 17:51:37 EDT Date: Thu, 28 Jun 90 17:51:37 EDT From: Karl Berry Message-Id: <9006282151.AA02585@aten.cs.umb.edu> To: tex-archive-request@SCIENCE.UTAH.EDU Subject: add me Please add me to the tex-archive list (even though I'm not an archive maintainer (yet)). karl@cs.umb.edu From "Nelson H. F. Beebe " Thu Jun 28 17:20:26 1990 Flags: 000000000001 Mail-From: BEEBE created at 28-Jun-90 17:10:57 Date: Thu 28 Jun 90 17:10:57-MDT From: "Nelson H. F. Beebe" Subject: TeX archives -- getting started To: tex-archive@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12601515295.19.BEEBE@SCIENCE.utah.edu> A few people responded with suggestions, additions, and changes to the tex-archive list, and Barbara Beeton supplied the current TeX implementors list, from which I've merged in vendors and site coordinators. This gives a current list of 51 people, which is larger than I expected. Henceforth, mail send to tex-archive@science.utah.edu will be broadcast to this list, and a copy will be made in a TOPS-20 mail file in aps:tex-archive.txt. Such a mail file is a simple ASCII text file that looks like a time-ordered concatenation of mail messages, with a single line between each one that contains some date/time information, and a byte count that the mailer uses to skip forward to the next message. There is no binary garbage that would inhibit looking at this file on another system. Don Hosek may have been the first one to send a lengthy posting ``Thoughts on a TUG archive''. One of the things that needs to be looked at first is getting the many archives into a consistent state. This is a VERY BIG job, and I don't expect it to have an easy solution. It may well be impossible without considerable software support to automate the job. Don Hosek observed that a large archive might draw material >From many sources, including other archives, and bulletin boards. If individuals at 50+ sites are doing this, then the situation is probably hopeless. It seems to me that we want to move toward some sort of tree-structured system, whereby several archive sites derive their holdings from one other system, and those systems in turn get theirs ... We don't have any single site with the human and machine resources to serve as the root of the tree, and TUG does not have the financial resources to fund such an activity, notwithstanding its great value to the TeX communit). Aston, ymir, Heidelberg, labrea, and sun.soe all have large collections, and additions from Don Knuth and the TUGboat editor have first appeared on score (succeeded by labrea in August 1989). Aston is largely inaccessible outside the U.K.; however, Don Hosek hopes to develop a shadow copy of Aston on ymir. Joachim Lammarsch transferred a complete copy of the labrea archive to Heidelberg in early June, but has been out of the country for a few weeks; the Heidelberg server does not yet permit anonymous ftp access, but that could change in the future as Internet connections become more widely available in Europe. Dean Guenther and Joachim Lammarsch have indicated that they plan to create a shadow copy of Heidelberg at Washington State University, in order to reduce the substantial volume of traffic across the Atlantic from North America to Heidelberg. By way of getting acquainted, it might be helpful if each reader posts a note to the list giving a summary of local TeX archive holdings, and where they were derived from. I'll start by telling you that the archives on science.utah.edu have been kept a mirror image (right down to time stamps) of score.stanford.edu until the latter was shutdown 10 months ago. Since then, I've updated local directories from labrea and sun.soe, plus added things like the AP-TeX font style files and MakeIndex (more on that in a subsequent posting). I've also maintained a set of files in the anonymous ftp directory named tex-for-xxx.* and tex-from-xxx.* which try to answer common questions I get phone calls and e-mail about. The 00news.txt file there describes recent additions, and the 00readme.txt file is a pointer into the file tree. aps:00readme.txt contains a description of the TOPS-20 file system. Files named index in the anonymous ftp login directory and in aps: give a one-line summary of major files and all subdirectories. To give you a flavor of the anonymous ftp activity on science.utah.edu. here is the top of a sorted file access list (TOPS-20 file control blocks have an access count field, and several time stamps, including last read): @file-aCCESS-COUNT (of files) /sort anon:*.*.* File Read Access Listing (Sorted by Reads/Day) 28-Jun-90 17:00:30 ------------------------------------------------------------------ File | Reads | Age | Reads/Day ------------------------------------------------------------------ 00README.TXT.56 1208 158 7.64 TEX-FOR-IBM-PC.TXT.13 287 62 4.62 00README.TXT.38 2692 627 4.29 00DIR.LST.1 8 3 2.66 INDEX..9 493 198 2.48 00PCDOS.TXT.1 2444 986 2.47 00README.TXT.39 660 276 2.39 TEXBOOK1.BIB.1 6 3 2.00 TEX-FOR-UNIX.TXT.3 398 201 1.98 INDEX..10 90 52 1.73 00README.TXT.41 358 213 1.68 00NEWS.TXT.20 24 15 1.60 INDEX..13 23 15 1.53 00README-CTRSCI.TXT.3 217 158 1.37 TEX-3P0.TXT.1 71 52 1.36 ... ------------------------------------------------------------------ The DVI driver access patterns look like: @file-aCCESS-COUNT (of files) /sort td:*.tar*,td:*.arc* File Read Access Listing (Sorted by Reads/Day) 28-Jun-90 17:03:20 ------------------------------------------------------------------ File | Reads | Age | Reads/Day ------------------------------------------------------------------ APS:DVIEXE.ARC.1 823 666 1.23 APS:DVI.TARZ-001.1 188 158 1.18 APS:DVIDOC.ARC.1 771 665 1.15 APS:DVI.TARZ-002.1 165 158 1.04 APS:DVI.TARZ-003.1 151 158 .95 APS:DVI.TARZ-004.1 148 158 .93 APS:DVI.TARZ-005.1 147 158 .93 APS:DVI.TARZ-010.1 146 158 .92 APS:DVI.TARZ-006.1 143 158 .90 APS:DVI.TARZ-008.1 143 158 .90 APS:DVI.TARZ-007.1 142 158 .89 APS:DVISRC.ARC.1 592 665 .89 APS:DVI.TARZ-009.1 140 158 .88 APS:PCMAKE.ARC.2 371 954 .38 APS:PDMAKE.ARC.1 210 665 .31 APS:XPORT.ARC.1 280 1189 .23 ------------------------------------------------------------------ Activity on these may pick up as people start trying out the tuglib server; a message to tuglib@science.utah.edu with the text "help" will get you started. Except for the whois command and the support subdirectory, everything accessible from tuglib can be fetched more easily via anonymous ftp. ------- From "Nelson H. F. Beebe " Thu Jun 28 17:23:40 1990 Flags: 000000000001 Mail-From: BEEBE created at 28-Jun-90 17:15:31 Date: Thu 28 Jun 90 17:15:31-MDT From: "Nelson H. F. Beebe" Subject: TeX archives -- MakeIndex status To: tex-archive@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12601516127.19.BEEBE@SCIENCE.utah.edu> As a start at informing one another what we have, here is an update on MakeIndex, the indexing package for TeX, LaTeX, and troff. Pehong Chen, the author of MakeIndex, has left Berkeley for the world of private computer consulting, and no longer has e-mail access. I've therefore taken MakeIndex under my wing, and recent changes applied all known bug fixes, and brought the code up to ANSI C, with complete ANSI-style function prototypes everywhere. According to the README file, >>... >> This current version is known to compile and run on UNIX (cc >> and gcc), VAX/VMS (VMS cc), TOPS-20 (kcc-20 and pcc-20), and >> IBM PC DOS (Microsoft C Version 5.0), Atari ST, Siemens >> BS2000 (CCD-2000), and IBM MVS/XA (IBM-C370). >>... [More systems are now actually covered; see below.] The current version is 2.9, and is available on science.utah.edu in the directory aps: in split compressed .tar files that preserve the directory structure, and also in .arc files that can be used to reconstruct each of the many directories. 8-bit binary files must transferred in tenex mode, NOT binary mode. Joachim Schrod in Darmstadt is looking at the code with a view to enhancing the sorting capabilities, so as to do a better job of handling accented words; no promises or commitments are implied. >From time to time the question comes up whether MakeIndex should be rewritten in Web. I'm inclined to say no, because (a) it works well as it stands, (b) C compilers are in fact available now for every machine that TeX runs on, and (c) no one is likely to have the time to write a Web version. You are all welcome to grab MakeIndex 2.9, either via ftp, or via e-mail through tuglib@science.utah.edu (a painful way, since you'll have to reconstruct it from pieces). It is quite possible that others have done independent work on MakeIndex, in which case a merger is called for. Please correspond with me directly (not to the whole list) if you have a version that purports to be newer. The LOG file from the src directory follows: Revision History for MakeIndex This is a reverse time-ordered history of changes to MakeIndex. ----------------------------------------------------------------- [12-Dec-1989] Version 2.9 released by Nelson H.F. Beebe (beebe@science.utah.edu) Testing carried out on: PC DOS Microsoft C 5.0, Turbo C 2.0, Lattice C 6.02 TOPS-20 KCC-20 and PCC-20 UNIX Sun OS 4.0.3 cc and gcc 1.36 VAX ULTRIX-32 cc VAX VMS VMS C 2.3 Added support for Turbo C 2.0 and Lattice C 6.02 on IBM PC DOS. Although compilation and linking were successful with Lattice C, the executable produced a 'Not enough core...abort' message at run time under the D, L, and H memory models. Replacing malloc(n) calls by halloc(1L,n) did not remove the problem; debugging statements (selected by defining DEBUG at compile time) showed that calls to malloc() and calloc() allocated less than 15KB before the abort. Curiously, a separate little test program that allocated 1000-byte blocks with malloc() or calloc() could allocate over 55KB in the small memory model, and over 500KB in the large models, before aborting. Thus, we conclude for now that Lattice C 6.02 is not usable for MakeIndex. Added ARGS macro to simplify function declarations in ANSI and pre-ANSI styles. Added missing definition of OS_XENIX in mkind.h. Moved declarations of static functions from mkind.h to relevant *.c files to remove compiler warnings about declared, but unused, objects. Removed a couple of unreachable break statements that raised compiler warnings. Use ANSI strchr/strrchr instead of K&R index/rindex; the former are #defined to the latter for systems that have only the old names. Fixed scan_arabic() in scanid.c to allow ARABIC_MAX digits, instead of one less than that, and fix condition on which the error message about too many Arabic digits is triggered. Repair widespread confusion between NUL (the character '\0'), and NULL (the pointer). NUL is a user-definable name, while NULL is defined by the implementation; on segmented memory machines, pointers and integers need not be equivalent, so it may hold that NULL != NUL. Previous versions of MakeIndex used NULL to mean both, and redefined NULL to be '\0'. In general, NULL must be typecast to a pointer of the appropriate type, since under ANSI C, it will usually be defined to be something like (void*)0 or (void*)0L. [11/11/1989] Version 2.8 released by Pehong Chen (chen@renoir.berkeley.edu). (1) ARABic_MAX changed from 4 to 5, duo to Sebastian Rahtz's (spqr%ecs.southampton.ac.uk@NSFnet-Relay.AC.UK) report on TeXhax #87 (9/17/1989). (2) A nasty sorting bug was fixed due to a report from Martha Wershofen-Mersbach (GRZTEX%dbngmd21.bitnet@NET.BIO.NET) of the German National Research Center For Computer Science (GMD). (3) Siemens BS2000 ported done by Andreas Brosig of the German National Research Center For Computer Science (GMD). (4) German word ordering, the "-g" option contributed by Brosig. (5) Miscellaneous bug fixes by Brosig: A. Blank compression routine ("-c") fixed. B. The "-p" option now works for MSDOS and MVS. Have to logfile in binary mode for OS_PCDOS and add OS_MVSXA to an existing #if because fseek(...) does not work under MVS. C. If an indexentry contains more than 2 IDX_LEVEL '!' or more than 3 IDX_ACTUAL '@', MakeIndex would ignore this entry and writes "Extra ... at position ..." to the transcript file. This is now fixed. D. If an indexentry is too long (> STRING_MAX), MakeIndex would ignore it and write a message to the transcript file. This is now fixed. E. For MSDOS(OS_PCDOS) LONG_MAX is set back to 144 and STRING_MAX to 64. Otherwise a core error will occur in the case of a big IDX-file. ----------------------------------------------------------------- [10/1/1988] Version 2.7 released by Pehong Chen (chen@orc.olivetti.com). (1) Fixed a string printing bug reported by anita@vax1.acs.udel.edu through Leslie Lamport. The string should be an argument to the printf format, instead of the format itself. ----------------------------------------------------------------- [7/14/1988] Version 2.6 released by Pehong Chen (chen@orc.olivetti.com). (1) The documentation for UNIX man page makeindex.l went through revision by Rick P. C. Rodgers of UCSF (rodgers@cca.ucsf.edu). Rick also provided a sample style file for MakeIndex to work with troff (see the man page for details). (2) String length (LONG_MAX) was increased from 144 to 1024. (3) Fixed a letter heading bug. It used to put the heading below the first index entry. (4) Added a new feature, the terminating delimiter for page list. This delim_t string is null by default. It can be redefined as a period if one would like a page list to be terminated by a period, for example. This delimeter has no effect on an index entry which does not have any page number associated with it. ----------------------------------------------------------------- [4/14/1988] Version 2.5 released by Pehong Chen (phc@berkeley.edu), with VAX/VMS extensions by Charles Karney Plasma Physics Laboratory Phone: +1 609 243 2607 Princeton University MFEnet: Karney@PPC.MFEnet PO Box 451 ARPAnet: Karney%PPC.MFEnet@NMFECC.ARPA Princeton, NJ 08543-0451 Bitnet: Karney%PPC.MFEnet@ANLVMS.Bitnet The file VMSmake.com for VAX/VMS users who don't have make. This version also includes a fix under XENIX by Baron O.A. Grey UCLA Computer Science Department baron@CS.UCLA.EDU ...!(ucbvax,ihnp4)!ucla-cs!baron ----------------------------------------------------------------- [3/20/1988] Version 2.4 released by Pehong Chen (phc@berkeley.edu), the ``official'' version of MakeIndex that enters public domain. * length() (originally defined in mkind.c) is replaced by the standard function strlen(), which in some C implementations is, or can be, expanded to in-line efficient hardware instructions (e.g. Microsoft C and VAX Unix); I have not yet done this. ----------------------------------------------------------------- [20-Jan-88] Portable version 2.3 released by Nelson H.F. Beebe (BEEBE@SCIENCE.UTAH.EDU). I spent 3 days implementing MakeIndex on Sun OS3.3 Unix (cc and gcc), TOPS-20 (KCC-20 and PCC-20 compilers), PC DOS (Microsoft C Version 5.0), and VAX VMS. This was at times a frustrating experience, because the effort revealed a great many portability problems in the original code (from VAX Unix, I think), plus some genuine bugs in MakeIndex, plus a bug in each of two compilers (KCC-20 and PCC-20)! The changes for this version over 2.2 are exclusively bug fixes and portability enhancements. Thanks to the original authors' careful design, no functionality changes are likely to be necessary. Besides getting the code working correctly on 4 systems and 6 compilers, I have made several passes over the code to reduce the lint complaints to a minimum, and remove all of the warnings produced by the IBM PC Microsoft C Version 5.0 compiler, which is the only one of the above systems which completely implements October 1986 draft ANSI C; the ANSI function prototype checking caught numerous problems. With these changes, I believe that we now have a version of MakeIndex that satisfies the important goal of TeX -- the same input will produce identical output results on all machines, whether they be micros, minis, mainframes, or supercomputers. This is true at least for the 6 systems for which testing has been possible at Utah. Here is a summary of bug corrections and other changes: * Several routines fell off the end without returning a value, when the caller expected it; this was particularly hard to trace (2 days of effort--the code only failed on PCC-20, and work correctly with the other 4). * Equivalence of *short and *int was incorrectly assumed in one routine; this made the code dependent on the byte storage order (it works on the little-Endian VAX architecture, but will fail on big-Endian architectures (IBM et al)). * Equivalence of *int and *char was incorrectly assumed in the call to qsort(); the only one of the 6 compilers which uses a different format for *char values is KCC-20, and that feature caught this bug (the compiler didn't find it for me, but when the sort failed, I tracked it down). * Routines which do not return a value are now explicitly typed `void' instead of nothing or `int', and mkind.h has both K&R old-style and new ANSI style function declarations for all routines; the choice is made on the basis of the compiler and operating-system switch selections. * A single (incorrect) use of backslash-dot (\.) escape sequence in scanid.h has been reduced to dot (.). * exit() was called without a valid argument in mkind.h. * In several places, code of the form char c; while ((c = getchar()) != EOF) existed; this is incorrect and will fail on many machines when the EOF (== -1) value returned by getchar() is truncated to a byte value for storage in c, then extended to an integer again and compared with EOF. The correct approach is to use "int c;" instead of "char c;". Type declarations have been changed from "short" or "int" to "char" or vice versa in several places in order to achieve consistency, and explicit typecasts are used when data types are intentionally changed by assignment or argument association. * mkind.h now has a SHORTNAMES section to define short names for the 45 long ones which clash when reduced to 6 characters (although KCC-20 and PCC-20 both handle long names, they produce assembly code output, and the assembler limits names to 6 case-insensitive chars). * File names have been reduced to 6 characters, allowing the source to be ported to all of the above systems without tedious file renaming. The TOPS-20 LINK program also runs under TOPS-10, and because TOPS-10 has a 6-character file name limit, LINK-20 does too, sigh... The executable is called makeindex on all systems except PC DOS, where the 8-character limit reduces it to makeindx. Similarly, filenames with special characters (ind+ and ind-) have been renamed to portable names. * Reference to sys/file.h has been eliminated; it was only needed for the symbol R_OK passed to access(). sys/file.h is missing from most non-Unix C implementations, while the value of R_OK (4) for access() is consistent for all but PCC-20, where only F_OK (0) is implemented. * Makefiles have been produced for each of the above systems (I have the same version of a public-domain make running on all of them). * A public version of qsort.c has been included in MakeIndex for two reasons. First, some non-Unix C implementations lack it. Second, quicksort is not a `stable' sorting algorithm; that is, the order of items with equal keys is not necessarily identical between the input and the output. Different implementations of the sort algorithm in the host qsort() can therefore give different ordering in such cases (PCC-20 and KCC-20 differed, which is how I caught this). qsort is #define'd to qqsort for all systems, in order to avoid possible clashes with the standard library version (this happens with IBM PC Microsoft C and with VAX VMS). * Version 2.2 did not come with any documents containing index entries to test MakeIndex with. I have taken the liberty of preparing an index for Leslie Lamport's article, ../doc/makeindex.tex for a test version, ../test/test.tex. This can be used both to test MakeIndex, as well as to illustrate the production of an index for new users (I'm using it in a class that I am teaching on LaTeX). test.tex uses the showidx document style option to get the index entries displayed as marginal notes, and the index entries in test.tex have been carefully formatted to always begin a line; that way, they can be easily extracted (e.g. by grep), so that one can see the original entries, the LaTeX output .idx file, and the MakeIndex output .ind file. * The bug fix for PCC-20 has been posted to the TOPS-20 bulletin board; PCC-20 was developed at CS.UTAH.EDU, but we (SCIENCE.UTAH.EDU) now have their DEC-20, so I guess we have become the default PCC bug-fix site. The bug in KCC-20's preprocessor has been reported to the KCC developers at SRI-NIC.ARPA but cannot be easily fixed until the draft ANSI C support in KCC-20 is complete; in the meantime, conditional compilation is used to provide alternate code which compiles correctly. ----------------------------------------------------------------- [29-May-87] Version 2.2 (5/29/1987) released by Pehong Chen (phc@berkeley.edu) ------- From "Nelson H. F. Beebe " Thu Jun 28 17:37:39 1990 Flags: 000000000001 Mail-From: BEEBE created at 28-Jun-90 17:34:12 Date: Thu 28 Jun 90 17:34:12-MDT From: "Nelson H. F. Beebe" Subject: TeX archives -- BibTeX style file status To: tex-archive@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12601519527.19.BEEBE@SCIENCE.utah.edu> While Oren Patashnik is finishing up BibTeX 1.0, perhaps we can get a notion of what has been done with the latest version, 0.99c, in the way of style files. I'm guessing that sun.soe.clarkson.edu probably has the latest stuff, since it took over the LaTeX style file repository from Rochester. Here are the current contents of ~ftp/pub/bibtex-style: -rw-r--r-- 1 325 788 May 2 1989 Description -rw-r--r-- 1 325 395 Jun 28 02:01 Index lrwxrwxrwx 1 root 21 Jun 26 1989 Readme -> ../latex-style/Readme -rw-r--r-- 1 325 22648 Apr 15 1988 aaai-named.bst -rw-r--r-- 1 325 19367 Feb 2 1988 acm.bst -rw-r--r-- 1 325 21794 Feb 2 1988 apalike.bst -rw-r--r-- 1 325 7402 Jan 4 1989 cpp.el -rw-r--r-- 1 325 16932 Feb 2 1988 ieeetr.bst -rw-r--r-- 1 325 1002 Feb 19 1988 makebst.sh -rw-r--r-- 1 325 22924 Mar 14 1989 named.bst -rw-r--r-- 1 325 99256 Jan 4 1989 physics.btx -rw-r--r-- 1 325 17956 Feb 2 1988 siam.bst and ~ftp/pub/bibtex has: -rw-r--r-- 1 325 20285 Dec 5 1989 abbrv.bst -rw-r--r-- 1 325 23863 Dec 5 1989 alpha.bst -rw-r--r-- 1 325 73045 Dec 5 1989 btxbst.doc -rw-r--r-- 1 325 20569 Dec 5 1989 plain.bst -rw-r--r-- 1 325 17986 Dec 5 1989 unsrt.bst At Utah, I've recently prepared two variants of plain and alpha, available in ps:is-*.bst; they include ISBN numbers in the output. [Is anyone aware of software that can check ISBN numbers for legality? According to a Comm. ACM article several months ago, they do carry a checksum.] The question of a named style (apalike in 0.98, I think) comes up regularly from people in the social sciences and humanities; the author of apalike, Stephen Gildea, has never updated it for 0.99c, and neither has Oren Patashnik. Does someone out there have a neat little bundle of other styles? ------- From "Nelson H. F. Beebe " Thu Jun 28 19:28:10 1990 Flags: 000000000001 Mail-From: BEEBE created at 28-Jun-90 19:25:26 Date: Thu 28 Jun 90 19:25:25-MDT From: "Nelson H. F. Beebe" Subject: TeX archives -- self-identifying files To: tex-archive@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12601539775.35.BEEBE@SCIENCE.utah.edu> In discussions that lasted late into the night in Heidelberg last month, we dealt with the problem of creating files that are self-identifying. The justification was that there was a need to record inside the file itself its name, ownership, version, time stamp, etc. The scheme we arrived at was to embed a BibTeX-like entry in comments in the start of the file. BibTeX format has the advantage of being relatively easy to parse, and importantly, is extensible. I've been trying this out on some bibliographies that I've been working on recently, and here are two examples: >From texbook1.ltx: %% @texfile{ %% author = "Nelson H. F. Beebe ", %% version = "1.04", %% date = "28 Jun 1990", %% filename = "texbook1.ltx", %% address = "Center for Scientific Computing %% and Department of Mathematics %% South Physics Building %% University of Utah %% Salt Lake City, UT 84112 %% USA %% Tel: (801) 581-5254", %% checksum = "61 200 1922", %% email = "beebe@science.utah.edu (Internet)", %% codetable = "ISO/ASCII", %% supported = "yes", %% docstring = "This file is a wrapper used for printing %% texbook1.bib", %% } >From texbook1.bib: %% texfile{ %% author = "Nelson H. F. Beebe ", %% version = "1.04", %% date = "28 Jun 1990", %% filename = "texbook1.bib", %% address = "Center for Scientific Computing %% and Department of Mathematics %% South Physics Building %% University of Utah %% Salt Lake City, UT 84112 %% USA %% Tel: (801) 581-5254", %% checksum = "757 2503 21835", %% email = "beebe at science.utah.edu (Internet)", %% codetable = "ISO/ASCII", %% supported = "yes", %% docstring = "This BibTeX file records books,articles, %% and electronic formums on TeX, METAFONT, Web, %% fonts, typography, indexing, and software %% related to these topics. The ISBN fields will %% be printed if the is-alpha.bst or is-plain.bst %% style files are used. The checksum field above %% contains the standard UNIX wc (word count) %% utility output of lines, words, and characters; %% eventually, a better checksum scheme should be %% developed." %% } The author, email, address, version, and date fields are fairly obvious, and usually included in most archive files anyway, except not in a form that permits automatic extraction. The filename is included to deal with systems that have filename restrictions, and also to facilitate transfer and reconstruction via e-mail. The date field could be made more precise by the addition of a time stamp; I would discourage anyone from using numbers for the month however, because different countries put the month and day in different order (is 03/04/90 in March or April?). Since the turn of the century is only 9.5 years away (or 10.5, depending on your point of view), I'm getting in the habit of using 4 digits for the year. I've written a small UNIX shell script that helps me keep the checksum fields updated. For now, as noted in the last docstring, the UNIX wc utility is being used; the UNIX sum utility actually creates a checksum, but its implementation varies from system to system, so the same number in general cannot be regenerated on different systems. wc's output gives a simple way to test for modification, but it cannot check for corruption of character remappings that we suffer on some gateways. The codetable field is present in anticipation of the Babel of 8-bit character sets being unleashed upon the TeX community through the new freedom of TeX 3.0. It will be needed to handle translation between the various character code sets. The supported field indicates whether the author maintains the file, and wants to hear bug reports, comments, et al. A value of "no" says that the author has turned it loose, and will not entertain communication about it. The docstring is a nice idea (the name is borrowed from LISP and Emacs, where functions traditionally carry their own documentation around in the compiled code); it was suggested that if each file contained a short documentation string, then it would be possible to automatically extract it and prepare a file collection summary in say, the Local Guide. Observe that in the .bib file, I had to replace @ by " at ". I've suggested to Oren Patashnik that a change in BibTeX 1.0 is in order to make it ignore any @ that does not occur at the start of a line, with optional leading white space. If you think this is a good idea, please say so; he would like feedback, and at present is worried that such a change could break some people's .bib files. [I would argue that if it did, they must be horribly formatted to begin with. BibTeX was designed without any formal comment statement or convention, which I view as a serious design flaw in any computer language.] I'm not stuck fast on the field names yet; the number of files with these new headers is still so small that they could easily be modified. Howevr, once a reasonable name set is settled on, I plan to provide Emacs editing support to generate these templates, and will no doubt develop small tools to deal with collections of such files. The %% was chosen because Frank Mittelbach's docstrip TeX macro preserves such comments; if a LaTeX .doc file were converted to a .sty file, the texfile{...} stuff should definitely be preserved. However, the %% are not essential; only the @name{key="value",...,} is. Obviously, such headers cannot go into every single file in an archive; some files cannot tolerate additions (e.g. binary files, and data files), and large source programs probably wouldn't want this sort of thing in each source file because of the maintenance burden. However, I think it would be reasonable to have such a header in every single TeX macro file and BibTeX bibliography, and in every TeX document that will be distributed anywhere. Retrofitting such comments is clearly not a simple job, and if we decide to do so, it must be coordinated so that the job is only done in one place, and then the files could be propagated to other archive sites. The extensibility of this format is important; addition keyword/value pairs can be added as needed, and we are unlikely to be able to foresee now all the possible uses this information might be put to. Comments, anyone? ------- From "Sebastian Rahtz " Fri Jun 29 09:58:26 1990 Flags: 000000000001 Return-Path: Received: from NSFnet-Relay.AC.UK by science.utah.edu with TCP; Fri 29 Jun 90 09:42:12-MDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa17250; 29 Jun 90 16:00 BST Received: from vicky.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Fri, 29 Jun 90 16:21:01 BST From: Sebastian Rahtz Date: Fri, 29 Jun 90 16:21:06 bst Message-Id: <19709.9006291521@manutius.ecs.soton.ac.uk> To: tex-archive@science.utah.edu In-Reply-To: <458.9006291353@hilliard.ecs.soton.ac.uk> Subject: Re: TeX archives -- BibTeX style file status > > The question of a named style (apalike in 0.98, I think) > comes up regularly from people in the social sciences and > humanities; the author of apalike, Stephen Gildea, has never > updated it for 0.99c, and neither has Oren Patashnik. Does apalike.bst *was* updated for 0.99, and indeed appears in your list! I use a variation on it for everything I do..... sebastian rahtz NB I'm replying to mail for archivegroup@uk.ac.aston. please address replies to the group, not me directly From "Sebastian Rahtz " Fri Jun 29 10:12:31 1990 Flags: 000000000001 Return-Path: Received: from NSFnet-Relay.AC.UK by science.utah.edu with TCP; Fri 29 Jun 90 10:10:43-MDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa18680; 29 Jun 90 16:31 BST Received: from vicky.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Fri, 29 Jun 90 16:31:16 BST From: Sebastian Rahtz Date: Fri, 29 Jun 90 16:31:20 bst Message-Id: <19724.9006291531@manutius.ecs.soton.ac.uk> To: tex-archive@science.utah.edu In-Reply-To: <614.9006291412@hilliard.ecs.soton.ac.uk> Subject: Re: archive contents Nelson asked for a summary of what archives hold. Can I attempt to summarize the UK archive? 1) we are not inaccessible outside the UK; our mail server does a thriving business worldwide. but ftp is only available within the UK 2) we aim to have a complete archive; there are no known significant omissions (though we may well not know about packages). there are no specialisms. 3) the archive working party includes VMS, Unix, MS-DOS and Mac experts, and we have a VM/CMS backup person. VMS, SMDOS and Unix versions of software tend to get the best treatment. We have some Atari material, and Aston funded the development of OzTeX, so that is well-covered. 4) our biggest problem is lack of interactive access, and the enormous difficulty in cataloguing and `maintaining' the holdings. we keep our heads above water, but only just. our second biggest bugbear is the incompatibility in binary file formats between VMS and everyone else. Sebastian Rahtz From "Karl Berry " Mon Jul 2 11:00:45 1990 Flags: 000000000011 Return-Path: <@RELAY.CS.NET:karl@aten.umb.edu> Received: from RELAY.CS.NET by science.utah.edu with TCP; Mon 2 Jul 90 10:56:52-MDT Received: from relay2.cs.net by RELAY.CS.NET id aa14694; 2 Jul 90 12:55 EDT Received: from umb.edu by RELAY.CS.NET id aa26398; 2 Jul 90 12:51 EDT Received: by umb.umb.edu (5.51/5.17) id AA24888; Mon, 2 Jul 90 12:48:11 EDT Received: by aten.cs.umb.edu (3.2/5.17) id AA05761; Mon, 2 Jul 90 12:48:08 EDT Date: Mon, 2 Jul 90 12:48:08 EDT From: Karl Berry Message-Id: <9007021648.AA05761@aten.cs.umb.edu> To: tex-archive@SCIENCE.UTAH.EDU In-Reply-To: "Nelson H. F. Beebe"'s message of Thu 28 Jun 90 19:25:25-MDT <12601539775.35.BEEBE@SCIENCE.utah.edu> Subject: TeX archives -- self-identifying files > %% @texfile{ > %% filename = "texbook1.ltx", > ... > %% docstring = "This file is a wrapper used for printing ... > %% texfile{ > %% docstring = "This BibTeX file records books,articles, Why not `@latexfile' and `bibfile'? Personally, I really wish that Knuth had made the default extension a parameter, instead of hardwiring .tex, because formats are not interchangeable. But oh well. But for identification purposes like this, we may as well have different top-level names for the different files in the TeX world. Incidentally, using `@' as the first character seems like a bad idea to me, since then these constructs can't be used in BibTeX files. Why not, say, `&'? > Since the turn of the century is only 9.5 years > away (or 10.5, depending on your point of view), I'm getting > in the habit of using 4 digits for the year. Don't you think people will write `00' in general ? But I agree that in comments like this, four digits are better. karl@cs.umb.edu From "Karl Berry " Mon Jul 2 11:04:33 1990 Flags: 000000000001 Return-Path: <@RELAY.CS.NET:karl@aten.umb.edu> Received: from RELAY.CS.NET by science.utah.edu with TCP; Mon 2 Jul 90 10:56:58-MDT Received: from relay2.cs.net by RELAY.CS.NET id aa14696; 2 Jul 90 12:55 EDT Received: from umb.edu by RELAY.CS.NET id ab26398; 2 Jul 90 12:51 EDT Received: by umb.umb.edu (5.51/5.17) id AA24943; Mon, 2 Jul 90 12:51:13 EDT Received: by aten.cs.umb.edu (3.2/5.17) id AA05764; Mon, 2 Jul 90 12:51:10 EDT Date: Mon, 2 Jul 90 12:51:10 EDT From: Karl Berry Message-Id: <9007021651.AA05764@aten.cs.umb.edu> To: tex-archive@SCIENCE.UTAH.EDU, pzf5hz%drueds2.bitnet@RELAY.CS.NET, bk4%dhdurz1.bitnet@RELAY.CS.NET Subject: font names I've taken Don (Hosek)'s suggestion for font names, and Frank & Rainer's tables in the latest TUGboat, and applied them to all the fonts I've used with TeX: the 25 standard PostScript fonts on the LaserWriter; the fonts from the Waterloo archive; fonts converted with Sun's TypeScaler system; and hand-edited bitmaps from Bigelow&Holmes. To recap, the basic scheme is: [device][foundry][weight][expansion][shape][size] D F M W E H S First I'll give all the extensions to Frank & Rainer's tables I had to make, and then all the (mostly boring) font names. My additions are in square brackets. I would also like to propose two changes to what was published in TUGboat: use `ti' instead of `it' for text italic, following DEK; and change their use of `expanded' to `extended'. As I understand it, typographic tradition is that `condensed' and `extended' fonts are versions that are designed by hand; `narrow' and `expanded' fonts are versions that are done merely geometrically. (Perhaps I'm wrong, though.) In any case, we must be clear about this. The only fonts for the names got too long were the Lucida bitmaps. This particular case doesn't matter so much, since the bitmaps aren't distributed, and probably will never be. So perhaps we shouldn't worry about it. I am about to distribute a set of TFM's for the PostScript fonts, plus a few TeX macros, that get all the accents, ligatures, etc. in the standard encoding right; I know dvips can do this with vfm files, but they aren't necessary in this case. If all is well, I will distribute with the names I've given here. karl@cs.umb.edu foundry ------- bh = Bigelow & Holmes bs = Bitstream i = ITC ps = Adobe s = Sun (Folio) family ------ ag = Avant Garde ao = Antique Olive at = American Typewriter bb = Bembo bg = Benguiat bk = Bookman bv = Baskerville bw = Broadway cb = Cooper Black cr = Courier cs = Century Schoolbook hv = Helvetica gm = Garamond gs = Gill Sans lc = Lucida nc = New Century Schoolbook op = Optima pl = Palatino rw = Rockwell tm = Times un = Univers uy = University zc = Zapf Chancery special ------ symbol = PostScript Symbol zdingb = Zapf Dingbats shape ------ n = normal [br = bright] [ol = outline] sc = small caps [sh = shadow] sl = slanted [or oblique] [ss = sans serif] tt = typewriter it [ti] = text italic u = unslanted italic weight ------- ultra light = ul extra light = el light = l semi light = sl [book = bk] medium = m [demi bold = db] semi bold = sb bold = b extra bold = eb ultra bold = ub expansion --------- ultra condensed (50%) = uc extra condensed (62.5) = ec condensed (75) = c semi condensed (87.5) = sc medium (100) = m semi expanded (112.5) = sx expanded (125) = x extra expanded (150) = ex ultra expanded (200) = ux repeat, with narrow = n and extended = t condensed and extended are by hand; narrow and expanded are automatic. (LaserWriter) psagbk AvantGarde-Book psagbksl AvantGarde-BookOblique psagd AvantGarde-Demi psagdsl AvantGarde-DemiOblique psbkd Bookman-Demi psbkdti Bookman-DemiItalic psbkl Bookman-Light psbklti Bookman-LightItalic pscrb Courier-Bold pscrbsl Courier-BoldOblique pscrsl Courier-Oblique pscr Courier pshvb Helvetica-Bold pshvbsl Helvetica-BoldOblique pshvsl Helvetica-Oblique pshv Helvetica pshvbn Helvetica-Narrow-Bold pshvbnsl Helvetica-Narrow-BoldOblique pshvnsl Helvetica-Narrow-Oblique pshvn Helvetica-Narrow psncb NewCenturySchlbk-Bold psncbti NewCenturySchlbk-BoldItalic psncti NewCenturySchlbk-Italic psncr NewCenturySchlbk-Roman psplb Palatino-Bold psplbti Palatino-BoldItalic psplti Palatino-Italic psplr Palatino-Roman pssymbol Symbol pstmb Times-Bold pstmbti Times-BoldItalic pstmti Times-Italic pstmr Times-Roman pszcti ZapfChancery-MediumItalic pszdingb ZapfDingbats (Waterloo; faces I can't identify are just labelled `xx') xx abb atr ame atrb ameb atsl amei agm avt xx bar bgr beg bwb brd bwe bre bvr bsq xx car csr cen csb cenb cssl ceni csol ceno cssh cens zcn cha zcb chab zcsl chai cbr coo xx cor xx cyr xx dea igmr gar (ITC Garamond) igmb garb igmsl gari igmol garo igmsh gars xx gas gsb gil18 unm glx hvmc helc hvsh hels xx helt xx oen aor oli opr opt opb optb opsl opti opol opto opsh opts uyr orn plr pal xx pcs xx pic xx pre xx qik rwr roc rwb rocb rwsl roci tmr rom tmb romb tmti romi xx scr xx spc (Sun/Folio) sagbk AvantGarde-Book sagbksl AvantGarde-BookOblique sagd AvantGarde-Demi sagdsl AvantGarde-DemiOblique (ditto for Bookman, Courier, Helvetica, Times) sbbr Bembo sbbti Bembo-Italic sbbb Bembo-Bold sbbbti Bembo-BoldItalic sgsm GillSans sgsti GillSans-Italic sgsb GillSans-Bold sgsbti GillSans-BoldItalic slcss LucidaSans slcssti LucidaSans-Italic slcssb LucidaSans-Bold slcssbti LucidaSans-BoldItalic slcbr LucidaBright slcbrti LucidaBright-Italic slcbrdb LucidaBright-Demi slcbrdti LucidaBright-DemiItalic [lost the `b' in `db'] slcsstt LucidaSans-Typewriter slcsstti LucidaSans-TypewriterItalic (hand-edited bitmaps from B&H; the names are longer than 8 characters, so remove the `bh'? Compress to ls instead of lcss?) bhlcr10 Lucida roman bhlcti10 Lucida italic bhlcb10 Lucida bold bhlcbi10 Lucida bold italic bhlcss10 Lucida sans bhlcssi10 Lucida sans italic bhlcssb10 Lucida sans bold bhlcssbi10 Lucida sans bold italic From "Don Hosek " Wed Jul 4 00:28:46 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Wed 4 Jul 90 00:23:07-MDT Date: Tue, 3 Jul 1990 23:17 PDT From: Don Hosek Subject: New version of BBfig To: tex-archive@science.utah.edu Message-id: <924319C87C6060301A@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: in%"tex-archive@science.utah.edu" Bernie Cosell recently posted a new version of BBfig to Usenet. It is available for anonymous FTP from ymir.claremont.edu in [anonymous.tex.graphics.bbfig] Those without FTP access may retrieve a shar file containing the entirety of the new version of BBfig by sending the command SEND [TEX.GRAPHICS.BBFIG]BBFIG.SHAR to MAILSERV@YMIR.CLAREMONT.EDU If you distribute BBfig at your archive, please make sure that you update your copy. -dh From "Don Hosek " Wed Jul 4 00:31:43 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Wed 4 Jul 90 00:28:37-MDT Date: Tue, 3 Jul 1990 23:22 PDT From: Don Hosek Subject: New version of new font selection scheme from Schoepf & Mittelbach To: tex-archive@science.utah.edu Message-id: <9243D9A06CA060301A@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: in%"tex-archive@science.utah.edu" If you are an official redistribution site for the Mainz style files, you should have already received an update on this (if you haven't contact Rainer to get on the list of distribution sites). The updates are bug fixes and affect nearly all files in the fontsel package. The files can be FTP'd from ymir.claremont.edu in the directory [anonymous.tex.inputs.latex-mainz]. The file fontsel.readme lists necessary files to retrieve. Mailserv users interested in obtaining the files should send the command SEND [TEX.INPUTS.LATEX-MAINZ]00README.TXT to mailserv@ymir.claremont.edu to get a list of files in the latex-mainz directory before retrieving any more files. -dh From "Don Hosek " Wed Jul 4 00:38:01 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Wed 4 Jul 90 00:35:03-MDT Date: Tue, 3 Jul 1990 23:29 PDT From: Don Hosek Subject: Withdrawal of the DEC DVItoLN03 package To: tex-archive@science.utah.edu Message-id: <9244BFBE080060301A@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: in%"tex-archive@science.utah.edu" I have decided to remove the old Flavio Rose DVItoLN03 drivers from the ymir archive since the driver is horribly out of date and there exists a superior driver in the public domain. LN03 users on VMS are encouraged to install the Brian {Hamilton Kelly} driver for the LN03. This driver can be obtained by anonymous FTP from ymir.claremont.edu in the directory [anonymous.tex.drivers.ukln03] Mailserv users should send the command SEND [TEX.DRIVERS.UKLN03]AAAREADME.TXT to mailserv@ymir.claremont.edu to see what files to retrieve. The version of the driver on ymir is v2.1; if there is a newer version, let me know and I'll update ymir accordingly. -dh From "Don Hosek " Wed Jul 4 00:49:13 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Wed 4 Jul 90 00:46:16-MDT Date: Tue, 3 Jul 1990 23:40 PDT From: Don Hosek Subject: Getting everybody's archives in line with each other... To: tex-archive@science.utah.edu Message-id: <92465181E62060301A@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: in%"tex-archive@science.utah.edu" I think that at this stage in the game, it would be worthwhile for everyone to at least make a complete file listing of the contents of their archive available so that we can see who has what... A proper catalog including such things as file revision dates, etc. is doubtless an awful lot of work, so I won't ask for that (yet). On ymir.claremont.edu there are three files updated roughly weekly (the exact interval is fairly random since there is a brief window when the maintenance batch job is run when certain commercial products are FTPable and I'd rather not make it easy on any hackers desiring access to those files). These are 00tex-files.txt A complete listing of the archive, less PK files 00last7days.txt Files changed in the last seven days 00last30days.txt Files changed in the last thirty days FTP users can find these files in [anonymous.txt] Mailserv users can retrieve these by appending "send [tex]" to the beginning of each name and sending the commands to mailserv@ymir.claremont.edu I am working on getting proper 00readme.txt files into every directory, but that will take a while. -dh From "Sebastian Rahtz " Wed Jul 4 01:33:18 1990 Flags: 000000000001 Return-Path: Received: from NSFnet-Relay.AC.UK by science.utah.edu with TCP; Wed 4 Jul 90 01:30:16-MDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa01386; 4 Jul 90 8:05 BST Received: from vicky.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Wed, 4 Jul 90 08:28:26 BST From: Sebastian Rahtz Date: Wed, 4 Jul 90 08:28:49 bst Message-Id: <23564.9007040728@manutius.ecs.soton.ac.uk> To: tex-archive@science.utah.edu In-Reply-To: <7514.9007040721@hilliard.ecs.soton.ac.uk> Subject: Re: (673) Getting everybody's archives in line with each other... Don Hosek says > I think that at this stage in the game, it would be worthwhile for > everyone to at least make a complete file listing of the contents of > their archive available so that we can see who has what... A proper > catalog including such things as file revision dates, etc. is doubtless > an awful lot of work, so I won't ask for that (yet). our directory listing at Aston (a VMS `DIR') is 6661 lines. I am not sure what good it would do to send it winging around the airwaves. surely if our archives are any good, we can each retrieve each others catalogues... sebastian From "bbeeton " Wed Jul 4 08:30:04 1990 Flags: 000000000001 Return-Path: Received: from MATH.AMS.COM by science.utah.edu with TCP; Wed 4 Jul 90 08:26:13-MDT Date: Wed 4 Jul 90 10:27:17-EST From: bbeeton Subject: re: getting everybody's archives in line ... To: tex-archive@science.utah.edu Message-ID: <647101637.0.BNB@MATH.AMS.COM> Mail-System-Version: i agree with sebastian that shipping full listings of archive holdings around the world is overkill. what i think might be useful, however, is a clear list of the archive tree structure, with perhaps a short description of what's to be found in each (sub)directory. the archive at labrea is (as far as i know) all contained under the main directory /tex and though i'm essentially unix-illiterate, with that one piece of information and a competent implementation of ftp, i can find my way around. (i'm sure going to miss the tops-20 machine when it goes. the vms ftp is much less friendly.) if i want to retrieve something >From clarkson, i only have to look at the writeup in tugboat that says where to find what. a month or so ago, i tried to retrieve something >From ymir, and though that's a vms system, like the one i work with daily, i couldn't find what i was looking for because i never managed to determine the head directory. after more than a half hour of frustration, i gave up. (sorry don.) well, that's been fixed now, since the structure was described in a handout i got at the tug meeting. note that i'm not suggesting that all archives have a common directory or naming scheme (there are good local reasons why that's not always possible), only that whatever the scheme, the structure is made public. i think such tree listings are so useful that i will publish in tugboat all that i receive by the editorial deadline (september 11 for the next regular issue). peter flynn has promised a list of hosts from which tex-related items can be ftp'ed; that won't be nearly as useful as it might be if no directory name is given. perhaps a preliminary version of that article could be circulated to this list, to allow knowledgeable archivists to check and augment the information. there was another feature of the late, lamented score archive that i found useful: every weekend, an automatic batch job ran, that generated a date-ordered directory listing of every subdirectory, and posted it in the relevant subdirectory; a remote user could retrieve that to determine if there was anything new. a similar set of files at every archive -- with a common name across archives (this is not the readme file) -- would be a real plus, i think. ------- From "Nelson H. F. Beebe " Wed Jul 4 14:17:48 1990 Flags: 000000000001 Mail-From: BEEBE created at 4-Jul-90 14:12:40 Date: Wed 4 Jul 90 14:12:40-MDT From: "Nelson H. F. Beebe" Subject: Please check this list To: tex-archive@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12603055703.7.BEEBE@SCIENCE.utah.edu> The current tex-archive list is appended. Please check your address on it to verify that mail is not being broadcast mistakenly to a wider audience than you intend. "TeX Archive Site Maintainers mailing list; last update [03-Jul-1990]": "mcvax!ed.ac.uk!g.toal"@uunet.uu.net, !14Jun88 Graham Toal, Acorn! "tools!ef"@uunet.uu.net, !20Nov87/22Oct89 Edgar Fu\ss, Atari ST, Archimedes! archivegroup@aston.ac.uk, !Peter Abbott and others! barry%reed.bitnet@mitvma.mit.edu, !Barry Smith! bart@cssun.tamu.edu, !23Nov88 Bart Childs, DG MV! beebe@science.utah.edu, !Nelson H. F. Beebe! beihl@mcc.com, !28Jul89 Gary Beihl, DosTeX! bloore%utorphys.bitnet@ugw.utcs.utoronto.ca, !13Mar90 Mark Bloore, MacTeX! c3ar@zaphod.uchicago.edu, !Walter Carlip! cbts8001@iruccvax.ucc.ie, !Peter Flynn! ccfd8%vax2.sussex.ac.uk%ukacrl.bitnet@mitvma.mit.edu, !Brian Williams, UK DECUS! cczdao%clan.nott.ac.uk@nsfnet-relay.ac.uk, !8Sep88 David Osborne, ICL Clan! cgl@rug.nl, !Kees van der Laan! cooke%srava.sra.co.jp@relay.cs.net, !Edgar Cooke! crawford-j@osu-20.ircc.ohio-state.edu, !20Nov87/10Apr89 John Crawford,Prime! cscmlv%ccnyvme.bitnet@mitvma.mit.edu, !27Dec89 Mike Vulis, Vector TeX! dhosek@ymir.claremont.edu, !Don Hosek! fisica@astrpd.infn.it, !25Jan89 Max Calvani! grztex%dbngmd21.bitnet@mitvma.mit.edu, !20Nov87 Ferdinand Hommes, IBM! guenther%wsuvm1.bitnet@mitvma.mit.edu, !20Nov87 Dean Guenther, IBM/CMS! in307%dhafeu11.bitnet@mitvma.mit.edu, !27Oct88/12Jan90 Peter Sawatzki, Turbo Pascal! jsg@arbortext.com, !John Gourlay! karl%cs.umb.edu@relay.cs.net, !26Apr90 Karl Berry, Web2C! kellerman@nls.com, !David Kellerman! knm5936%tamsigma.bitnet@mitvma.mit.edu, !23Nov87 Ken Marsh, HP9000/500! mackay@june.cs.washington.edu, !Pierre Mackay! mattes@azu.informatik.uni-stuttgart.de, !26Apr90 Eberhard Mattes, emTeX! mike@inrs-telecom.uquebec.ca, !20Nov87/1Apr89 Mike Ferguson, MTeX! morgan@ics.uci.edu, !10Dec89 Tim Morgan, Web2C, C TeX! mrd@sun.soe.clarkson.edu, !Michael DeCorte! naugle@ee.tamu.edu, !01Nov89 Norman Naugle, Amiga! ogawa@saturn.arc.nasa.gov, !Art Ogawa! p920021%dborub01.bitnet@mitvma.mit.edu, !14Nov88 Norbert Schwarz! peb%dm0mpi11.bitnet@mitvma.mit.edu, !14Oct89 Peter Breitenlohner, CMS, MS-DOS/Turbo Pascal! platt@ccm.umanitoba.ca, !24Nov87/8Oct89 Craig Platt, IBM/MVS! pti@well.sf.ca.us, !23Nov87/26Mar90 Lance Carnes, PCTeX! rey@math.ams.com, !Ralph E. Youngen! rokicki@neon.stanford.edu, !20Nov87/5Sep89 Tom Rokicki, Amiga! roswitha@admin.kth.se, !Roswitha Graham! simpson%yktvmx.bitnet@mitvma.mit.edu, !23Nov87 Rick Simpson, IBM RT! tnieland@aamrl.af.mil, !28May88/12Oct89 Ted Nieland, DECUS! tugboat@math.ams.com, !TUGboat editors! u0275%dgogwdg5.bitnet@mitvma.mit.edu, !08Oct89 Klaus Heidrich, for Stefan Lindner, Atari ST! ucir001%frors31.bitnet@cunyvm.cuny.edu, !Bernard Gaulle, President, GUTenberg! wsulivan%irlearn.bitnet@mitvma.mit.edu, !25Jul88 Wayne Sullivan, SB*TeX! x066tr%tamvm1.bitnet@cunyvm.cuny.edu, !Tom Reid at Texas A&M! x92%dhdurz1.bitnet@cunyvm.cuny.edu, !Joachim Lammarsch, President, DANTE! xcgnstex%ddathd21.bitnet@mitvma.mit.edu, !13Mar90 Matthias Gaertner, DEC-10, VAX/VMS! xitikgun%ddathd21.bitnet@mitvma.mit.edu, !24Nov87 Klaus Guntermann, Atari ST! yaski%ntt-20.ntt.jp@relay.cs.net !17Nov88 Yaski Saito, JTeX! ------- From "mackay@cs.washington.edu (Pierre MacKay)" Wed Jul 4 16:22:02 1990 Flags: 000000000001 Return-Path: Received: from june.cs.washington.edu by science.utah.edu with TCP; Wed 4 Jul 90 16:17:00-MDT Received: by june.cs.washington.edu (5.61/7.0jh) id AA19985; Wed, 4 Jul 90 15:14:17 -0700 Date: Wed, 4 Jul 90 15:14:17 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9007042214.AA19985@june.cs.washington.edu> To: karl%aten.umb.edu@RELAY.CS.NET Cc: tex-archive@SCIENCE.UTAH.EDU, pzf5hz%drueds2.bitnet@RELAY.CS.NET, bk4%dhdurz1.bitnet@RELAY.CS.NET In-Reply-To: Karl Berry's message of Mon, 2 Jul 90 12:51:10 EDT <9007021651.AA05764@aten.cs.umb.edu> Subject: font names Karl's scheme certainly covers the fonts we have now, but I worry about the future, when we get much richer libraries. Of course we can hope that the stupider file-name restrictions presently in force may eventually disappear, and ultimately they will have to, but the entrenched 8-character troops are going to be around for a long time. Two things strike me about Karl's scheme. The break between font name and attributes is unpredictable, and the use of the foundry in the name adds to the problem of field length. Foundry is the one item I think could best be assigned to a directory, since even MS-DOS knows how to search down a directory tree. Then we need names that are sufficiently distinctive that they can be distinguished even across several directories. With only eight letters it is not possible to be too absolute about that, but we can do the best possible. Starting from the back, with attributes, we need to allow for at least four, as in Demi Bold Extended Oblique (I don't like the thought, but it is imaginable, and Postscript positively encourages the creation of this sort of thing.) More than four are possible, in all likelyhood, but four will have to suffice in an eight character environment. We can probably find unique letters of the alphabet for all of attributes, including the important distinction Karl makes between extended and expanded, etc. So the four-letter tail of the name is AAAA---four attribute letters, in any order because they will be unique in significance. ZZZZ means no stated attribute. Demi Bold Extended Oblique will be either DBXO or DBEO, depending on which of the two [Extended,Expanded] gets the X. Now, taking the atypi Index of Typefaces, the latest U&lc, and the Adobe list as a reasonable sampling, I find very few names (exclusive of attribute) that have as many as four elements. Several with three, many with two and very many with one. I would therefor suggest that a name with only one element: Bembo, Caledonia, Courier take up four characters at the head of the eight character string. Caledonia, otherwise unqualified, would be CALEZZZZ Bembo Semi-Bold Italic would be BEMBDBIZ (substituting Demi for Semi) Palatino Bold Italic (to take an Adobe example) would be PALABIZZ Two element names would have the first two letters from each name ZapfChancery-MediumItalic ---> ZACHMIZZ AvantGarde-DemiOblique ---> AVGADOZZ Three element names have the first letter from the first two elements and the first two letters from the third NewCenturySchoolbook-BoldItalic ---> NCSCBIZZ I don't have to go on about the rare four element name. I don't hold too firmly to the ZZZZ stuff. It can be any character that is not needed to specify an attribute. Even truncation is OK, though I think it is not as consistent an approach. There is still some possibility of pi-ing a directory by transferring one foundry's "Times Roman" to another directory, but it is not possible to prevent every error with a field-length as restrictive as we are forced to deal with. The one signal virtue that I would argue for in this scheme is that you can tell very quickly which set of characters is the name and which the attribute. Also I think it may provide slightly more room for adding new font families in a consistent way. I don't know what to say about the Waterloo faces. Those cryptic letter sequences must stand for something. I have done the examples in upper-case just as a reminder that we cannot make any use of the distinction between upper and lower case. Naturally, lower-case operating systems could do the same things in lowercase. METAFONT output is special because it retains the concept of a design size. Here we might adapt Don Knuth's name-shrinker to a limit of eight characters instead of the old six. Pierre From "Don Hosek " Wed Jul 4 17:18:40 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Wed 4 Jul 90 17:13:52-MDT Date: Wed, 4 Jul 1990 16:07 PDT From: Don Hosek Subject: Re: font names To: mackay@cs.washington.edu, karl%aten.umb.edu@RELAY.CS.NET, tex-archive@SCIENCE.UTAH.EDU, pzf5hz@DRUEDS2.BITNET, bk4@DHDURZ1.BITNET Message-id: <92D040AD0480603139@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@SCIENCE.UTAH.EDU X-VMS-To: IN%"mackay@cs.washington.edu" X-VMS-Cc: in%"karl%aten.umb.edu@RELAY.CS.NET", in%"tex-archive@SCIENCE.UTAH.EDU",in%"pzf5hz@drueds2.bitnet", in%"bk4@dhdurz1.bitnet" >Two things strike me about Karl's scheme. The break between font >name >and attributes is unpredictable, and the use of the foundry in the >name >adds to the problem of field length. Foundry is the one item I >think could >best be assigned to a directory, since even MS-DOS knows how to >search down >a directory tree. MS-DOS does, and MVS does (kind of), but CMS doesn't and CTSS (Cray) doesn't. Furthermore, it simply is not possible, with existing TeX configurations, to make the directory name a significant part of the name of any file, certainly not fonts. And as you doubtless no, ITC Garamond is not Adobe Garamond is not Merganthaler Garamond is not... As for the unpredictability of unpacking font names, I have to say, in response to that, too bad. We need a scheme that can be used by _humans_ to go *from* the long name *to* the short name and get results that once can be expected to be reasonably unique. >So the four-letter tail of the name is AAAA---four attribute >letters, in any order >because they will be unique in significance. ZZZZ means no stated >attribute. >Demi Bold Extended Oblique will be either DBXO or DBEO, depending >on which of >the two [Extended,Expanded] gets the X. Why *any* order? It seems to me that we'd want to be secure in knowing that the correct form is DBXO and not OXDB or some such. Also, why "DB" for Demi-bold? (the hyphen has great significance in that last word). You've just used up two letters for one attribute of the font. Incidentally, a reference I have on hand (Jan White, _Graphic Design for the Electronic Age_) lists no less than 13 distinct font weights ranging from Hairline to Ultra. This is 4 more than Frank and Rainer and 3 more than Karl. There also is a note that the meanings of weights are not standardized in any significant way. On the extended/expanded matter, White mentions that there are two ways to change the expansion but does not pursue the matter much further. >METAFONT output is special because it retains the concept of a >design size. >Here we might adapt Don Knuth's name-shrinker to a limit of eight >characters >instead of the old six. I wonder how many people even know what Knuth's name shrinker is? (I know I learnt this exactly two summers ago, but have no idea where). In any event for the uninformed, the basic algorithim is to take the first four and last four characters of any name over 8 characters and use that as the name. (This is the reason for some of the seemingly random orderings of information in CM font names btw--if you take the first three and last three letters of any standard CM font, you'll find that you end up with a unique name). Incidentally, MF is _not_ the only guardian of design sizes, although other systems often handle things differently. The faces Merganthaler made for Xerox are design-sized although they probably use a scheme like Autologic's where there are four "ranges" for fonts, each corresponding to a single shape. If I remember correctly (my dad explained this to me four years ago when I was harrassing him for info on the APS typesetters at RR Donnelly) range one corresponded to sizes 1-9, two to 10-24, three to 25-48, and four to 49 and above. The boundaries are probably wrong, but it's close enough to give you the idea. Since most typesetters use a similar scheme, for these we could use a single character along the lines of "a" for range one, "b" for range two, etc. Incidentally, I've heard rumours that Adobe has learned the errors of its ways and is developing design-sizing software for its fonts. A few years pack, I saw an AFM for Adobe's Times Roman designed for 10pt (how I wish I had the font... their normal Times looks awful at text sizes, at least at 300dpi). I think the main thing holding them back is the fact that no one's software can deal with their techniques. -dh From "Nelson H. F. Beebe " Wed Jul 4 18:31:12 1990 Flags: 000000000001 Mail-From: BEEBE created at 4-Jul-90 18:26:15 Date: Wed 4 Jul 90 18:26:15-MDT From: "Nelson H. F. Beebe" Subject: The font mapping problem has already been solved To: tex-archive@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12603101867.7.BEEBE@SCIENCE.utah.edu> Previous postings have been wrestling with the problem of how to reduce a long font name to the short names required by many operating systems. Perhaps we should take guidance from the X Window System. In moving from X11R3 to X11R4 (released in January 1990), the X developers faced exactly this problem, and came up with a mapping file; the user can reference long meaningful names in command-line switches, but the mapping file is used to locate a specific file. The long names are systematic, and permit wildcards. Here is a portion of one fonts.dir mapping file: 8x16 -sony-fixed-medium-r-normal--16-120-100-100-c-80-iso8859-1 9x15 -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1 9x15bold -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1 10x20 -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1 12x24 -sony-fixed-medium-r-normal--24-170-100-100-c-120-iso8859-1 For example, the long name -sony-* maps to the name 12x24, which is short for the file 12x24.snf (Server Normal Font). A utility, xlsfonts, provides for listing fonts that match a particular pattern. An example is: % xlsfonts -fn '-adobe-new century schoolbook-medium-r-*' -adobe-new century schoolbook-medium-r-normal--10-100-75-75-p-60-iso8859-1 -adobe-new century schoolbook-medium-r-normal--11-80-100-100-p-60-iso8859-1 -adobe-new century schoolbook-medium-r-normal--12-120-75-75-p-70-iso8859-1 -adobe-new century schoolbook-medium-r-normal--14-100-100-100-p-82-iso8859-1 -adobe-new century schoolbook-medium-r-normal--14-140-75-75-p-82-iso8859-1 -adobe-new century schoolbook-medium-r-normal--17-120-100-100-p-91-iso8859-1 -adobe-new century schoolbook-medium-r-normal--18-180-75-75-p-103-iso8859-1 -adobe-new century schoolbook-medium-r-normal--20-140-100-100-p-103-iso8859-1 -adobe-new century schoolbook-medium-r-normal--24-240-75-75-p-137-iso8859-1 -adobe-new century schoolbook-medium-r-normal--25-180-100-100-p-136-iso8859-1 -adobe-new century schoolbook-medium-r-normal--34-240-100-100-p-181-iso8859-1 -adobe-new century schoolbook-medium-r-normal--8-80-75-75-p-50-iso8859-1 There was a directory named cmr in our local X11R4 font tree, but it was a link pointing off into nowhere; I suspect we accidentally lost it when we wiped out X11R3 a couple of months ago. Our X11 support person is on vacation, so I won't be able to recover it for a couple of weeks. The showsnf utility can be used to dump font parameters and other info from a .snf font file: % showsnf timB12.snf ------------- timB12.snf --------------- version1: 0x4 (version2: 0x4) linear printing direction: left-to-right first character: 0x20 last characters: 0xff number of font properties: 0x18 FONTNAME_REGISTRY FAMILY_NAME Times FOUNDRY Adobe WEIGHT_NAME Bold SETWIDTH_NAME Normal SLANT R ADD_STYLE_NAME PIXEL_SIZE 12 POINT_SIZE 120 RESOLUTION_X 75 RESOLUTION_Y 75 SPACING P AVERAGE_WIDTH 67 CHARSET_REGISTRY ISO8859 CHARSET_ENCODING 1 CHARSET_COLLECTIONS ASCII ISO8859-1 ADOBE-STANDARD FULL_NAME Times Bold COPYRIGHT Copyright (c) 1984, 1987 Adobe Systems, Inc., Portions Copyright 1988 Digital Equipment Corp. CAP_HEIGHT 9 X_HEIGHT 6 FONT -Adobe-Times-Bold-R-Normal--12-120-75-75-P-67-ISO8859-1 WEIGHT 280 RESOLUTION 103 QUAD_WIDTH 8 default character: 0x0 font descent: 3 font ascent: 11 minbounds: rbearing descent width exists lbearing ascent byteOffset ciFlags 0 -1 -7 -2 3 0x0 no 0x0 maxbounds: rbearing descent width exists lbearing ascent byteOffset ciFlags 12 1 3 12 13 0x1948 no 0x0 FontInfo struct: virtual memory address == 204d4 size == 6c CharInfo array: virtual memory base address == 20540 size == e00 glyph block: virtual memory address == 21340 size == 1948 You can see that the properties FAMILY_NAME through CHARSET_ENCODING are encoded into the long name: -Adobe-Times-Bold-R-Normal--12-120-75-75-P-67-ISO8859-1 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | +---CHARSET_ENCODING | | | | | | | | | | | +---CHARSET_REGISTRY | | | | | | | | | | +---AVERAGE_WIDTH | | | | | | | | | +---SPACING | | | | | | | | +---RESOLUTION_Y | | | | | | | +---RESOLUTION_X | | | | | | +---POINT_SIZE | | | | | +---PIXEL_SIZE | | | | +---SETWIDTH_NAME | | | +---SLANT | | +---WEIGHT_NAME | +---FAMILY_NAME +---FOUNDRY It is possible that a recent edition of @string{OR = "O'Reilly \& {Associates, Inc.}"} @string{OR:adr = "981 Chestnut Street, Newton, MA 02164"} @Book{Oreilly:x-3, author = "Tim O'Reilly and Valerie Quercia and Linda Lamb", title = "X Window System User's Guide for Version 11", publisher = OR, address = OR:adr, volume = "3", year = "1988", } will describe the new font handling scheme; my edition is for X11R3, which does not have it. Here is a portion of the X manual pages that has more detail: >>... >> FONT NAMES >> Collections of characters for displaying text and symbols in >> X are known as fonts. A font typically contains images that >> share a common appearance and look nice together (for exam- >> ple, a single size, boldness, slant, and character set). >> Similarly, collections of fonts that are based on a common >> type face (the variations are usually called roman, bold, >> italic, bold italic, oblique, and bold oblique) are called >> families. >> >> Sets of font families of the same resolution (usually meas- >> ured in dots per inch) are further grouped into directories >> (so named because they were initially stored in file system >> directories). Each directory contains a database which >> lists the name of the font and information on how to find >> the font. The server uses these databases to translate font >> names (which have nothing to do with file names) into font >> data. >> >> The list of font directories in which the server looks when >> trying to find a font is controlled by the font path. >> Although most installations will choose to have the server >> start up with all of the commonly used font directories, the >> font path can be changed at any time with the xset program. >> However, it is important to remember that the directory >> names are on the server's machine, not on the application's. >> >> The default font path for the sample server contains three >> directories: >> >> /usr/lib/X11/fonts/misc >> This directory contains many miscellaneous fonts >> that are useful on all systems. It contains a small >> family of fixed-width fonts in pixel heights 5 >> through 10, a family of fixed-width fonts from Dale >> Schumacher in similar pixel heights, several Kana >> fonts from Sony Corporation, a Kanji font, the stan- >> dard cursor font, two cursor fonts from Digital >> Equipment Corporation, and OPEN LOOK(tm) cursor and >> glyph fonts from Sun Microsystems. It also has font >> name aliases for the font names fixed and variable. >> >> /usr/lib/X11/fonts/75dpi >> This directory contains fonts contributed by Adobe >> Systems, Inc., Digital Equipment Corporation, >> Bitstream, Inc., Bigelow and Holmes, and Sun >> Microsystems, Inc. for 75 dots per inch displays. >> An integrated selection of sizes, styles, and >> weights are provided for each family. >> >> /usr/lib/X11/fonts/100dpi >> This directory contains 100 dots per inch versions >> of some of the fonts in the 75dpi directory. >> >> Font databases are created by running the mkfontdir program >> in the directory containing the source or compiled versions >> of the fonts (in both compressed and uncompressed formats). >> Whenever fonts are added to a directory, mkfontdir should be >> rerun so that the server can find the new fonts. To make >> the server reread the font database, reset the font path >> with the xset program. For example, to add a font to a >> private directory, the following commands could be used: >> >> % cp newfont.snf ~/myfonts >> % mkfontdir ~/myfonts >> % xset fp rehash >> >> The xlsfonts program can be used to list all of the fonts >> that are found in font databases in the current font path. >> Font names tend to be fairly long as they contain all of the >> information needed to uniquely identify individual fonts. >> However, the sample server supports wildcarding of font >> names, so the full specification >> >> -adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1 >> >> could be abbreviated as: >> >> -*-courier-medium-r-normal--*-100-*-*-*-*-*-* >> >> or, more tersely (but less accurately): >> >> *-courier-medium-r-normal--*-100-* >> >> Because the shell also has special meanings for * and ?, >> wildcarded font names should be quoted: >> >> % xlsfonts -fn '*-courier-medium-r-normal--*-100-*' >> >> If more than one font in a given directory in the font path >> matches a wildcarded font name, the choice of which particu- >> lar font to return is left to the server. However, if fonts >> from more than one directory match a name, the returned font >> will always be from the first such directory in the font >> path. The example given above will match fonts in both the >> 75dpi and 100dpi directories; if the 75dpi directory is >> ahead of the 100dpi directory in the font path, the smaller >> version of the font will be used. >> >>... Finally, here is the documentation for mkfontdir, which makes the fonts.dir file from the binary font files. The fonts.alias file is also described. >>... >> MKFONTDIR(1) USER COMMANDS MKFONTDIR(1) >> >> >> >> NAME >> mkfontdir - create fonts.dir file from directory of font >> files. >> >> SYNOPSIS >> mkfontdir [directory-names] >> >> DESCRIPTION >> Mkfontdir For each directory argument, mkfontdir reads all >> of the font files in the directory searching for properties >> named "FONT", or (failing that) the name of the file >> stripped of its suffix. These are used as font names, which >> are written out to the file "fonts.dir" in the directory >> along with the name of the font file. >> >> The kinds of font files read by mkfontdir depends on confi- >> guration parameters, but typically include SNF (suffix >> ".snf"), compressed SNF (suffix ".snf.Z"), BDF (suffix >> ".bdf"), and compressed BDF (suffix ".bdf.Z"). If a font >> exists in multiple formats, the most efficient format will >> be used. >> >> FONT NAME ALIAES >> The file "fonts.alias" which can be put in any directory of >> the font-path is used to map new names to existing fonts, >> and should be edited by hand. The format is straight for- >> ward enough, two white-space separated columns, the first >> containing aliases and the second containing font-name pat- >> terns. >> >> When a font alias is used, the name it references is search >> for in the normal manner, looking through each font direc- >> tory in turn. This means that the aliases need not mention >> fonts in the same directory as the alias file. >> >> To embed white-space in either name, simply enclose them in >> double-quote marks, to embed double-quote marks (or any >> other character), preceed them with back-slash: >> >> "magic-alias with spaces" "\"font\name\" with quotes" >> regular-alias fixed >> >> If the string "FILE_NAMES_ALIASES" stands alone on a line, >> each file-name in the directory (stripped of it's .snf suf- >> fix) will be used as an alias for that font. >> >> USAGE >> Xserver(1) looks for both "fonts.dir" and "fonts.alias" in >> each directory in the font path each time it is set (see >> xset(1)). >> >> >> SEE ALSO >> X(1), Xserver(1), xset(1) >>... ------- From "Don Hosek " Wed Jul 4 19:21:14 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Wed 4 Jul 90 19:17:40-MDT Date: Wed, 4 Jul 1990 18:11 PDT From: Don Hosek Subject: Mac TeX software available from ymir To: tex-archive@science.utah.edu Message-id: <92E1945D3620603139@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive I've just copied most of the Mac TeX software from midway.uchicago.edu to ymir.claremont.edu The notable omission was makeindex which from the datestamps on that system was two years old. With any luck, a newer version will be made available in the future. The Mac software is in the following subdirectories of [anonymous.tex.macintosh]: [anonymous.tex.macintosh.bibtex] BibTeX for the Mac [anonymous.tex.macintosh.binary] Binary files needed for OzTeX [anonymous.tex.macintosh.ctex] A C implementation of TeX for the Mac [anonymous.tex.macintosh.dvi2img] A Imagewriter driver for OzTeX [anonymous.tex.macintosh.metafont] Victor Ostromoukhov's MacMF [anonymous.tex.macintosh.ozinp] Input files for OzTeX [anonymous.tex.macintosh.ozsrc] Source files for OzTeX [anonymous.tex.macintosh,oztex] OzTeX executables Questions regarding these files should be referred to oztex@midway.uchicago.edu -dh From "Don Hosek " Thu Jul 5 02:39:57 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Thu 5 Jul 90 02:32:14-MDT Date: Thu, 5 Jul 1990 01:26 PDT From: Don Hosek Subject: Re: getting everybody's archives in line ... To: tex-archive@science.utah.edu Message-id: <931E4F208660603139@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive >there was another feature of the late, lamented score archive that >i >found useful: every weekend, an automatic batch job ran, that >generated >a date-ordered directory listing of every subdirectory, and posted >it in >the relevant subdirectory; a remote user could retrieve that to >determine >if there was anything new. a similar set of files at every >archive -- >with a common name across archives (this is not the readme file) >-- would >be a real plus, i think. Well, what I do is based on an idea I stole from Peter Abbott & crew: once a week, I run a batch job which creates a list of files created or modified in the last week and the last 30 days. Doing this allows one to tell at a glance what's new. The old score way of doing things was a bit inconvenient in that one had to examine one file for each directory. -dh From "JANET TEX@UK.AC.CRANFIELD.RMCS " Thu Jul 5 02:53:10 1990 Flags: 000000000001 Return-Path: Received: from NSFnet-Relay.AC.UK by science.utah.edu with TCP; Thu 5 Jul 90 02:46:02-MDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa03055; 5 Jul 90 9:07 BST Date: Thu, 5 JUL 90 09:32:02 BST From: TEX@rmcs.cranfield.ac.uk To: TEX-ARCHIVE <@NSFnet-Relay.AC.UK:TEX-ARCHIVE@science.utah.edu> Subject: RE: (691) font names Actually-to: Sender: "JANET TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <0000048E_002D7A70.009393621D7129A0$13_3@UK.AC.CRANFIELD.RMCS> Reply-to: Brian {Hamilton Kelly} Originally-to: CBS%UK.AC.NSFNET-RELAY::EDU.WASHINGTON.CS.JUNE::MACKAY,CBS%UK.AC.ASTON.VAXA::ARCHIVEGROUP Originally-from:TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Pierre Mackay's recent posting to archive maintainers under the above subject caused me some difficulty in reading it, because of text scrolling off the top of the screen: I ended up reading it within an editor and getting the latter to reformat paragraphs. The problem was, that although it started out with a couple of paragraphs no longer than 75 characters/line, it then degenerated to having some lines well over 80 characters in width. So can I make a little plea to all those posting to this group: please ensure that you keep the line length down when generating your messages; 75 seems a reasonable number, doesn't it? Although it was annoying to have to reformat the message before I was able to read it, but at least I had that opportunity (and it's got some good information content, worth reading), but I understand that many people experience problems with their (or more usually, certain gateways') mailers when long lines are included in messages: the offending lines may get truncated, or the whole message truncated at the first such line, or sometimes even the whole message will fall into the great bit bucket. Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: ...!mcvax!rmcs.cranfield.ac.uk!tex + + OR ...!ukc!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From "Peter Flynn, UCC Computer Centre " Thu Jul 5 16:08:58 1990 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Thu 5 Jul 90 15:38:58-MDT Received: from IRUCCIBM.BITNET by CC.UTAH.EDU; Thu, 5 Jul 90 09:06 MDT Received: from IRUCCVAX.UCC.IE (CBTS8001) by IRUCCIBM.BITNET (Mailer R2.07) with BSMTP id 3341; Thu, 05 Jul 90 13:20:55 IST Date: Thu, 5 Jul 90 13:16 GMT From: "Peter Flynn, UCC Computer Centre" Subject: Font mapping To: tex-archive@science.utah.EDU Message-id: <6CA1736423DF4001BF@CC.UTAH.EDU> X-Envelope-to: tex-archive@science.utah.EDU X-VMS-To: IN%"tex-archive@science.utah.edu" Nelson said: >> how to reduce a long font name to the short names required >> by many operating systems. One might add, "by many users". It's not just OSs which might need short names. I certainly don't want to type them, hence the need for mapping, but might it not also be a route if system-specific users used local methods such as file equates if their OS has them. ///peter From "Peter Flynn, UCC Computer Centre " Thu Jul 5 16:24:22 1990 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Thu 5 Jul 90 15:39:39-MDT Received: from IRUCCIBM.BITNET by CC.UTAH.EDU; Thu, 5 Jul 90 09:00 MDT Received: from IRUCCVAX.UCC.IE (CBTS8001) by IRUCCIBM.BITNET (Mailer R2.07) with BSMTP id 3328; Thu, 05 Jul 90 13:10:17 IST Date: Thu, 5 Jul 90 13:10 GMT From: "Peter Flynn, UCC Computer Centre" Subject: Getting in line To: tex-archive@science.utah.EDU Message-id: <6CA234ED6D9F4001B6@CC.UTAH.EDU> X-Envelope-to: tex-archive@science.utah.EDU X-VMS-To: IN%"tex-archive@science.utah.edu" I agree with barb. non-unixers have severe difficulty in guessing the (sometimes arbitrary) top-level (and lower-level) directories used by ftp'ers. I would be delighted to include the relevant pointers in the next version of the servers doc. ///peter ps---if someone tells ME them! From "Don Hosek " Thu Jul 5 16:46:47 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Thu 5 Jul 90 16:40:29-MDT Date: Thu, 5 Jul 1990 15:33 PDT From: Don Hosek Subject: Re: Font mapping To: tex-archive@science.utah.edu, driv-l@TAMVM1.BITNET Message-id: <9394B2C58B40603AB5@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive,in%"driv-l@tamvm1" (This note is being sent to both the archive group and the DVI standards group... apologies for duplicates. Please direct follow-ups to the appropriate group). Nelson's comments with regard to the Xwindows stuff, while interesting, don't address the issue that Mackay, Berry, and myself have been discussing. The mechanism by which long names are mapped to short names is irrelevant. What we are working towards is the ability to say, "if you wish to use Adobe's Times Bold Italic, you should use the command \font\tbi=??? with an appropriate name ??? that will work on all systems. Thus we want to come up with a set of rules for taking a long name and reducing it to something 8 characters or less that we can adopt as standard. This relates to the TeX archive issue in that it would be nice if the PL files for device-specific fonts were named consistently across all archives. One issue that we haven't touched on is font encoding. My feeling is that with the advent of VF (standing, of course for "composite fonts" ;-), the standard PL files for device fonts should assume _no_ remapping of characters by the device driver. This still causes a problem with Adobe fonts, but I suppose we could slip in an extra character to indicate whether we're dealing with the Adobe Standard Encoding (cf the Red book) or ISO8859/1. -dh From "mackay@cs.washington.edu (Pierre MacKay)" Thu Jul 5 23:57:12 1990 Flags: 000000000001 Return-Path: Received: from june.cs.washington.edu by science.utah.edu with TCP; Thu 5 Jul 90 23:54:43-MDT Received: by june.cs.washington.edu (5.61/7.0jh) id AA12354; Thu, 5 Jul 90 22:51:49 -0700 Date: Thu, 5 Jul 90 22:51:49 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9007060551.AA12354@june.cs.washington.edu> To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: karl%aten.umb.edu@RELAY.CS.NET, tex-archive@SCIENCE.UTAH.EDU, pzf5hz@DRUEDS2.BITNET.washington.edu, bk4@DHDURZ1.BITNET.washington.edu, D2628@applelink.apple.com In-Reply-To: Don Hosek's message of Wed, 4 Jul 1990 16:07 PDT <92D03DC8F760603139@HMCVAX.CLAREMONT.EDU> Subject: design size Don's points are well taken; perhaps things like Ultra-light and Demi-bold are so fixed that they can be reduced to a single letter. I confess I don't really know. On the matter of design size, there is a world of difference between design size and "size range". Size range may have been introduced in the film-font world of Lumigraph, Photon and that great old troff workhorse the C/A/T, but I first ran into it on the RCA VideoComp. "Size range" was rarely, if ever, associated with an aesthetically responsible consideration of the appearance of the type; it was a convention adopted because electronic expansion on the screen was only possible within a certain range. If you went beyond that range the effect of stepping, especially around curves near the vertical was all too obvious. For mechanical convenience, VideoComp had (and has--they have not changed) the concept of a 4-8 point size range at one granularity, an 8-16 point range at double the granularity, and a 16-32 point range at double the previous granularity. (That assumed that you really cared about the appearance of the font. You could use the lower granularities if you didn't care.) My impression of the marked up pixel patterns that I saw when I dealt with VideoComp is that design-size in Don Knuth's sense was never even considered. All that was considered was the change in granularity. Not that ViedoComp is all bad. If you were prepared to make up design-sized masters, the VideoComp could produce them quite faithfully. I still suspect, however, that when you run into references to "size ranges" you are dealing with purely mechanical considerations more often than not. Incidentally, someone (was it David Ness?) told me in Texas, that Stanley Morison never designed Times Roman for anything larger than nine point letterpress on newsprint. Lou Rosenblum said that he had once spotted that the "eleven point" matrices were mechanical enlargements (probably using a pantograph) of the nine-point matrices, so it looks as if we must allow for a certain amount of "size-range" fudging even in the giants of old. But it was much more limited than the sort of broad ranging that Phototypesetter firms introduced. Don has a sort of "size-range" between 10pt and 12pt, and another between 12pt and 17pt, but it is a lot more delicate than anything I ever ran into in the commercial phototypesetter world. If the phototypesetter people are making any real concession to design size, so much the better, but let us be sure that the concession is real. I have the strong suspicion that most such concessions are like the one in the VideoComp font format---just a recognition that 50 lines/em looks fine in 7-point, but a little scraggy in 35-point. Pierre From "mackay@cs.washington.edu (Pierre MacKay)" Fri Jul 6 00:08:45 1990 Flags: 000000000001 Return-Path: Received: from june.cs.washington.edu by science.utah.edu with TCP; Fri 6 Jul 90 00:06:01-MDT Received: by june.cs.washington.edu (5.61/7.0jh) id AA12590; Thu, 5 Jul 90 23:03:24 -0700 Date: Thu, 5 Jul 90 23:03:24 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9007060603.AA12590@june.cs.washington.edu> To: Beebe@science.utah.edu Cc: tex-archive@science.utah.edu, Beebe@science.utah.edu In-Reply-To: "Nelson H. F. Beebe"'s message of Wed 4 Jul 90 18:26:15-MDT <12603101867.7.BEEBE@SCIENCE.utah.edu> Subject: The font mapping problem has already been solved A font "name-server" is certainly the most open-ended way of looking at the problem. Is it well enough maintained to be stable? And can it serve the needs of 8-character systems? The X world tends to assume the better parts of a Unix file system hierarchy, with not much in the way of limitations on name length in any part of the system. I hope and pray that that is the way of the future (I learned to use meaningful file names on TOPS-20 systems, not on Unix), but the current exercise is to squeeze our information into an intirely inadequate field length. It is not entirely clear to me that this can be done under the X scheme, however otherwise the X scheme may be. Pierre From "Sebastian Rahtz " Fri Jul 6 02:26:57 1990 Flags: 000000000001 Return-Path: Received: from NSFnet-Relay.AC.UK by science.utah.edu with TCP; Fri 6 Jul 90 02:23:24-MDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa02027; 6 Jul 90 8:55 BST Received: from vicky.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Fri, 6 Jul 90 09:20:01 BST From: Sebastian Rahtz Date: Fri, 6 Jul 90 09:18:27 bst Message-Id: <1686.9007060818@manutius.ecs.soton.ac.uk> To: tex-archive@science.utah.edu In-Reply-To: <25412.9007052304@hilliard.ecs.soton.ac.uk> Subject: Re: Font mapping > ;-), the standard PL files for device fonts should assume _no_ > remapping of characters by the device driver. This still causes a > problem with Adobe fonts, but I suppose we could slip in an extra > character to indicate whether we're dealing with the Adobe Standard > Encoding (cf the Red book) or ISO8859/1. There is a fundamental problem with Adobe fonts (as I understand it), that they do not have a consistent set of characters. A lot are `guarenteed', but fonts like Times and Lucida (I know by experiment) have extra characters, and there are characters in some fonts which are not available in `vanilla' PostScript. Should there be a recommended encoding vector for PS fonts... sebastian From "Don Hosek " Fri Jul 6 12:33:08 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Fri 6 Jul 90 12:27:54-MDT Date: Fri, 6 Jul 1990 11:21 PDT From: Don Hosek Subject: The ymir batch job for listing what's changed (was RE: getting everybody's archives in line ...) To: tex-archive@science.utah.edu Message-id: <943AA06EDAE0800172@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive Dean Guenther requested this and I decided it might be of general interest. Here's the batch job... I've inserted some comments to indicate what's going on. $ ! First off, resubmit ourselves for one week later (a little less, $ ! actually) $SUBMIT/AFTER="+6-22"/NAME="TeX Weekly"/RESTART/ID - TEX_ROOT:[MAINT]__WEEKLY_MAINTENANCE.COM $ ! I do this because there was a brief time when I had to maintain two $ ! copies of the archive on different disks $DEFINE TEX_PHYS_DISK LOCAL $ ! Make sure that no old files are lurking about $PURGE TEX_PHYS_DISK:[TEX...]/LOG $ ! The shadowing support is not yet enabled $@TEX_ROOT:[MAINT]__SHADOW_ARCHIVES.COM $ ! This makes sure that all file protections are correct $@TEX_ROOT:[MAINT]__LOCKED_FILES.COM $ ! Now we get a list of files modified in the last 7 days. Maintenance $ ! files begin with "__" and we leave out directories and PK files to $ ! keep down the bulk. How many Unix commands does it take to do this, $ ! Pierre? $DIR TEX_PHYS_DISK:[TEX...]*.*; - /MODIFIED/SINCE=-7-/OUTPUT=TEX_PHYS_DISK:[TEX]00LAST7DAYS.TXT - /EXCL=(*.DIR,__*.*,*.*PK) $ ! Now we do the last 30 days $DIR TEX_PHYS_DISK:[TEX...]*.*; - /MODIFIED/SINCE=-30-/OUTPUT=TEX_PHYS_DISK:[TEX]00LAST30DAYS.TXT - /EXCL=(*.DIR,__*.*,*.*PK) $ ! And the whole archive. $DIR TEX_PHYS_DISK:[TEX...]*.*; - /OUTPUT=TEX_PHYS_DISK:[TEX]00TEX-FILES.TXT - /EXCL=(*.DIR,__*.*,*.*PK) $ ! These next steps are for creating an inverted index (idea courtesy of $ ! Nelson Beebe). The index takes file names and file types and lists $ ! the directories in which they appear. I'll tack the AWK files onto the $ ! end of this message. (Gee, so much for my Unix-bashing ;-) $DIR TEX_PHYS_DISK:[TEX...]*.*; - /EXCL=(*.DIR,__*.*) - /COL=1 - /NOTRAILING - /OUTPUT=TEX_PHYS_DISK:[TEX.MAINT]__INV_DIR.TMP1 $AWK :== $TEX_PHYS_DISK:[TEX.MAINT.RIC.GAWK]GAWK.EXE $AWK -f TEX_PHYS_DISK:[TEX.MAINT]__INVERTED_INDEX_1.AWK - TEX_PHYS_DISK:[TEX.MAINT]__INV_DIR.TMP2 $ ! VAX SORT has problems with very big files with 80-column sort keys; $ ! Over 5000 blocks of scratch space is needed to sort the AWK output $ ! which weighs in at 2039 blocks itself (!) $DEFINE SYS$SCRATCH TEX_ROOT:[MAINT] $SORT/NODUPLICATES - TEX_PHYS_DISK:[TEX.MAINT]__INV_DIR.TMP2 - TEX_PHYS_DISK:[TEX.MAINT]__INV_DIR.TMP3 $AWK -F TEX_PHYS_DISK:[TEX.MAINT]__INVERTED_INDEX_2.AWK - TEX_PHYS_DISK:[TEX]00INVERTED-INDEX.TXT $PURGE TEX_PHYS_DISK:[TEX]/LOG $EXIT ------ __INVERTED_INDEX_1.AWK: #======================================================================= # Take a VMS DIRECTORY listing, and produce an inverted index # with lines of the form # # filename directory # # which can later be sorted by filename. # # [04-Jul-1990] # Modified from Nelson Beebe's original by Don Hosek 4-Jul-1990 and # 6-Jul-1990 #======================================================================= /\[/ { # directory line directory = substr($2,index($2,":")+1); next; } /\.[0-9]+pk/ { # font file for (k = length($1); substr($1,k,1) != ";"; --k) ; # trim version number filename = substr($1,1,k-1); printf("%s\t%s\n",\ substr(filename,1,index(filename,".")) "*pk",\ directory); printf("%s\t%s\n",\ substr(filename,1,index(filename,".")) "*",\ directory); printf("%s\t%s\n",\ "*" substr(filename,index(filename,".")),\ directory); next; } /\.[0-9]+;/ { # numerical extension for (k = length($1); substr($1,k,1) != ";"; --k) ; # trim version number filename = substr($1,1,k-1); printf("%s\t%s\n",\ substr(filename,1,index(filename,".")) "*",\ directory); printf("%s\t%s\n",filename,directory); next; } /\./ { # all other files for (k = length($1); substr($1,k,1) != ";"; --k) ; # trim version number filename = substr($1,1,k-1); printf("%s\t%s\n",filename,directory); printf("%s\t%s\n",\ substr(filename,1,index(filename,".")) "*",\ directory); if (index(filename,".")!=length(filename)) printf("%s\t%s\n",\ "*" substr(filename,index(filename,".")),\ directory); } -------- __inverted_index_2.awk #======================================================================= # Filter a sorted file with lines of the form # # filenamedirectory # # to produce a more compact listing of the form # # filename directory directory directory ... # # [04-Jul-1990] #======================================================================= { if (filename != $1) # filename changed { if (filename != "") printf("%-30s %s\n",filename,directory_list); filename = $1; directory_list = $2; } else # filename unchanged { new_directory_list = directory_list " " $2; if (length(new_directory_list) > 42) { printf("%-30s %s\n",filename,directory_list); directory_list = $2; } else directory_list = new_directory_list; } } END { if (filename != "") printf("%-30s %s\n",filename,directory_list); } From "Don Hosek " Fri Jul 6 22:56:09 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Fri 6 Jul 90 22:52:13-MDT Date: Fri, 6 Jul 1990 21:45 PDT From: Don Hosek Subject: Getting everything in line--part II: specifically, the standard WEB software. To: CA_ROWLEY@vax.acs.open.ac.uk, tex-archive@science.utah.edu Message-id: <9491D35FB4E08003B0@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: IN%"CA_ROWLEY@vax.acs.open.ac.uk",tex_archive I've just finished putting together 00readme.txt files for all of the [.sources...] subdirectories on ymir. Everything here is up-to-date except some of the change files (site coordinators, can you hear me?). I've taken some care to insure that as much information as possible is included in these files, in particular, the VERSION NUMBERS of the WEB files. Now, at last, a quick reference to everything. Incidentally, I'm putting extra version numbers on the VMS change files (these do NOT change automatically with a new version of the WEB file they correspond to). This allows a user to quickly check to see if their change file is up-to-date with what the site coordinator is distributing. At present this only really applies to BibTeX and TeX (and sometime in the next week or so, MF), but will be more widespread as I work my way through the software (or get somebody else to do the working). But enough prolixity: on to the piece de resistance: ----- [tex.sources]00readme.txt The Sources tree contains the sources for the standard TeX programs and utilties written in WEB and some system-specific change files etc. The sources are broken down into the following directories: BIBTEX0_99 BibTeX 0.99c by Oren Patashnik MF2_0 METAFONT 2.0 by Donald Knuth MFWARE The MFware utilities: GFread, GFtoDVI, GFtoPK, GFtoPXL, GFtype, MFT, PKtoGF, PKtoPX, PKtype and PXtoPK TEX3_0 TeX 3.0 by Donald Knuth TEXWARE The TeXware utilities: DVItype, PatGen, PLtoTF, TFtoPL, VFtoVP and VPtoVF. WEB The WEB system and utilities: PoolType, Primes, Profile, TANGLE and WEAVE. ----- [.sources.bibtex0_99]00readme.txt This directory contains the source code for BibTeX 0.99c by Oren Patashnik, documentation, and system-specific files. See also subdirectories of [TEX.BIBTEX] for related files. 00readme.txt This file. bibtex.web The WEB source for BibTeX btxdoc.tex User and BibTeX style designer's btxhak.tex documentation for BibTeX. Also serves as btxdoc.aux test of BibTeX. btxdoc.bbl btxdoc.xua bibtex.bug Description of a bug in BibTeX 0.99c bibtex.ins BibTeX installation notes. >>>>>Specific BibTeX system implementations VMS BibTeX compile_bibtex.com Command file for compiling BibTeX bibtex.cld CLD file for BibTeX. bibtex.exe BibTeX executable (compiled under VMS 5.3) bibtex.obj BibTeX object file for those with other VMS versions bibtex.vms-changes BibTeX changes for VMS [PD VMS 1.6a] vms_bibtex_notes.txt Notes on VMS BibTeX. CMS BibTeX bibtex.cms-changes BibTeX changes for CMS TOPS-20 BibTeX bibtex.tops20-changes BibTeX changes for TOPS-20 ----- [.sources.mf2_0]00readme.txt This directory contains the source code for MF 2.0 by Donald E. Knuth, some documentation files and system specific files. 00readme.txt This file. mf.web The WEB source for MF 2.0 mf.web01-12 MF.WEB broken up into pieces 2000 lines or mf.web02-12 less. mf.web03-12 mf.web04-12 mf.web05-12 mf.web06-12 mf.web07-12 mf.web08-12 mf.web09-12 mf.web10-12 mf.web11-12 mf.web12-12 mf84.bug History of bugs in MF (see also the errata.* files in [TEX.SOURCES.TEX3_0] mfbook.tex Metafont source for the Metafontbook. >>>>>Specific MF system implementations VMS MF ****MF 2.0 for VMS TeX is currently under development**** CMS MF mf.cms-changes MF changes for CMS (outdated) TOPS-20 MF mf.tops20-changes MF changes for TOPS-20 (outdated) ----- [.sources.mfware]00readme.txt This directory contains source for the MFware programs and some system-dependent files. 00readme.txt This file. GFread 1.1 (Tomas Rokicki) Sample GF reading code. gfread.web WEB source file gfread.tops20-changes Change file for TOPS-20 GFtoDVI 3.0 (D.E. Knuth) Utility for producing proof sheets from GF files (see appendix H of the MFbook). gftodvi.web WEB source file gftodvi.cms-changes CMS change file for GFtoDVI **out of date** gftodvi.tops20-changes TOPS-20 change file for GFtoDVI **out of date** gftodvi.vms-changes VAX/VMS change file for GFtoDVI gftodvi.exe VAX/VMS executable (compiled under VMS 5.3) gftodvi.obj VAX/VMS object file GFtoPK 2.2 (Tomas Rokicki) Program to convert GF files to PK files. gftopk.web WEB source file gftopk.tops20-changes TOPS-20 change file for GFtoPK **out of date** gftopk.vms-changes VAX/VMS change file for GFtoPK **out of date** GFtoPXL 2.1 (Arthur Samuel) Utility for creating PXL files from GF files. NB: PXL files are obsolete! gftopxl.web WEB source file gftopxl.cms-changes CMS change file for GFtoPXL gftopxl.vms-changes VAX/VMS change file for GFtoPXL GFtype 3.0 (D.R. Fuchs) Diagnostic utility for listing contents of GF files. gftype.web WEB source file gftype.cms-changes CMS change file for GFtype **out of date** gftype.tops20-changes TOPS-20 change file for GFtype **out of date** gftype.vms-changes VAX/VMS change file for GFtype gftype.exe VAX/VMS executable (compiled under VMS 5.3) gftype.obj VAX/VMS object file MFT 2 (D.E. Knuth) MF "pretty printer". Used in production of _Computer Modern Typefaces_ and sections of the MFbook. mft.web WEB source file mftmac.tex Macros for use with MFT output. PKtoGF 1.0 (Tomas Rokicki) Utility for converting PK files to GF files. pktogf.web WEB source file pktogf.tops20-changes TOPS-20 change file for PKtoGF PKtoPX 2.3 (Tomas Rokicki) Utility for converting PK files to PXL files. NB: PXL files are obsolete! pktopx.web WEB source file pktopx.tops20-changes TOPS-20 change file for PKtoPX pktopx.vms-changes VAX/VMS change file for PKtoPX pktopx.exe VAX/VMS executable (compiled under VMS 5.3) pktopx.obj VAX/VMS object file PKtype 2.2 (Tomas Rokicki) Diagnostic utility for listing contents of PK files. pktype.web WEB source file pktype.tops20-changes TOPS-20 change file for PKtype pktype.vms-changes VAX/VMS change file for PKtype pktype.exe VAX/VMS executable (compiled under VMS 5.3) pktype.obj VAX/VMS object file PXtoPK 2.3 (Tomas Rokicki) Utility for converting PXL files to PK files. NB: PXL files are obsolete! pxtopk.web WEB source file pxtopk.tops20-changes TOPS-20 change file for PXtoPK pxtopk.vms-changes VAX/VMS change file for PXtoPK pxtopk.exe VAX/VMS executable (compiled under VMS 5.3) pxtopk.obj VAX/VMS object file ----- [.sources.tex3_0]00readme.txt This directory contains the source code for TeX 3.0 by Donald Knuth, some documentation files and system specific files. 00readme.txt This file. tex.web The WEB source for TeX 3.0 tex.web01-13 TeX.WEB broken up into pieces 2000 lines or tex.web02-13 less. tex.web03-13 tex.web04-13 tex.web05-13 tex.web06-13 tex.web07-13 tex.web08-13 tex.web09-13 tex.web10-13 tex.web11-13 tex.web12-13 tex.web13-13 errata.five Errata reports and related files for TeX. errata.four errata.one errata.tex errata.three errata.two errorlog.tex history.txt logmac.tex tex82.bug tex82.dif Differences between TeX82 and TeX79. Mostly of historical interest. tex3.dif New features of TeX 3.0 and MF 2.0. texbook.tex TeX source for the TeXbook. >>>>>Specific TeX system implementations VMS TeX compile_tex.com Command file for compiling TeX. tex.cld CLD file for TeX tex.exe TeX executable (compiled under VMS 5.3) tex.obj TeX object file for those with other VMS versions tex.pool TeX string pool file. tex.vms-changes TeX changes for VMS [PD VMS 3.1a] vms_tex_notes.txt Notes on VMS TeX implementation. CMS TeX tex.cms-changes TeX changes for CMS (outdated) MVS TeX tex.mvs-changes TeX changes for MVS (outdated) TOPS-10 TeX tex.tops10-changes TeX changes for TOPS-10 (outdated) TOPS-20 TeX tex.tops20-changes TeX changes for TOPS-20 (outdated) ----- [.sources.texware]00readme.txt This directory contains source for the MFware programs and some system-dependent files. 00readme.txt This file. DVItype 3.2 (D.E. Knuth) Utility program to symbolically list contents of a DVI file. dvitype.web WEB source file dvitype.cms-changes CMS change file **out of date** dvitype.tops20-changes TOPS-20 change file **out of date** dvitype.vms-changes VAX/VMS change file dvitype.exe VAX/VMS executable (compiled under VMS 5.3) dvitype.obj VAX/VMS object file PatGen (Frank Liang) Utility program for generating hyphenation patterns for TeX from a list of correctly hyphenated words. patgen.web WEB source file PLtoTF 3.2 (D.E. Knuth) Program to convert PL (symbolic listing of TFM) files to TFM files. pltotf.web WEB source file pltotf.cms-changes CMS change file **out of date** pltotf.tops20-changes TOPS-20 change file **out of date** pltotf.vms-changes VAX/VMS change file **out of date** TFtoPL 3.1 (D.E. Knuth) Program to convert TFM files to PL (symbolic listing of TFM) files. tftopl.web WEB source file tftopl.cms-changes CMS change file **out of date** tftopl.tops20-changes TOPS-20 change file **out of date** tftopl.vms-changes VAX/VMS change file **out of date** VFtoVP 1 (D.E. Knuth) Program to convert VF (composite font) files to VPL (symbolic listing of VF) files. vftovp.web WEB source file VPtoVF 1 (D.E. Knuth) Program to convert VPL (symbolic listing of VF) files to VF (composite font) files. vptovf.web WEB source file ----- [.sources.web]00readme.txt This directory contains source and documentation for the WEB package and related utilites. 00readme.txt This file. Pooltype 3 (D.E. Knuth) Utility for listing the contents of a POOL file. pooltype.web WEB source file pooltype.cms-changes Change file for VM/CMS (out of date) pooltype.vms-changes Change file for VAX/VMS pooltype.exe VAX/VMS executable (compiled under VMS 5.3) pooltype.obj VAX/VMS object file PROFILE 1.1 (D.E. Knuth) Pascal execution profiler. profile.web WEB source code Tangle 4 (D.E. Knuth) Program to take WEB source and create a compilable Pascal file from it. tangle.web WEB source code tangle.cms-changes CMS changes (Out of date) tangle.cms-pascal Bootstrap Pascal Tangle for CMS (Out of date) tangle.tops20-changes TOPS-20 changes (Out of date) tangle.vms-changes VAX/VMS changes tangle.vms-pascal Bootstrap Pascal Tangle for VAX/VMS tangle.exe Executable (compiled under VMS 5.3) tangle.obj VAX/VMS object file WEAVE 4.1 (D.E. Knuth) Program to take WEB source code and produce a printable TeX file. weave.web WEB source code webmac.tex TeX macros for use with WEAVE's output weave.cms-changes CMS change file (out of date) weave.tops20-changes TOPS-20 change file (out of date) weave.vms-changes VAX/VMS change file weave.exe Executable (compiled under VMS 5.3) weave.obj VAX/VMS object file compile_web.com VAX/VMS command file to compile WEB software web.tex "Literate Programming" by Donald E. Knuth primes.contents Sample program and additional file for the primes.web above. webman.tex WEB documentation -------------------------------------------------------------------- th-th-th-that's all folks. -dh From "Karl Berry " Tue Jul 10 08:07:37 1990 Flags: 000000000001 Return-Path: <@RELAY.CS.NET:karl@aten.umb.edu> Received: from RELAY.CS.NET by science.utah.edu with TCP; Tue 10 Jul 90 07:59:48-MDT Received: from relay2.cs.net by RELAY.CS.NET id ab25142; 10 Jul 90 9:58 EDT Received: from umb.edu by RELAY.CS.NET id aa23647; 10 Jul 90 9:50 EDT Received: by umb.umb.edu (5.51/5.17) id AA01503; Tue, 10 Jul 90 09:36:26 EDT Received: by aten.cs.umb.edu (3.2/5.17) id AA04575; Tue, 10 Jul 90 09:36:23 EDT Date: Tue, 10 Jul 90 09:36:23 EDT From: Karl Berry Message-Id: <9007101336.AA04575@aten.cs.umb.edu> To: DHOSEK%hmcvax.claremont.edu@RELAY.CS.NET Cc: tex-archive@SCIENCE.UTAH.EDU, driv-l%tamvm1.bitnet@RELAY.CS.NET In-Reply-To: Don Hosek's message of Thu, 5 Jul 1990 15:33 PDT <9394B2C58B40603AB5@HMCVAX.CLAREMONT.EDU> Subject: Font mapping PostScript fonts in Adobe's standard encoding can be dealt with without virtual fonts (at least if one doesn't care about the unencoded characters in the fonts). I have made up a set of pure TFM files with all the appropriate ligature and kerning (from the AFM files), and wrote some simple TeX macros so that \" and so forth still work. I didn't think it worthwhile to do the unencoded characters, because they are used so infrequently in English, and I don't write in any other language :-) karl@cs.umb.edu From "The TUG DVI driver standards discussion list " Tue Jul 10 14:48:32 1990 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Tue 10 Jul 90 14:48:27-MDT Received: from TAMVM1.TAMU.EDU by CC.UTAH.EDU; Tue, 10 Jul 90 14:44 MDT Received: by TAMVM1 (Mailer R2.03B) id 5393; Tue, 10 Jul 90 15:34:23 CDT Date: Tue, 10 Jul 90 09:36:23 EDT From: Karl Berry Subject: Font mapping Sender: The TUG DVI driver standards discussion list To: Nelson Beebe Reply-to: The TUG DVI driver standards discussion list Message-id: <68845BD3C57F402183@CC.UTAH.EDU> X-To: DHOSEK%hmcvax.claremont.edu@RELAY.CS.NET X-cc: tex-archive@SCIENCE.UTAH.EDU, driv-l%tamvm1.bitnet@RELAY.CS.NET In-Reply-To: Don Hosek's message of Thu, 5 Jul 1990 15:33 PDT <9394B2C58B40603AB5@HMCVAX.CLAREMONT.EDU> X-Envelope-to: beebe@SCIENCE.UTAH.EDU PostScript fonts in Adobe's standard encoding can be dealt with without virtual fonts (at least if one doesn't care about the unencoded characters in the fonts). I have made up a set of pure TFM files with all the appropriate ligature and kerning (from the AFM files), and wrote some simple TeX macros so that \" and so forth still work. I didn't think it worthwhile to do the unencoded characters, because they are used so infrequently in English, and I don't write in any other language :-) karl@cs.umb.edu From "Nelson H. F. Beebe " Tue Jul 10 19:18:10 1990 Flags: 000000000001 Mail-From: BEEBE created at 10-Jul-90 19:15:22 Date: Tue 10 Jul 90 19:15:22-MDT From: "Nelson H. F. Beebe" Subject: Status report on TeX for IBM RS/6000 To: "TeX Archive Site Maintainers mailing list; last update [04-Jul-1990]": ; cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12604683671.21.BEEBE@SCIENCE.utah.edu> Since coming back from the TUG90 meeting in College Station two weeks ago, I've been hard at work on many things, but in particular, the installation of TeX 3.0 and METAFONT 2.0 and related software, on the IBM RS/6000. My e-mail volume on the latter is starting to pick up, so it seemed worthwhile to get something written down as a guide to others who are about to start the exercise. I've therefore collected fragments of past mail messages, written an introduction, and put the result in the file ps:tex-for-ibm-rs-6000.txt on science.utah.edu, where it joins a number of other tex-for-xxx.txt files. I emphasize that is is very definitely a first draft, but it seemed important to get it out quickly to archive site maintainers for their records. You should expect that it will be updated frequently. I will e-mail it separately to the tex-archive to save you the trouble of FTPing it. ------- From "Nelson H.F. Beebe " Tue Jul 10 19:22:44 1990 Flags: 000000000001 Return-Path: Received: from csc-sun.math.utah.edu by science.utah.edu with TCP; Tue 10 Jul 90 19:17:21-MDT Received: from plot79.math.utah.edu by csc-sun.math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA13115; Tue, 10 Jul 90 19:13:18 MDT Date: Tue, 10 Jul 90 19:13:18 MDT From: Nelson H.F. Beebe Message-Id: <9007110113.AA13115@csc-sun.math.utah.edu> To: tex-archive@science Subject: tex-for-ibm-rs-6000.txt ; PS:TEX-FOR-IBM-RS-6000.TXT.3, 10-Jul-90 19:10:41, Edit by BEEBE =================== TeX for IBM RS/6000 =================== Nelson H. F. Beebe Center for Scientific Computing and Department of Mathematics South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 [10-Jul-1990] ============ INTRODUCTION ============ IBM's announcement on 15-Feb-1990 in San Francisco of its new RISC System 6000 (code named RIOS) workstations caused considerable excitement in the industry because of the reported high performance levels (peak performance of 50 Mflops, with about 9 Mflops achievable on LINPACK in double precision, and 12 Mflops on double precision 100 x 100 matrix multiplication), and highly competitive pricing. Readers interested in the technical background of the development of the RS/6000 should consult @Book{IBM:rs6000, editor = "Mamata Misra", title = "IBM RISC System/6000 Technology, publication SA23-2619-00", publisher = "IBM Corporation", year = "1990", } This book is a collection of technical articles on the IBM RS/6000 system by the people who developed it. It goes into details of hardware and software design decisions, without any sales promotions. Reading it is the next best thing to actually talking to the designers, and I'm pleased that IBM has chosen to make it available. On any new system, particularly one in which the CPU architecture is new, one can expect growing pains, and the IBM RS/6000 has been no exception. At the time of writing this, almost 5 months after the announcement, deliveries have been slow, and the first official release of the operating system appeared only in late June. Even with that release, many software problems remain, and porting difficulties should be expected. =================================== TeX and METAFONT on the IBM RS/6000 =================================== Many of those people who are interested in the IBM RS/6000 want to run TeX on it, and to that end, this document has been prepared to collect our experience with it at Utah. The BAD news is that unless you have very up-to-date system software, you will not be able to install TeX or METAFONT. The GOOD news is that with the latest release available to me since 28-Jun-1990, both TeX 3.0 and METAFONT 2.0, and related TeXware and METAFONTware all pass the trip and trap torture tests at ALL optimization levels (-g, none, and -O) in the Web2C 5.0.c implementation, with some small changes documented below. I have therefore installed all of this software compiled with -O (full optimization) on a local RS/6000, usigraph.utah.edu, located at the Utah Supercomputer Institute on the University of Utah campus. I have been collaborating with the Web2C developers (Karl Berry, Tim Morgan, and Tom Rokicki) and you can expect that later releases than 5.0.c on the Web2C system on labrea.stanford.edu will incorporate the necessary source changes, and simplify the installation. What follows now is a collection of e-mail messages, in increasing chronological order (oldest to newest, so you have to read everything to get all of the details), with irrelevant parts deleted, which summarize the current state of affairs. This includes information about building the TeX and METAFONT systems, and also about performance. ============== STATUS REPORTS ============== ------------------------------------------------------------------------ 22-Jun-90 12:58:55-MDT,2088;000000000001 Mail-From: BEEBE created at 22-Jun-90 12:58:53 Date: Fri 22 Jun 90 12:58:53-MDT From: "Nelson H. F. Beebe" Subject: Re: TeX for AIX unix To: fox@hardy.u.washington.edu cc: Beebe@SCIENCE.utah.edu In-Reply-To: <9006221734.AA12884@hardy.u.washington.edu> X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12599896542.31.BEEBE@SCIENCE.utah.edu> >>... >> can you please send me those typedefs necessary to make TeX >> run properly on the AIX system. >>... Changes for Web2C under AIX [22-Jun-1990] The current Web2C (5.0.c) translator requires two small mods to make the installation succeed on any kind of IBM AIX. The changes have to do with a different handling of sign extension of char data by AIX compilers. Later versions of the Web2C translator are expected to incorporate these changes. In the following, you may need to use AIX instead of _AIX, depending upon whether you are on a PS/2, 30xx, RT, or RS system; check what the compiler does by trying "cc -v -c foo.c"; you should see -DAIX or -D_AIX in the output. For example, on the RS/6000, you will get 104 usigraph>cc -v -c foo.c exec: /usr/lpp/xlc/bin/xlcentry(xlcentry,foo.c,foo.o,foo.lst, -D_IBMR2,-D_AIX,-qlanglvl=extended,NULL) showing that _AIX and _IBMR2 are both defined. In site.h: /* The type `schar' should be defined here to be the smallest signed type available. ANSI C compilers may need to use `signed char'. If you don't have signed characters, then define schar to be the type `short'. */ #ifdef _AIX typedef int schar; #else typedef char schar; #endif In web2c/web2c.yacc, about line 340, else if (lower_bound >= 0 && upper_bound <= 65535) my_output("int" /* "unsigned short"*/); On most systems, unsigned short is used, but for AIX, use int. ------------------------------------------------------------------------ 14-Jun-90 15:42:41-MDT,2632;000000000001 Mail-From: BEEBE created at 14-Jun-90 15:42:37 Date: Thu 14 Jun 90 15:42:37-MDT From: "Nelson H. F. Beebe" Subject: Progress report on IBM RS/6000 To: caldwell@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu, op.bowman@SCIENCE.utah.edu, ma.gustafson@SCIENCE.utah.edu, rodgers@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12597829198.21.BEEBE@SCIENCE.utah.edu> I compiled my TeX DVI drivers with only a couple of lines of code changes; with -g, output on a 40-page file matches the Sun 3 and 4 exactly, with the following times: % time dvialw dviman plot79.math.utah.edu (Sun 3/110, diskless): 45.9u 12.6s 2:20 41% 0+208k 70+37io 199pf+0w mjl.math.utah.edu (Sun SPARCstation, local swap disk): 7.9u 1.2s 0:11 81% 0+608k 23+37io 23pf+0w usigraph.utah.edu (IBM RS/6000, local disk): 11.87u 1.96s 0:46 3937% 10853+10853k 0+0io 0pf+0w I then recompiled dvialw with -O, and got usigraph.utah.edu: 7.34u 2.59s 0:30 1521% -26565+-26565k 0+0io 0pf+0w This time is almost as good as on the Sun SPARCstation, but notice that the elapsed time is double that of the SPARCstation; also the RS/6000 has a local disk for all of its files, while the SPARCstation has only local swap; all other files have to come from the Sun 3/280 file server. Unfortunately, the output with -O on the RS/6000 is wrong; it is missing curly braces in about 40 places, but is otherwise correct. Those missing braces are all from the header macros, which are output by a single function, cppsfile(), in dvialw.c, which is only one of about 150 source files and 52K lines of code making up the DVI drivers; I estimate that about 100 compiled source files are actually included in any one executable driver program. This suggests that a single code generation error is responsible. I therefore recompiled dvialw.c without optimization (and without -g), and found: usigraph.utah.edu: 8.46u 1.99s 0:34 4268% -1087+-1087k 0+0io 0pf+0w This is only marginally slower than the fully optimized program, and this time, the output is correct. I suspect that a Sun SPARCstation with everything on a local disk would outperform this by another 25% or better. I don't have such a system available, but I ran a test on a Sun 4/370 with a local disk for everything and found: maxwell.mmwb.ucsf.edu: 6.7u 1.2s 0:18 43% 0+776k 48+30io 58pf+0w >From my I/O benchmarks, this machine is actually slower than a SPARCstation with a local Hitachi disk. ------------------------------------------------------------------------ 6-Jul-90 20:00:50-MDT,1705;000000000001 Mail-From: BEEBE created at 6-Jul-90 20:00:44 Date: Fri 6 Jul 90 20:00:44-MDT From: "Nelson H. F. Beebe" Subject: Announcing success of Web2C on IBM RS/6000! To: "Web2C developers and interested parties: last update [06-Jul-1990]": ; cc: Beebe@SCIENCE.utah.edu, usimap@snow.usi.utah.edu, caldwell@SCIENCE.utah.edu, usirjm@usigraph.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12603643355.11.BEEBE@SCIENCE.utah.edu> Just before I left for College Station for the TUG90 meeting, I reported to you that by bootstrapping some files >From the Sun to the IBM RS/6000, and compiling at the debug level of optimization (-g), I was able to get TeX to pass the trip test, but METAFONT would not compile. Last week, we installed an upgrade to the O/S on the RS/6000, bringing it to level ``IBM AIX Version 3.1, loaded 28 June 1990 with 9021'' "strings /unix" gives no useful output, but ls -l reports -rwxr-xr-x 3 bin bin 26462 May 23 18:38 /bin/cc -r-xr-xr-x 1 root system 1261933 May 30 00:42 /unix -r--r--r-- 1 bin bin 25530 May 20 07:29 /usr/lib/libcsys.a The great news is that after this upgrade (1) no file bootstrapping is necessary, (2) METAFONT now compiles, and (3) trip and trap are passed at -g, none, and -O optimization levels! I have yet to install the DVI drivers, because I've once again been changing the sources. However, I expect to report back shortly with timings of the RS/6000 versus some other machines, including the IBM 3090/600VF supercomputer. ------------------------------------------------------------------------ 7-Jul-90 15:28:37-MDT,2862;000000000001 Mail-From: BEEBE created at 7-Jul-90 15:28:35 Date: Sat 7 Jul 90 15:28:35-MDT From: "Nelson H. F. Beebe" Subject: Update on TeX 3.0 timings To: "Web2C developers and interested parties: last update [06-Jul-1990]": ; cc: Beebe@SCIENCE.utah.edu, caldwell@SCIENCE.utah.edu, usimap@usigraph.utah.edu, usirjm@usigraph.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 From: "Nelson H. F. Beebe" Message-ID: <12603855954.11.BEEBE@SCIENCE.utah.edu> [This is an extract of results from an earlier message, with the IBM timings added] Here are the results of 'time latex messages.ltx' for TeX 3.0 on several (idle) machines (the IBM 3090 is never idle): Output written on messages.dvi (28 pages, 62116 bytes). DECstation 3100 (cosmic) 15.5u 0.6s 0:16 98% 564+2215k 0+19io 3pf+0w HP 9000/850 (ee) 20.9u 0.8s 0:29 74% IBM RS/6000 (usigraph) 13.8u 1.25s 0:40 2836% 0+2k 0+0io 0pf+0w IBM 3090/600VF (avalanche) 4.4u 0.2s 0:11.2 41% 208+938k 227+0io 55pf+0w Stardent 1520 (graphics) 31.3u 3.2s 0:36 95% 235+840k 28+34io 292pf+0w Sun 3/50 (moe) 64.9u 2.2s 1:11 93% 0+512k 78+12io 99pf+0w Sun 3/110 (plot79) 65.6u 5.0s 1:53 62% 0+408k 80+12io 215pf+0w Sun 3/280 (csc-sun) 34.9u 3.4s 0:48 78% 0+472k 114+19io 125pf+0w Sun 386i (shemp) 30.9u 1.7s 0:41 79% 0+496k 130+12io 157pf+0w Sun SPARCstation (mjl) 15.5u 0.8s 0:19 82% 0+1092k 6+18io 25pf+0w Sun 4/370 (maxwell.mmwb.ucsf) 13.7u 0.8s 0:17 83% 0+1304k 83+16io 74pf+0w The DECstation 3100 has nearly 2GB of local disk (/dev/rz). The Sun 3/50 and 3/110 systems are diskless; the SPARCstation has a local disk for swap, but gets its files from the central 3/280 file server. Here are the same results, ordered from fastest to slowest CPU time: IBM 3090/600VF (avalanche) 4.4u 0.2s 0:11.2 41% 208+938k 227+0io 55pf+0w Sun 4/370 (maxwell.mmwb.ucsf) 13.7u 0.8s 0:17 83% 0+1304k 83+16io 74pf+0w IBM RS/6000 (usigraph) 13.8u 1.25s 0:40 2836% 0+2k 0+0io 0pf+0w DECstation 3100 (cosmic) 15.5u 0.6s 0:16 98% 564+2215k 0+19io 3pf+0w Sun SPARCstation (mjl) 15.5u 0.8s 0:19 82% 0+1092k 6+18io 25pf+0w HP 9000/850 (ee) 20.9u 0.8s 0:29 74% Sun 386i (shemp) 30.9u 1.7s 0:41 79% 0+496k 130+12io 157pf+0w Stardent 1520 (graphics) 31.3u 3.2s 0:36 95% 235+840k 28+34io 292pf+0w Sun 3/280 (csc-sun) 34.9u 3.4s 0:48 78% 0+472k 114+19io 125pf+0w Sun 3/50 (moe) 64.9u 2.2s 1:11 93% 0+512k 78+12io 99pf+0w Sun 3/110 (plot79) 65.6u 5.0s 1:53 62% 0+408k 80+12io 215pf+0w Note that the wall clock time of the IBM RS/6000 is more than double the CPU time, despite its being otherwise idle. Repeated runs showed similar ratios. Another campus user has also reported seeing a 2:1 wall:cpu ratio on other benchmarks. [Author's note: this behavior is being investigated by local IBM staff; it may be due to idiosynchrasies of just one machine, so ignore it until further information is available.] ------------------------------------------------------------------------ 10-Jul-90 13:54:59-MDT,1450;000000000001 Mail-From: BEEBE created at 10-Jul-90 13:54:47 Date: Tue 10 Jul 90 13:54:46-MDT From: "Nelson H. F. Beebe" To: monohon@cernvax.cern.ch cc: Beebe@SCIENCE.utah.edu In-Reply-To: <9007100644.AA28181@cernvax.cern.ch> X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12604625310.21.BEEBE@SCIENCE.utah.edu> Prior to my going to College Station for the TUG90 meeting last month, I had only been able to get TeX 3.0 to pass the trip test on the IBM RS/6000 with optimization level -g (debug), and then only after bootstrapping some files from the Sun which could not be generated correctly on the RS/6000. METAFONT could not be compiled under any optimization level. On the 28th of June, the O/S was upgraded to 3.1.9021, and with that change, TeX and METAFONT pass the trip and trap tests at all optimization levels, and I've installed it here with the highest level. It is necessary to do make OPT="-O -DANSI" to get a syntax-error free compile. I worked from the 5.0.c Web2c translator, and had to make a couple of source code changes that are described in e-mail that I'll forward separately to you. Later releases of Web2C will incorporate these changes. ... ------------------------------------------------------------------------ 10-Jul-90 14:00:33-MDT,778;000000000001 Mail-From: BEEBE created at 10-Jul-90 14:00:31 Date: Tue 10 Jul 90 14:00:31-MDT From: "Nelson H. F. Beebe" Subject: xdvi on RS/6000 To: monohon@cernvax.cern.ch cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12604626354.21.BEEBE@SCIENCE.utah.edu> I could not compile xdvi from X11R4 on the RS/6000 because there is no support for the Athena widget library (-lXaw) and associated include files. I was able to make the X11R2 version run, and we are making do with it, even though it is much inferior to the 11R4 version. I unfortunately don't have the 11R3 version, which probably could be compiled. ------------------------------------------------------------------------ From "Karl Berry " Wed Jul 11 03:58:56 1990 Flags: 000000000001 Return-Path: <@RELAY.CS.NET:karl@claude.umb.edu> Received: from RELAY.CS.NET by science.utah.edu with TCP; Wed 11 Jul 90 03:55:38-MDT Received: from relay2.cs.net by RELAY.CS.NET id aa19803; 11 Jul 90 5:54 EDT Received: from umb.edu by RELAY.CS.NET id ac12793; 11 Jul 90 5:48 EDT Received: by umb.umb.edu (5.51/5.17) id AA15125; Wed, 11 Jul 90 05:51:24 EDT Received: by claude. (4.0/SMI-4.0) id AA00216; Wed, 11 Jul 90 05:49:35 EDT Date: Wed, 11 Jul 90 05:49:35 EDT From: Karl Berry Message-Id: <9007110949.AA00216@claude.> To: tex-archive@SCIENCE.UTAH.EDU Subject: More on font names. > (Pierre) Starting from the back, with attributes, we need to allow for > at least four, as in Demi Bold Extended Oblique As Don pointed out, this is only 3: demi-bold is one, the weight. I think Frank & Rainer's classification into weight, expansion, and shape (really ``variation'') covers all the bases. The last is the most painful one to do. > We can > probably find unique letters of the alphabet for all of attributes, Let's just say that they always occur in a predetermined order, as Don suggested; then they don't have to be unique. Also, I think there are more 26 total possibilities. The reason I didn't assign one letter to each attribute to begin with is that that's not what Knuth does. But I guess we are abandoning CM as a guide. > ZZZZ means no stated attribute. > ... Caledonia, otherwise unqualified, would be CALEZZZZ > I don't hold too firmly to the ZZZZ stuff. It can be any character that > is not needed to specify an attribute. Even truncation is OK, though I > think it is not as consistent an approach. Not as consistent, but so much nicer for the TeX user, who then doesn't have to write \font\x = calezzzz, which looks really ugly. Also, I don't think we can afford four, or even three, letters for the typeface name. See below. > I don't know what to say about the Waterloo faces. I found a list that Hal Peterson sent to me once upon a time. > (Don) Incidentally, a reference I have on hand (Jan White, _Graphic > Design for the Electronic Age_) lists no less than 13 distinct font > weights ranging from Hairline to Ultra. And the complete list is? > (Pierre) Bembo Semi-Bold Italic would be BEMBDBIZ > (substituting Demi for Semi) > (Don) There also is a note that the > meanings of weights are not standardized in any significant way. Or the meanings of anything else. I think we would just take the names that were already given to the typefaces; it seems an impossible burden to take on to try to rationalize the typeface naming world. This implies that, for example, `regular' and `book' weights (which are, as I understand it, the same objective thing) would each get a letter, and that we would not substitute demi for semi; we'd just take what was given. Any kind of name-shrinker will lead to even more ambiguity than we already have: we don't have any extra letters, unlike CM. To make fonts with design sizes and fonts without have consistent names, we have to waste the two characters that are the design size. Anything else invites massive confusion, IMHO. If we assign exactly one character to each possibility for each weight, expansion, and shape, and one character to the foundry, and keep two for the typefaces, this will work: FTTWES (without design sizes) FTTWESDD (with design sizes) F=foundry, T=typeface, W=weight, E=expansion, S=shape/variation, D=design size. The foundry is omitted in some cases (public domain fonts, e.g.). We omit the shape when it isn't in the name, and the expansion when it and the shape are both not in the name. Otherwise, we get monstrosities like aagkmn for Adobe AvantGarde-Book; the trailing mn doesn't really add anything (for me). I'd rather just have aagk. On the other hand, when the name is something like `Palatino Roman', we should put in the `r'. I think correspondence with the original name will be the easiest to keep straight. (When there is no original name, as with the Waterloo fonts, someone will just have to decide by fiat.) It would be nice to allow three characters for the typeface name, since two characters only provides for 676 (if we just use letters) typefaces. Perhaps by the time we have 676 typefaces available, though, the 8-character limit will be history. Probably not, but maybe. Here is a revised list of what the various abbreviations might be: foundry: a = Adobe b = Bitstream h = Bigelow&Holmes (with apologies to Chuck) i = ITC s = Sun families: (as before) weight: a = hairline l = light k = book r = regular m = medium d = demi-bold b = bold h = heavy u = ultra expansion: c = condensed (by hand) n = narrow (automatic) m = medium x = extended (by hand) e = expanded (automatic) shape/variation: [normal] (always omitted) b = bright l = outline c = small caps h = shadow o = oblique \equiv slanted s = sans serif t = typewriter i = text italic u = unslanted italic This leads to names like aagkmn for Adobe AvantGarde-Book, aplbi for Adobe Palatino-BoldItalic. From "bbeeton " Wed Jul 11 09:18:25 1990 Flags: 000000000001 Return-Path: Received: from VAX01.AMS.COM by science.utah.edu with TCP; Wed 11 Jul 90 09:15:05-MDT Date: Wed 11 Jul 90 11:15:30-EST From: bbeeton Subject: Re: More on font names. To: karl%claude.umb.edu@RELAY.CS.NET Cc: tex-archive@science.utah.edu Message-ID: <647709330.0.BNB@MATH.AMS.COM> In-Reply-To: <9007110949.AA00216@claude.> Mail-System-Version: two additions for the foundry list, please: autologic compugraphic we've been using the prefix "a" for autologic fonts since we got an aps typesetter (at the beginning of 1987); we'd contemplated the potential conflict with adobe, and decided we could use "p" for that, meaning "postscript" (which is, after all, an adobe trademark). i still prefer that scheme, but am clearly biased. (we have tried to use "short" names, but haven't felt constrained to stick to 8 chars, since the vms system doesn't have that strict a limitation, and we haven't had any need to pass any of these files around. on the other hand, it seems reasonable to look to the future and try to avoid possible conflicts, as the compugraphic imagesetter that will arrive here before the month is out has a postscript rip.) how, by the way, do you propose to distinguish between adobe type-1 and non-type-1 (type-3?) fonts, or isn't there really a problem? regarding weight, et al., i can dig out what's been proposed for the iso font standard (iso dis 9541) and post it, if anybody's interested. it's certainly not necessary to follow that, but since the approach is very similar, it might be useful to at least take a look. -- bb ------- From "Nelson H.F. Beebe " Wed Jul 11 09:46:11 1990 Flags: 000000000001 Return-Path: Received: from csc-sun.math.utah.edu by science.utah.edu with TCP; Wed 11 Jul 90 09:43:13-MDT Received: from plot79.math.utah.edu by csc-sun.math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA13966; Wed, 11 Jul 90 09:39:07 MDT Date: Wed, 11 Jul 90 09:39:07 MDT From: Nelson H.F. Beebe Message-Id: <9007111539.AA13966@csc-sun.math.utah.edu> To: tex-archive@science.utah.edu Subject: tex-for-ibm-rs-6000.txt ; PS:TEX-FOR-IBM-RS-6000.TXT.3, 10-Jul-90 19:10:41, Edit by BEEBE =================== TeX for IBM RS/6000 =================== Nelson H. F. Beebe Center for Scientific Computing and Department of Mathematics South Physics Building University of Utah Salt Lake City, UT 84112 USA Tel: (801) 581-5254 [10-Jul-1990] ============ INTRODUCTION ============ IBM's announcement on 15-Feb-1990 in San Francisco of its new RISC System 6000 (code named RIOS) workstations caused considerable excitement in the industry because of the reported high performance levels (peak performance of 50 Mflops, with about 9 Mflops achievable on LINPACK in double precision, and 12 Mflops on double precision 100 x 100 matrix multiplication), and highly competitive pricing. Readers interested in the technical background of the development of the RS/6000 should consult @Book{IBM:rs6000, editor = "Mamata Misra", title = "IBM RISC System/6000 Technology, publication SA23-2619-00", publisher = "IBM Corporation", year = "1990", } This book is a collection of technical articles on the IBM RS/6000 system by the people who developed it. It goes into details of hardware and software design decisions, without any sales promotions. Reading it is the next best thing to actually talking to the designers, and I'm pleased that IBM has chosen to make it available. On any new system, particularly one in which the CPU architecture is new, one can expect growing pains, and the IBM RS/6000 has been no exception. At the time of writing this, almost 5 months after the announcement, deliveries have been slow, and the first official release of the operating system appeared only in late June. Even with that release, many software problems remain, and porting difficulties should be expected. =================================== TeX and METAFONT on the IBM RS/6000 =================================== Many of those people who are interested in the IBM RS/6000 want to run TeX on it, and to that end, this document has been prepared to collect our experience with it at Utah. The BAD news is that unless you have very up-to-date system software, you will not be able to install TeX or METAFONT. The GOOD news is that with the latest release available to me since 28-Jun-1990, both TeX 3.0 and METAFONT 2.0, and related TeXware and METAFONTware all pass the trip and trap torture tests at ALL optimization levels (-g, none, and -O) in the Web2C 5.0.c implementation, with some small changes documented below. I have therefore installed all of this software compiled with -O (full optimization) on a local RS/6000, usigraph.utah.edu, located at the Utah Supercomputer Institute on the University of Utah campus. I have been collaborating with the Web2C developers (Karl Berry, Tim Morgan, and Tom Rokicki) and you can expect that later releases than 5.0.c on the Web2C system on labrea.stanford.edu will incorporate the necessary source changes, and simplify the installation. What follows now is a collection of e-mail messages, in increasing chronological order (oldest to newest, so you have to read everything to get all of the details), with irrelevant parts deleted, which summarize the current state of affairs. This includes information about building the TeX and METAFONT systems, and also about performance. ============== STATUS REPORTS ============== ------------------------------------------------------------------------ 22-Jun-90 12:58:55-MDT,2088;000000000001 Mail-From: BEEBE created at 22-Jun-90 12:58:53 Date: Fri 22 Jun 90 12:58:53-MDT From: "Nelson H. F. Beebe" Subject: Re: TeX for AIX unix To: fox@hardy.u.washington.edu cc: Beebe@SCIENCE.utah.edu In-Reply-To: <9006221734.AA12884@hardy.u.washington.edu> X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12599896542.31.BEEBE@SCIENCE.utah.edu> >>... >> can you please send me those typedefs necessary to make TeX >> run properly on the AIX system. >>... Changes for Web2C under AIX [22-Jun-1990] The current Web2C (5.0.c) translator requires two small mods to make the installation succeed on any kind of IBM AIX. The changes have to do with a different handling of sign extension of char data by AIX compilers. Later versions of the Web2C translator are expected to incorporate these changes. In the following, you may need to use AIX instead of _AIX, depending upon whether you are on a PS/2, 30xx, RT, or RS system; check what the compiler does by trying "cc -v -c foo.c"; you should see -DAIX or -D_AIX in the output. For example, on the RS/6000, you will get 104 usigraph>cc -v -c foo.c exec: /usr/lpp/xlc/bin/xlcentry(xlcentry,foo.c,foo.o,foo.lst, -D_IBMR2,-D_AIX,-qlanglvl=extended,NULL) showing that _AIX and _IBMR2 are both defined. In site.h: /* The type `schar' should be defined here to be the smallest signed type available. ANSI C compilers may need to use `signed char'. If you don't have signed characters, then define schar to be the type `short'. */ #ifdef _AIX typedef int schar; #else typedef char schar; #endif In web2c/web2c.yacc, about line 340, else if (lower_bound >= 0 && upper_bound <= 65535) my_output("int" /* "unsigned short"*/); On most systems, unsigned short is used, but for AIX, use int. ------------------------------------------------------------------------ 14-Jun-90 15:42:41-MDT,2632;000000000001 Mail-From: BEEBE created at 14-Jun-90 15:42:37 Date: Thu 14 Jun 90 15:42:37-MDT From: "Nelson H. F. Beebe" Subject: Progress report on IBM RS/6000 To: caldwell@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu, op.bowman@SCIENCE.utah.edu, ma.gustafson@SCIENCE.utah.edu, rodgers@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12597829198.21.BEEBE@SCIENCE.utah.edu> I compiled my TeX DVI drivers with only a couple of lines of code changes; with -g, output on a 40-page file matches the Sun 3 and 4 exactly, with the following times: % time dvialw dviman plot79.math.utah.edu (Sun 3/110, diskless): 45.9u 12.6s 2:20 41% 0+208k 70+37io 199pf+0w mjl.math.utah.edu (Sun SPARCstation, local swap disk): 7.9u 1.2s 0:11 81% 0+608k 23+37io 23pf+0w usigraph.utah.edu (IBM RS/6000, local disk): 11.87u 1.96s 0:46 3937% 10853+10853k 0+0io 0pf+0w I then recompiled dvialw with -O, and got usigraph.utah.edu: 7.34u 2.59s 0:30 1521% -26565+-26565k 0+0io 0pf+0w This time is almost as good as on the Sun SPARCstation, but notice that the elapsed time is double that of the SPARCstation; also the RS/6000 has a local disk for all of its files, while the SPARCstation has only local swap; all other files have to come from the Sun 3/280 file server. Unfortunately, the output with -O on the RS/6000 is wrong; it is missing curly braces in about 40 places, but is otherwise correct. Those missing braces are all from the header macros, which are output by a single function, cppsfile(), in dvialw.c, which is only one of about 150 source files and 52K lines of code making up the DVI drivers; I estimate that about 100 compiled source files are actually included in any one executable driver program. This suggests that a single code generation error is responsible. I therefore recompiled dvialw.c without optimization (and without -g), and found: usigraph.utah.edu: 8.46u 1.99s 0:34 4268% -1087+-1087k 0+0io 0pf+0w This is only marginally slower than the fully optimized program, and this time, the output is correct. I suspect that a Sun SPARCstation with everything on a local disk would outperform this by another 25% or better. I don't have such a system available, but I ran a test on a Sun 4/370 with a local disk for everything and found: maxwell.mmwb.ucsf.edu: 6.7u 1.2s 0:18 43% 0+776k 48+30io 58pf+0w >From my I/O benchmarks, this machine is actually slower than a SPARCstation with a local Hitachi disk. ------------------------------------------------------------------------ 6-Jul-90 20:00:50-MDT,1705;000000000001 Mail-From: BEEBE created at 6-Jul-90 20:00:44 Date: Fri 6 Jul 90 20:00:44-MDT From: "Nelson H. F. Beebe" Subject: Announcing success of Web2C on IBM RS/6000! To: "Web2C developers and interested parties: last update [06-Jul-1990]": ; cc: Beebe@SCIENCE.utah.edu, usimap@snow.usi.utah.edu, caldwell@SCIENCE.utah.edu, usirjm@usigraph.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12603643355.11.BEEBE@SCIENCE.utah.edu> Just before I left for College Station for the TUG90 meeting, I reported to you that by bootstrapping some files >From the Sun to the IBM RS/6000, and compiling at the debug level of optimization (-g), I was able to get TeX to pass the trip test, but METAFONT would not compile. Last week, we installed an upgrade to the O/S on the RS/6000, bringing it to level ``IBM AIX Version 3.1, loaded 28 June 1990 with 9021'' "strings /unix" gives no useful output, but ls -l reports -rwxr-xr-x 3 bin bin 26462 May 23 18:38 /bin/cc -r-xr-xr-x 1 root system 1261933 May 30 00:42 /unix -r--r--r-- 1 bin bin 25530 May 20 07:29 /usr/lib/libcsys.a The great news is that after this upgrade (1) no file bootstrapping is necessary, (2) METAFONT now compiles, and (3) trip and trap are passed at -g, none, and -O optimization levels! I have yet to install the DVI drivers, because I've once again been changing the sources. However, I expect to report back shortly with timings of the RS/6000 versus some other machines, including the IBM 3090/600VF supercomputer. ------------------------------------------------------------------------ 7-Jul-90 15:28:37-MDT,2862;000000000001 Mail-From: BEEBE created at 7-Jul-90 15:28:35 Date: Sat 7 Jul 90 15:28:35-MDT From: "Nelson H. F. Beebe" Subject: Update on TeX 3.0 timings To: "Web2C developers and interested parties: last update [06-Jul-1990]": ; cc: Beebe@SCIENCE.utah.edu, caldwell@SCIENCE.utah.edu, usimap@usigraph.utah.edu, usirjm@usigraph.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 From: "Nelson H. F. Beebe" Message-ID: <12603855954.11.BEEBE@SCIENCE.utah.edu> [This is an extract of results from an earlier message, with the IBM timings added] Here are the results of 'time latex messages.ltx' for TeX 3.0 on several (idle) machines (the IBM 3090 is never idle): Output written on messages.dvi (28 pages, 62116 bytes). DECstation 3100 (cosmic) 15.5u 0.6s 0:16 98% 564+2215k 0+19io 3pf+0w HP 9000/850 (ee) 20.9u 0.8s 0:29 74% IBM RS/6000 (usigraph) 13.8u 1.25s 0:40 2836% 0+2k 0+0io 0pf+0w IBM 3090/600VF (avalanche) 4.4u 0.2s 0:11.2 41% 208+938k 227+0io 55pf+0w Stardent 1520 (graphics) 31.3u 3.2s 0:36 95% 235+840k 28+34io 292pf+0w Sun 3/50 (moe) 64.9u 2.2s 1:11 93% 0+512k 78+12io 99pf+0w Sun 3/110 (plot79) 65.6u 5.0s 1:53 62% 0+408k 80+12io 215pf+0w Sun 3/280 (csc-sun) 34.9u 3.4s 0:48 78% 0+472k 114+19io 125pf+0w Sun 386i (shemp) 30.9u 1.7s 0:41 79% 0+496k 130+12io 157pf+0w Sun SPARCstation (mjl) 15.5u 0.8s 0:19 82% 0+1092k 6+18io 25pf+0w Sun 4/370 (maxwell.mmwb.ucsf) 13.7u 0.8s 0:17 83% 0+1304k 83+16io 74pf+0w The DECstation 3100 has nearly 2GB of local disk (/dev/rz). The Sun 3/50 and 3/110 systems are diskless; the SPARCstation has a local disk for swap, but gets its files from the central 3/280 file server. Here are the same results, ordered from fastest to slowest CPU time: IBM 3090/600VF (avalanche) 4.4u 0.2s 0:11.2 41% 208+938k 227+0io 55pf+0w Sun 4/370 (maxwell.mmwb.ucsf) 13.7u 0.8s 0:17 83% 0+1304k 83+16io 74pf+0w IBM RS/6000 (usigraph) 13.8u 1.25s 0:40 2836% 0+2k 0+0io 0pf+0w DECstation 3100 (cosmic) 15.5u 0.6s 0:16 98% 564+2215k 0+19io 3pf+0w Sun SPARCstation (mjl) 15.5u 0.8s 0:19 82% 0+1092k 6+18io 25pf+0w HP 9000/850 (ee) 20.9u 0.8s 0:29 74% Sun 386i (shemp) 30.9u 1.7s 0:41 79% 0+496k 130+12io 157pf+0w Stardent 1520 (graphics) 31.3u 3.2s 0:36 95% 235+840k 28+34io 292pf+0w Sun 3/280 (csc-sun) 34.9u 3.4s 0:48 78% 0+472k 114+19io 125pf+0w Sun 3/50 (moe) 64.9u 2.2s 1:11 93% 0+512k 78+12io 99pf+0w Sun 3/110 (plot79) 65.6u 5.0s 1:53 62% 0+408k 80+12io 215pf+0w Note that the wall clock time of the IBM RS/6000 is more than double the CPU time, despite its being otherwise idle. Repeated runs showed similar ratios. Another campus user has also reported seeing a 2:1 wall:cpu ratio on other benchmarks. [Author's note: this behavior is being investigated by local IBM staff; it may be due to idiosynchrasies of just one machine, so ignore it until further information is available.] ------------------------------------------------------------------------ 10-Jul-90 13:54:59-MDT,1450;000000000001 Mail-From: BEEBE created at 10-Jul-90 13:54:47 Date: Tue 10 Jul 90 13:54:46-MDT From: "Nelson H. F. Beebe" To: monohon@cernvax.cern.ch cc: Beebe@SCIENCE.utah.edu In-Reply-To: <9007100644.AA28181@cernvax.cern.ch> X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12604625310.21.BEEBE@SCIENCE.utah.edu> Prior to my going to College Station for the TUG90 meeting last month, I had only been able to get TeX 3.0 to pass the trip test on the IBM RS/6000 with optimization level -g (debug), and then only after bootstrapping some files from the Sun which could not be generated correctly on the RS/6000. METAFONT could not be compiled under any optimization level. On the 28th of June, the O/S was upgraded to 3.1.9021, and with that change, TeX and METAFONT pass the trip and trap tests at all optimization levels, and I've installed it here with the highest level. It is necessary to do make OPT="-O -DANSI" to get a syntax-error free compile. I worked from the 5.0.c Web2c translator, and had to make a couple of source code changes that are described in e-mail that I'll forward separately to you. Later releases of Web2C will incorporate these changes. ... ------------------------------------------------------------------------ 10-Jul-90 14:00:33-MDT,778;000000000001 Mail-From: BEEBE created at 10-Jul-90 14:00:31 Date: Tue 10 Jul 90 14:00:31-MDT From: "Nelson H. F. Beebe" Subject: xdvi on RS/6000 To: monohon@cernvax.cern.ch cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12604626354.21.BEEBE@SCIENCE.utah.edu> I could not compile xdvi from X11R4 on the RS/6000 because there is no support for the Athena widget library (-lXaw) and associated include files. I was able to make the X11R2 version run, and we are making do with it, even though it is much inferior to the 11R4 version. I unfortunately don't have the 11R3 version, which probably could be compiled. ------------------------------------------------------------------------ From "Don Hosek " Wed Jul 11 10:05:37 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Wed 11 Jul 90 10:02:41-MDT Date: Wed, 11 Jul 1990 08:56 PDT From: Don Hosek Subject: Re: More on font names. To: tex-archive@science.utah.edu, karl%claude.umb.edu@relay.cs.net Message-id: <98141CF2ABA0801F85@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive,in%"karl%claude.umb.edu@relay.cs.net" >how, by the way, do you propose to distinguish between adobe type-1 >and non-type-1 (type-3?) fonts, or isn't there really a problem? There's really no need to distinguish between the two. Any founder who had access to the type-1 specification would not bother releasing the font in type-3 as well. The distinction on the basis of foundry should be adequate (almost... what happened to the distinction on the basis of device? Mergenthaler makes typefaces for a lot of printers, although I suppose we could just settle on a device code in place of the founder, e.g. something along the lines of xcsbxi10 for Xerox Merganthaler Century Schoolbook Bold Extended Text Italic 10 point). >regarding weight, et al., i can dig out what's been proposed for >the iso font standard (iso dis 9541) and post it, if anybody's >interested. it's certainly not necessary to follow that, but since >the approach is very similar, it might be useful to at least take a >look. I promise I'll get the list of weights from Jan White's book out sometime in the next day or two. I don't have it handy at the moment. -dh From "Thomas J. Reid " Wed Jul 11 16:39:26 1990 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Wed 11 Jul 90 16:36:58-MDT Received: from TAMVM1.TAMU.EDU by CC.UTAH.EDU; Wed, 11 Jul 90 16:33 MDT Received: from TAMVM1 (X066TR) by TAMVM1.TAMU.EDU (Mailer R2.03B) with BSMTP id 2987; Wed, 11 Jul 90 17:34:16 CDT Date: Wed, 11 Jul 90 17:26:08 CDT From: "Thomas J. Reid" Subject: Re: More on font names. To: tex-archive@science.utah.EDU Message-id: <67ABF740A39F4028BC@CC.UTAH.EDU> In-Reply-To: Your message of Wed, 11 Jul 1990 08:56 PDT X-Envelope-to: tex-archive@science.utah.EDU On Wed, 11 Jul 1990 08:56 PDT Don Hosek said: > ... Mergenthaler makes typefaces for a lot of printers, >although I suppose we could just settle on a device code in place of >the founder, e.g. something along the lines of xcsbxi10 for Xerox >Merganthaler Century Schoolbook Bold Extended Text Italic 10 point). But there can a many-to-many relationship between foundry and device. Xerox offers fonts for their 9700 family which they licensed from Mergenthaler. However, their 4650 (600 dpi) fonts are licensed from Compugraphic and ITC. There are also other companies which sell fonts for these printers. It is very possible that a given typeface is available for a device from more than one foundry. Then, of course, since we are dealing with TeX fonts, will it ever be necessary to distinguish between a Mergenthaler Century Schoolbook font for a Xerox printer versus Merg. C.S. for a high-resolution typesetter? In theory, any differences in character metrics should be slight (due to pixel map adjustments for the specific printer); a good "max drift" algorithm should be able to accomodate the differences. (How close to reality is this theory?) >I promise I'll get the list of weights from Jan White's book out >sometime in the next day or two. I don't have it handy at the moment. > >-dh Since I'm already replying, from page 45 of "Graphic Design for the Electronic Age" by Jan V. White: "Don't forget the many variations of boldness that are available. "Hairline Thin Extra Light Light Book Regular Medium Demi Bold Semi Bold Heavy Black Ultra ... "Think about the basic variations in width. "Regular Condensed Expanded "Plus these additional variations. "Extra Condensed Ultra Compressed Extra Compressed Compressed Narrow Extended Expanded Wide" (Note: "Expanded" is given in both "variation of widths" lists.) He then goes on to explain that condensing and expanding can be produced in different ways Other ways of doing "weights": The Univers family represents another problem. It's weights and degree of compression and slant are given by numbers. Martin Solomon shows the Univers family on page 29 of "The Art of Typography." The available codes are Univers 39, 45, 46, 47, 48, 49, 53, 55, 56, 57, 58, 59, 63, 65, 66, 67, 68, 73, 75, 76, and 83. The numbers are arranged in a matrix: expanded --------------------------------------> condensed roman roman oblique roman oblique roman light 39 | 45 46 47 48 49 | 53 55 56 57 58 59 | 63 65 66 67 68 V 73 75 76 bold 83 How would these names be handled? Would someone (mostly arbitrarily) map the different weights onto five of the thirteen weights given by White? Then do the same for the four different degrees of compression/expansion? Keeping the numbers could get confusing with numeric point sizes (un5510: boy is that a *big* font! ;-). Finally, is some provision being made for font names that, for whatever reason, don't fit into the naming scheme? ---Tom Reid From "Piet van Oostrum " Wed Jul 11 16:43:52 1990 Flags: 000000000001 Return-Path: <@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from ruuinf.cs.ruu.nl by science.utah.edu with TCP; Wed 11 Jul 90 16:40:41-MDT Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA01560; Thu, 12 Jul 90 00:39:25 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA25922; Thu, 12 Jul 90 00:40:00 met Date: Thu, 12 Jul 90 00:40:00 met From: Piet van Oostrum Message-Id: <9007112240.AA25922@praxis.cs.ruu.nl> To: Don Hosek Cc: tex-archive@science.utah.edu In-Reply-To: <9814385C3000801F85@HMCVAX.CLAREMONT.EDU> Subject: Re: More on font names. Hi Don, On 11 Jul 90 you wrote: > > I promise I'll get the list of weights from Jan White's book out > sometime in the next day or two. I don't have it handy at the moment. > I have it here: hairline, thin, extra light, light, book, regular, medium, demibold, semi, bold, heavy, black, ultra. Piet. From "Michael Ferguson " Fri Jul 13 13:10:23 1990 Flags: 000000000001 Return-Path: Received: from relay.CDNnet.CA by science.utah.edu with TCP; Fri 13 Jul 90 13:09:56-MDT Received: by relay.CDNnet.CA (4.1/1.14) id AA12533; Fri, 13 Jul 90 12:06:55 PDT Date: 13 Jul 90 15:02 -0500 From: Michael Ferguson To: , , , , , , , , , Message-Id: <1132*mike@inrs-telecom.uquebec.ca> Return-Receipt-To: Michael Ferguson Subject: Comments -- Character Input Method of Don Hosek Some comments on the proposal for character encoding scheme by Don Hosek: General Comment: I feel uncomfortable, both philosophically and practically, about any scheme that insists that font implementors, incorporate features into the font, or rather the .tfm description in order to overcome inadequacies or incompatibilities at character input. It seems to me that the new ligature features of TeX should be used to create exotic type. Knuth was uneasy about using the ligature mechanisms for German-like discretionarys. This is a similar uncleanliness. Specific Comments: 1. The current Multilingual TeX uses precisely the accent/letter pair in the hyphenation patterns to indicate that an accented letter is involved in hyphenation. It then reconstructs the letter using the accenting algorithm. This does not depend on any changes in the font. 2. My \charsubdef proposal, and associated macros, accesses the internal code from the external code by defining in almost the same manner as suggested in this comment. The current accent definition includes a test to see if the macro such as \csname 'e\endcsname is defined. If it is, it uses this result of such a definition; if not, then the ordinary accent primitive is used. However \patterns appears to be able to process macros that are no more complex than \csname 'e\endcsname. This is why I have suggested that accented letters in all hyphenation patterns be encoded in this manner, and then translated to the appropriate internal representation by a \csname .. \endcsname. set of local definitions. 3. Once a character is made active, it can only appear in macro names where the prefix, including the character, is unique. This restriction is well known to the users of Multilingual TeX. 4. Hosek is quite correct in pointing out that TeX's hyphenation routine is stopped by explicit kerns rather than macro expansions. TeX will not declare anything a word that includes anything other than implicit kerns and characters. This is due to the fact that TeX throws away all the typesetting and input information before it attempts to hyphenate, and then reconstructs the (typeset) word, including permitted discretionaries, after the hyphenation. This reconstruction is now very difficult and subtle because of the new ligature features. Knuth indicated in some email that he was finding it very difficult to do it correctly. 5. Although there may be problems of differing input code pages in the IBM-PC world, these I suspect are small compared to the IBM mainframe world. However, I do feel that the ability to handle different input code pages in the same document, especially if there are multiple authors, is an important feature of an "International TeX". From "Rainer Schoepf " Wed Jul 18 06:07:01 1990 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Wed 18 Jul 90 05:59:48-MDT Received: from DHDURZ1 by CC.UTAH.EDU; Wed, 18 Jul 90 05:56 MDT Received: from DHDURZ1 (BK4) by DHDURZ1 (Mailer R2.03B) with BSMTP id 8550; Wed, 18 Jul 90 12:34:22 CET Date: Wed, 18 Jul 90 12:12:41 CET From: Rainer Schoepf Subject: Status of various TeX servers -- a query To: TeX archive mailing list Message-id: <6284CCD1595F401603@CC.UTAH.EDU> Organization: Inst. f. Theor. Physik d. Univ. Heidelberg X-Envelope-to: tex-archive@science.utah.EDU Since some weeks I'm partly maintaining the TeX archives on the BITNET Listserv server machine here at Heidelberg. From my experiences during that time I conclude that this is the only up-to-date mail-accessible TeX server in the world. Before you start flaming me for this let me explain how the situation looks to me: [FTP, being the standard method in the US, is not an option for people here in Europe. BITFTP is a solution but it is rather overloaded.] labrea.stanford.edu: I cannot say anything about the maintenance there but it is only accessible via FTP. sun.soe.clarkson.edu: This one can be reached by mail, and it also answers nearly all requests, BUT: at least the LaTeX style collection does not get updated (I tried to send them our new stuff several times, but it never appeared in the LaTeX-style directory.) Furthermore, it uses tar --> uuencode --> split to answer large requests. This is a big problem for non-Unix sites as tar is not available on all machines. The uuencode they use is the original uucp one, i.e. no padding with a non-blank character at the end of the lines, no method of line-sequence checking, no character table at the beginning, i.e. nothing you need to get it successfully through the gateways. ymir.claremont.edu: Again, only reachable by FTP. It seems to be well-maintained (Don always reacts to my postings :-)). But it is not clear to me whether it will continue to exist when Don leaves there. science.utah.edu: Nelson Beebe has installed a mail-based service there, but from the documentation (and experience) it seems that one cannot access the FTP directory tree. aston.ac.uk: It's mail service doesn't work at the moment. It only acknowledges the requests but does not honour them. Additionally there is the character mis-translation problem at the JANET<->BITNET gateway. listserv@dhdurz1: No FTP access, but easily reachable via mail. Due to problems with character-mangling gateways most files are stored in arced and uuencoded form. This is a problem for mainframe users. DECNET/SPAN archive in Italy: Only accessible via DECNET/SPAN, i.e. unreachable for most people. Seems to be rather complete. Did I miss any major server? Comments? Rainer Sch\"opf From "Don Hosek " Thu Jul 19 19:16:45 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Thu 19 Jul 90 19:12:03-MDT Date: Thu, 19 Jul 1990 18:07 PDT From: Don Hosek Subject: Change to "grand index" of TeX files on ymir To: tex-archive@science.utah.edu Message-id: <9EAA67CEC720805284@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: in%"tex-archive@science.utah.edu" It was pointed out to me that the file 00tex-files.txt was too big to reach some sites (this is still a problem for 00inverted-index.txt, which may end up being split); to deal with this problem, the main index has been split into the following files: 00BABEL-INDEX.TXT 00BIBTEX-INDEX.TXT 00DOCUMENTATION-INDEX.TXT 00DRIVERS-INDEX.TXT 00DVI-STANDARD-INDEX.TXT 00FONTS-INDEX.TXT 00GRAPHICS-INDEX.TXT 00HERSHEY-INDEX.TXT 00IBM_PC-INDEX.TXT 00INPUTS-INDEX.TXT 00MACINTOSH-INDEX.TXT 00MF-INDEX.TXT 00PERIODICALS-INDEX.TXT 00SITE-INFO-INDEX.TXT 00SOURCES-INDEX.TXT;1 00TEST-INDEX.TXT;1 00UTILITIES-INDEX.TXT;1 00TEX-FILES.TXT now contains a list of index files available, From "Network Mailer " Fri Jul 20 13:40:04 1990 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Fri 20 Jul 90 13:40:02-MDT Received: from MAILGATE.DBIUNI19 by CC.UTAH.EDU; Fri, 20 Jul 90 13:35 MDT Received: by DBIUNI19 (Mailer R2.07) id 8889; Fri, 20 Jul 90 00:10:02 SET Date: Fri, 20 Jul 90 00:10:00 SET From: Network Mailer Subject: Undelivered mail To: Beebe@science.utah.EDU Message-id: <60B255CF0A1F400183@CC.UTAH.EDU> X-Envelope-to: Beebe@science.utah.EDU Your mail was not delivered to some or all of its intended recipients for the following reason(s): No recipients for this node. --------------------RETURNED MAIL FILE-------------------- Received: from MITVMA(MAILER) by DBIUNI19 (Mailer R2.07) id 8888; Fri, 20 Jul 90 00:10:01 SET Received: from MITVMA by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 7638; Thu, 19 Jul 90 15:53:19 EDT Received: from science.utah.edu by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with TCP; Thu, 19 Jul 90 15:53:16 EDT Date: Thu 19 Jul 90 13:44:11-MDT From: "Nelson H. F. Beebe" Subject: Correction on tuglib access To: tex-archive@science.utah.edu cc: Beebe@science.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12606982677.19.BEEBE@SCIENCE.utah.edu> Rainer Schoepf writes: >>science.utah.edu: >> Nelson Beebe has installed a mail-based service there, but from the >> documentation (and experience) it seems that one cannot access the >> FTP directory tree. The FTP tree is the anonymous FTP login directory; send mail to tuglib@science.utah.edu with the text send index from ftp to find out its contents. The TeX tree on science.utah.edu is indeed accessible, but unlike UNIX FTP, it does not reside under the FTP login directory; for its contents, send mail with the text send index from tex Perhaps a diagram will clarify this: /tuglib (root directory) | | ------------------------------------------------------------ | | | /tuglib/ftp /tuglib/support /tuglib/tex (anonymous FTP login (uu*code utilities) (TeX tree tree on science.utah.edu) on science.utah.edu) The ftp directory is actually a symbolic link to ps:, and the tex directory, a symbolic link to aps:. In both cases, the entire subtrees are accessible to tuglib. ------- From "Don Hosek " Sat Jul 21 03:27:12 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Sat 21 Jul 90 03:16:18-MDT Date: Sat, 21 Jul 1990 02:11 PDT From: Don Hosek Subject: LaTeX and SliTeX for TeX 3.0 and TeX 2.x To: tex-archive@science.utah.edu Message-id: <9FB74102CAC080556C@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: in%"tex-archive@science.utah.edu" I've installed Frank and Rainer's lplain.tex and splain.tex files on ymir as the standard versions of lplain.tex and splain.tex (the reasoning, as I explained to Rainer, is that the old files simply do not work correctly with the current version of TeX, which is 3.0). -dh From "Ron Whitney " Sat Jul 21 14:38:27 1990 Flags: 000000000001 Return-Path: Received: from MATH.AMS.COM by SCIENCE.UTAH.EDU with TCP; Sat 21 Jul 90 14:38:13-MDT Date: Sat 21 Jul 90 16:40:43-EST From: Ron Whitney Subject: Re: labrea To: Beebe@science.utah.edu Cc: DHOSEK@HMCVAX.CLAREMONT.EDU, tex-archive@science.utah.edu Message-ID: <648592843.0.RFW@MATH.AMS.COM> In-Reply-To: <12607459939.13.BEEBE@SCIENCE.utah.edu> Mail-System-Version: We've been asking Dan Kolkowitz to install new tugboat files: kolk@smiley.Stanford.EDU ; ; Dan Kolkowitz ; archivist at labrea ------- From "List Processor " Thu Jul 26 12:55:59 1990 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Thu 26 Jul 90 12:55:44-MDT Received: from DHDURZ1 by CC.UTAH.EDU; Thu, 26 Jul 90 12:56 MDT Received: by DHDURZ1 (Mailer R2.03B) id 3048; Thu, 26 Jul 90 20:28:37 CET Date: Thu, 26 Jul 90 20:28:33 CET From: List Processor Subject: File: "LISTSERV MEMO" being sent to you To: "Nelson H.F. Beebe" Message-id: <5C00D74FA79F400818@CC.UTAH.EDU> X-Envelope-to: Beebe@SCIENCE.UTAH.EDU LISTEARN List Processor, Release 1.0 ------------------------------------------- LISTEARN 1.0 (c) EARN Association 1989 is derived from: LISTEARN 1.5o (c) Eric Thomas 1986,1987,1988,1989 You can skip the introduction and go to the commands description by instructing your text editor to locate the string "GENCOM" (eg "/GENCOM" under XEDIT). ******************************* * What is LISTSERV, LISTEARN? * ******************************* LISTSERV stands for "list server"... but what does that mean? Origi- nally, LISTSERV was a mailing-list server which was designed to make group communication easier. The first version of LISTSERV, written by EDUCOM and installed at BITNIC under the userid of LISTSERV, offered basic "mail-exploding" capabilities. People with a common interest (eg network protocols, issues related to handicapped people in education, system administration problems) were grouped in a list which was then stored on LISTSERV. They could then communicate with each other by sen- ding mail to a special network address (eg UG-L@BITNIC). Any piece of mail sent to these special user-ids would then be automatically distri- buted by the list server to each and every person on the list. You did not have to know all the names and network addresses of the people sub- scribed to the list. The usual messages sent by the mailing systems when mail has been successfully delivered were sent to LISTSERV -- a big relief for the sender... People could join a list by asking the "list coordinator" (actually the person who maintains the list server) to be added to the list and it was a very convenient way to meet people and participate in interesting discussions/forums. As LISTSERV became popular and the number of lists grew, it started to show some weaknesses and limitations. Even though LISTSERV was ins- talled at a central site, it generated a very important traffic because there was an important number of people from distant nodes in the net- work. If there were ten persons of the same node on a given list, it sent ten copies of each piece of mail to the node. List maintenance be- came a problem because of the evergrowing number of requests for sub- scription. Mail headers became bigger and bigger, and 30 lines was not an uncommon size. Some non-VM users had troubles accessing the server, could not send commands nor mail to it and received files in a format their system was not able to read. Non-mail files could not be sent to a list. The server was often caught looping on a rejection mail from a network mailer. No help or command description was available, and unknown commands were ignored. Sending a "HELP" command did not produce any kind of answer from the server. Revised LISTSERV is a newer list processor which was developped at the Ecole Centrale de Paris in France to overcome the restrictions and lack of functionnality of the first version of LISTSERV. It retains the basics of the old LISTSERV and provides good ascending compatibili- ty, while offering more sophisticated functions, helpfiles and more user-friendliness. Revised LISTSERVs can be linked together to create peer lists for better network efficiency in a way that is nearly trans- parent for the user. Users can send a command to the server to subscri- be to a list. For more information about the differences between the BITNIC-type LISTSERV and Revised LISTSERV, send the following command to the nearest Revised LISTSERV: Info FEATures (or just: I FEAT) Additionally, LISTSERV and LISTEARN servers provide powerful file-server func- tions which allow list moderators to make pertinent datafiles and/or programs available to the subscribers of their lists. For more informa- tion on this new feature, issue the following command to the nearest Revised LISTSERV or LISTEARN: Info FILE During 1988, the LISTSERV code was licenced by EARN Association and distributed to its members. According to the agreement, the name of the server code had to be changed, and the name LISTEARN was chosen. Right now, the server is being developped by two different groups, led by Eric Thomas , and Turgut Kalfaoglu ******************************************************************** * Terminology and general information about LISTEARN documentation * ******************************************************************** All the information guides available from LISTEARN follow the IBM convention that changes since last release are indicated by a vertical bar in column one. These vertical bars are "reset" when the release number is incremented. Post-releases (indicated by a lowercase letter following the release number, eg "1.3c") will have exclamation marks in column one to indicate the changes from the base release (1.3 in our example) and to differentiate them from the vertical bars that must be reset when the next version (1.4 in our example) is released. Temporary restrictions/warnings will be indicated by a ">" sign in column one and will stay until the restriction is removed or the warning is no longer applicable. Backwards compatibility of all documented features will be kept across release changes unless technically impossible (eg a feature which is discovered to be incompatible with system security). Applica- tions programmers should be careful not to use any feature or command which is not documented since these are subject to change without noti- ce. All throughout the LISTEARN documentation, several terms will be used to refer to distribution lists, mailing systems, etc. Here is a short definition for some of them: "Distribution list", "LISTEARN list", "list": this is a list of per- sons to be used by LISTEARN to distribute mail and/or program files. It can be reviewed by sending a "REView" (qqv) command to the server "List title": this is the "title" of the list, eg "IBM 7171 protocol converter list". It appears in the "Sender:" field of every piece of mail distributed to the list. "List name": this is the 1-8 characters name by which a distribution list is identified to the server. It will often end in "-L", eg "CHAT-L", "UG-L", etc. "List userid": this is the network address/userid@node/mailbox to which mail and files must be sent in order to be redistributed to the list. The first part ("userid") will always be the list name (see above), while the second part ("node") is the node name of the LISTEARN server. Examples: CHAT-L@DEARN, UG-L@BITNIC. The domain name (if required by your mailing system) is always ".BITNET" "LISTEARN userid": this is the network address of the LISTEARN ser- ver, eg LISTSERV@FRECP11. The userid will usually be LISTSERV, but could be something else due to accounting conventions or suchlike. This is the network address you must send commands to. "List owner": the person(s) who maintain the list and who have autho- rity to perform list-maintenance functions. You will sometimes get a message saying that "Your request has been forwarded to the list owner". "List editor": the person, if any, who reviews material sent by users to the list before allowing the server to distribute them. If the list you send mail to is controlled by an editor, you will get a mes sage saying that "Your mail has been forwarded to the list editor". Most distribution lists do NOT have an editor and mail received by the server is distributed "as is". "File format": the "format" in which a computer file is transmitted across the network. There are several formats which all have limita- tions or flaws, and are not necessarily supported by all operating systems. LISTEARN can send files in five different formats: Punch, Disk Dump, Card Dump, Netdata and LISTEARN-Punch (issue an "Info LPunch" command for more information on the latter). It accepts only three formats as input: Punch, Disk Dump and Netdata. > Card Dump format will be accepted as input in a future version. > There is no need to support LISTEARN-Punch format as input. ******************************************************************* * Who should I contact if I have a problem with Revised LISTEARN? * ******************************************************************* In much the same way as hierarchy does not exist in Revised LISTEARN lists (all the servers are peers), there is no hierarchy in the LIST- SERV "management", but three complementary categories of persons: - The list owners: each list will have one or more owners, who are authorized to add or remove people from the list, change the list attributes, etc. They will have this authority on all the peer LIST- EARNs serving their list, and can be considered as "list managers". They are the persons to contact if you have a problem which is speci fic to a particular list, eg your name being misspelled in the mail header ("To:"), your not being able to send mail to the list, etc. Their name and network address appear in the header of the list definition file (which you can obtain by sending a "REView" command to the server -- see below) under the keyword "Owner=". - The "postmasters": each LISTEARN will have one or more postmasters (send a "RELEASE" command to get their names and network addresses). Postmasters are usually systems programmers and are the people who maintain the list servers and make sure they operate properly. They create and delete lists on their servers but do not maintain them -- that's what list owners are for. They have full authority over their own server and all of its lists, but this authority does not usual ly extend to other LISTEARNs. This means that even though they can modify the copy of any list on their server, they will not be able to affect peer lists on other servers (if any). They do not qualify for list maintenance, unless the list has no peer. Being system administrators, postmasters are usually pretty busy and it will probably take them longer to answer a question than list owners. It is therefore your interest to make sure that you do not send them complaints that ought to be directed to list owners, and they will be thankful for the time you are saving them. Typical questions that should be sent to postmasters are: "LISTEARN is not logged on, is it normal?", "Here is a copy of a piece of mail I sent to LISTEARN and it said it was not valid, why?", etc. - The LISTEARN coordinators: their names, network addresses and task are defined in LISTCOOR MEMO (send an "INFO COORD" to obtain it). Basically, they (try to) provide technical help information to the postmasters, assist new LISTEARN owners in installing the code, coordinate the placement of the servers and distributed lists on the network and correct bugs in the software. They have no special autho rity or privilege on the LISTEARNs or their host systems and there- fore do not qualify for list or server maintenance. They should be contacted mainly by postmasters, and only for reporting bugs, sugges ting improvements to the software and for questions that the owners/ postmasters were not able to answer. They should of course be con- tacted for obtaining a copy of the LISTEARN code. The following 3 sections are designed to help non-BITNET or non-VM/SP users in sending commands to LISTEARN and mail to distribution lists. If you are on a BITNET VM system and you are familiar with this concepts, just do a "/GENCOM" command to skip to the commands description. **************************************** * How can I send commands to LISTEARN? * **************************************** Commands can be sent to LISTEARN in three basic ways: interactive messages, mail, and non-mail files. The distinction between mail files and non-mail files is very important on some systems and inexistant on others; some systems provide only mail files, and some will only have normal files. In the following discussion it will be assumed that you want to send an "Info GENintro" command to LISTSERV at FRECP11 (or LISTSERV@FRECP11.BITNET in RFC822 terms). A) Interactive messages Interactive messages is a facility that is not available to all sys tems; besides, only computers which are directly connected to BITNET can send interactive messages. However, this is the fastest and most convenient way of sending commands to LISTEARN: all you have to do is send it a message with the command text as message text. Example: "*message* Info GENintro", where "*message*" is the command that must be used on your system to send an interactive message to LISTSERV at FRECP11. - On VM/SP systems, this command is "TELL LISTSERV AT FRECP11", ie what you must do is "TELL LISTSERV AT FRECP11 Info GENintro". You could also use CP SMSG rscs MSG FRECP11 LISTSERV Info GENintro, where "rscs" is the name of the RSCS virtual machine at your site. - On MVS systems with TSO/E, this command would be TRANSMIT or XMIT: "TRANSMIT FRECP11.LISTSERV NOPROLOG" When the message text screen is displayed, enter "Info GENintro" as first text line and press PF3 to send it. - On some JES2 systems, the command could be TO, VMSG or XMSG, depen ding on the local implementation: "TO LISTSERV@FRECP11 Info GENintro" - On VAX systems the command would be "SEND" or "SEND/MSG": "SEND LISTSERV@FRECP11 Info GENintro" - Other systems might, or might as well not, have a command for sending interactive messages. Please send any appropriate informa- tion to the author for inclusion in this help file, other users will be thankful for the hint. B) Mail files Those systems which do not have interactive messaging capabilities will usually have a mailing system (although this is not necessarily the case). "Command jobs" can be submitted to LISTEARN via RFC822, PROFS, or IBM NOTE formatted mail. Systems which are not capable of sending mail in any of these standards must resort to the third method (see below). Command jobs can also be used by people on sys- tems which do have interactive messaging capabilities for the usual reliability reasons (messages can be lost in a line glitch while files are *much* safer), and also because command jobs allow several commands to be submitted at once and give better control on their output. They are ideal for commands generated by programs or servers, as opposed to commands sent by human persons. You can obtain a detailed description of the commands-job feature by sending an "INFO JOB" command to LISTEARN. To send a command to LISTEARN via mail, all you have to do is send mail to the LISTEARN mailbox and type in the command text as first line in the mail body or note or whatever it is called in your sys- tem. You can enter additional commands if required, as long as you type each command on a separate line. You will get a reply via RFC822 mail, regardless of the mail agent you used to submit the command. - All VM systems can send IBM NOTEs by issuing a "NOTE LISTSERV AT FRECP11" command. Issue a "HELP NOTE" command for more information on the IBM NOTE command format. - VM systems equipped with a Crosswell mailer can send RFC822 mail by issuing a "MAIL LISTSERV@FRECP11" command. The subject field is ignored and needs not be specified. - PROFS users will have no problem finding out how to send PROFS mail to LISTEARN; however, the piece of mail must be sent as MAIL and not as a DOCUMENT. Documents cannot be sent to LISTEARN because LISTEARN is not a PROFS user. - Note: Netdata files in NOTE format generated by MVS systems are not considered as "mail" files unless they contain an IBM NOTE formatted header, which is usually not the case. You should there- fore expect them to be processed as non-mail files when sent to the LISTSERV userid. - There are other commands on other systems of which the author is not aware of. Any information would be appreciated. C) Non-mail files Those systems which do not have interactive messaging capabilities nor mailing facility will be able to transmit normal files, otherwise they would not be on a network... To submit a command job to LIST- SERV via non-mail file, all you have to do is to prepare a file (or dataset) containing the required commands, one command at a line, and > send it to the LISTEARN userid using the appropriate command. The > "//" trick which was mandatory with the previous releases of LISTEARN > is no longer required to identify the file as a command job; it will > of course still be accepted (and may even speed up command processing > under certain conditions). - On VM systems the command is "SENDFILE filename filetype TO LISTSERV AT FRECP11". There are a lot of other specialized com- mands depending on the format you wish to use, but SENDFILE will work. Please note that CARD format is not accepted as INPUT to LISTEARN, although it does know how to generate it if specifically requested (see "F=" keyword description). - On MVS systems the command will usually be: "TRANSMIT FRECP11.LISTSERV DATASET(dsname)", where dsname is the name of the dataset containing the command lines. Most MVS systems will also accept the following job: // EXEC PGM=IEBGENER //SYSUT2 DD SYSOUT=A,DEST=(FRECP11,LISTSERV) - On Multics systems the command is "sdm" and you must specify a destination of LISTSERV at node FRECP11 when prompted to enter it. You must then enter "Info GENintro" as mail contents. ****************************************** * How do I send mail to a LISTEARN list? * ****************************************** To send mail to a LISTEARN distribution list, you will have to know the network address of this list. In the following discussion we will assume that you want to send mail to "SAMPLE-L@FRECP11.BITNET" (or, in IBM terms, SAMPLE-L at FRECP11). Mail can be sent to a distribution list in either of the two following ways: A) Using a mailing system If your system is equipped with a mailing facility, all you have to do is send mail to the network address mentioned above. Refer to the information in the previous section for a description of the command to be used on your system. Note: MVS NOTEs in Netdata format fall in this category, even though they do not have a valid IBM NOTE formatted header. LISTEARN will ge- nerate a standard header and insert it on top of the note. B) Without any mailing system If your system is not equipped with a mailing facility, you will have to resort to files. Note that LISTEARN distributed mailing is primarily designed to work on systems who DO have a mailing facility; sending mail as a normal file is always possible (see below) but can be quite tedious. Mail can always be sent to a distribution list by means of the DISTRIBUTE MAIL command. To do so, you must prepare a distribution job as indicated in LISTDIST MEMO (you can obtain this memo by sen- ding an "INFO DIST" command to LISTEARN) with the list userid as one and only destination, and a valid RFC822 mail (header + text) as "data". This method should be used only if the network interface in your system is so poor that no other method can be used. To send mail to SAMPLE-L@FRECP11, you will have to prepare a file named "anything NOTE", "anything.NOTE", etc, as dictated by your system's file naming conventions. The file name can be anything while the file type/extension/whatever must be "NOTE" (all caps please). This file must contain the text to be distributed to the list, and nothing else. It must be sent "as is" to SAMPLE-L@FRECP11.BITNET, using the appropriate method. LISTEARN will generate a header and add it on top of the file. ******************************************************* * How do I send files to LISTEARN for redistribution? * ******************************************************* To send a file to LISTEARN for redistribution, all you have to do is to send the desired file "as is" to the list userid. No header should be inserted, and no particular name is to be used. The only restriction on the file name is that the filetype/file-extension/whatever it is called on your system must not be "MAIL" nor "NOTE". The only restric- tion on the contents of the file is that it must not be a Netdata NOTE NOTE file nor a PROFS-mail formatted file (otherwise it would be classified as a mail file). In some instances where the list owner suspects that files might in- voluntarily be sent to the list userid although they are not destined for being redistributed, he will have enabled an additional test to be performed on the files before redistributing them. In that case the server will expect files destined for actual redistribution to have a "FORM" value of "REDIST" (or "QUREDIST" if you want to trigger the "Quiet file transfer" feature installed at some RSCS sites). This is indicated by a "Formcheck= Yes" keyword in the list header (send an "Info KEYwords" for more information on list control keywords). Not all systems allow the user to control the FORM value of network files. On a VM system you would have to issue a "CP SPOOL PUNCH FORM REDIST" before issuing the SENDFILE command. On a MVS system you would have to expand the SYSOUT= parameter of the IEBGENER dataset: SYSOUT=(A,,REDIST) *********************************************** * Commands description (non-privileged users) * ---> GENCOM <--- *********************************************** A description of command-keywords format (eg "F=") can be found at the end of this section. Please refer to it for more information on how, where and when to specify these keywords. Info Sends you an information file like this one. Use "Info ?" for a list of topics. Please note that some of the documents available through the INFO command are restricted to certain categories of users. Help Sends you a brief description of the most useful commands, along with the names and network addresses of the server's postmasters. List Get a description of all lists. The default option is "Short", and will send you a brief description of each list (via messages). The "Long" and "Detailed" options are synonyms and will send you the "header" por- tion of each list (via file). Query listname Displays your list distribution options for the corresponding list. Refer to the SET command description for more details on the meaning of these options. SUBscribe listname SIGNUP Use this command to subcribe to a list. You will be automatically added to it unless the list owner has disabled this option, in which case he will be sent a request-for-addition note. If you have misspelled your name when issuing this command in the first place, you will be able to correct it by re-issuing it without having to sign off from the list first. In that case no notification is sent to the list owner. Note that it is not necessary to supply your full name if you have already signed up to another list of the same server. The name you provided on your first signup command will automatically be used for the new subscription. Also note that you will always be able to issue a signup command to correct your name, regardless of the list being open for au- tomatic subscription or not: as long as you are already on the list, the SUBSCRIBE command is not disabled (unless the list is set to "Validate= All commands" to protect you from UREP hackers and suchlike who might issue a SUBSCRIBE command "from" you and change your name to something you would not want to see in front of your userid; in that case, your request will be forwarded to the list owner). In the case that the list has one or more peers and that the server you are sending your SUBscribe request to is not the nearest to your node, it will automatically determine the nearest host server for the list you are subscribing to and forward your request to it. This applies only if you are not yet subscribed to the list, of course. SIGNOFF listname UNSubscribe This is the counterpart of the SUBSCRIBE command. Note that you can remove yourself from any list you have been added to, unless it is specially protected by a "Validate= All commands" keyword. Whether you have subscribed to the list yourself or you have been added to it by the list owner is irrelevant. SET listname options Mail/NOMail Files/NOFiles ACK/NOACK/MSGAck Changes your distribution options for the specified list. You can spe- cify more than one option if desired. The previous settings will be retained unless specifically changed, ie if you want to change only one of the options you do not have to specify the settings of the options you do not want to change if they differ from the standard ones. If the list is protected by a "Validate= All commands" keyword, your command will not be executed but it will be forwarded to the list owner. Mail/Nomail indicate whether you want to receive mail from this list or not. The default value is "Mail", of course. Files/NOFiles indicate whether you want to receive non-mail files from the list or not. The default is "Files", but it is recommended that no more than one person per node has this option active on any given list, for obvious network efficiency reasons. ACK/NOACK/MSGAck define the mode in which acknowledgements for mailing or file distribution are to be sent to you. ACK is the default and in- dicates that you want a file acknowledgement (short mail file which in- cludes some statistics on the mailing). NOACK directs the server not to send out any acknowledgement; a single message will be sent to you when the file has been processed, but nothing else. MSGAck indicates that you are interested in the statistics report contained in the acknowled- gement but want it sent to you as messages rather than mail. It is pro- bably the best alternative for local lists (ie lists comprised of users from your local node only). REView listname <(options> LOCal Msg Countries Short NOHeader Sends you the (formatted) contents of a list. Private lists cannot be reviewed by users who do not appear on it. However, the header of the list (without any information about the subscribers) will still be sent to you even if you are not authorized to review the list, as long as you would qualify to obtain this header by means of a "List Detailed" (qqv) command. The command will be automatically propagated to all the linked servers, if any, so that you get the complete list of all the persons who are subcribed to the list, not just the local subcription. For a descrip- tion of the keywords defined in the list header, please issue an "Info KEYwords" command to LISTEARN. If the list is a "centralized" one, ie a list without any peer, the output of the REVIEW command will have a fileid of "listname LIST". If the list is found to have one or more peers, the file will be sent as "listname nodeid" so that a different fileid is generated for each peer list. This will make it easier to keep a copy of the list on your disk. The "LOCal" option indicates that you want only the list of subscribers served by the local LISTEARN and that the command should therefore not be propagated to the peer servers. The "Msg" option causes the command output to be sent to you via inter- active messages, unless it is larger than 30 lines. The "Countries" option indicates that you want a summary of the number of subscribers in each country, sorted by country name. The "Short" options causes the list of subscribers not to be sent to you: only the list header and possible country summary is sent out. "NOHeader" is the counterpart of "Short" and suppresses the list header but not the country summary nor the list of subscribers. Specifying both "NOHeader" and "Short" is valid and will display only the number of persons subscribed to the list, and possibly the country summary. STats listname <(LOCal> Sends you the statistics report for the desired list. Note that statis- tics may have been disabled for the list, or may not be available to everybody. The report will indicate the total number of mailing opera- tions, the number on (non-local) outbound mail files, the number of (non-local) outbound 80-lines records and possibly the resulting net- work load in "link.kbytes". A link.kbyte corresponds to one kbyte of data being transferred across one link, 512 bytes of data being sent over two links, etc. When this measurement is enabled, the server will compute the distance between itself and all the recipients of the mai- ling operation and compute the exact "link.kbyte" amount. Since this operation takes a relatively important amount of CPU time and requires relatively large data files, it may have been disabled by the postmas- ter in some cases. The "LOCal" option indicates that the command is not to be forwarded to the peer servers linked to the list. The default is to propagate the command to all the servers housing a peer copy of the list. GET fn ft SENDME Sends you the requested file provided you are authorized to retrieve it. A more detailed description of this command, including information about the optional "filelist_name" operand and the general structure of the FILELISTs can be found in LISTFILE MEMO (send an "Info FILE" com- mand to obtain it). Synonyms have been defined for the GETND, GETDD, GETPP and GET80 com- mands of Netserv. "GETND xxxx" is translated to "GET xxxx F=Netdata", etc. Note that in this implementation, GETPP and GET80 are strictly equivalents and will cause the file to be sent in LISTEARN-Punch format if its logical record length is greater than 80. Send an "Info LPUNch" command to LISTEARN for more information about LISTEARN-Punch format. >Note that the Netserv "prologtext" feature is NOT yet supported on the >GET command. INDex Sends you the specified filelist (defaults to LISTEARN FILELIST). This command is strictly equivalent to "GET filelist_name FILELIST" and has been made available for compatibility with other file servers on the network. PW ADD new_password CHange old_password new_password DELete old_password This command allows you to define yourself a password for use with LIST SERV, change that password, or delete it if you no longer need it. Note that the PW ADD function may have been disabled or restricted to a cer- tain category of people by the local LISTEARN management. Please con- tact the local LISTEARN management, not the author, if you find youself unable to use the PW ADD and think you ought to be able to use it. A more detailed description of this command and the use of passwords in LISTEARN can be found in LISTAFD MEMO (which you can obtain by means of an "Info AFD" command). AFD ADD filename filetype PW=password FUI DELete filename filetype PW=password GET filename filetype List Query This command allows you to subscribe to a file or package which you are normally authorized to retrieve from the server by means of a GET com- mand (qqv). AFD/FUI DELete will remove your subscription to one or more files/packages (wildcard characters are accepted), while AFD/FUI List or Query will list the files/packages to which you have subscribed. The GET option allows file owners to request a list of people who have sub- scribed to their files. AFD refers to "Automatic File Distribution", ie automatic shipment of the updated file, while FUI refers to "File Update Information", that is notification of the update without the new file being automatically shipped to you. There are two different commands, FUI and AFD, with a (nearly) identical syntax, and two independent lists, one for FUI and one for AFD. A more detailed description of this command and the use of passwords in LISTEARN can be found in LISTAFD MEMO (which you can obtain by means of an "Info AFD" command). Note that the Netserv "prologtext" feature is supported on the AFD command. See LISTAFD MEMO for more information. PUT filename >> <"parameters"> This command allows file owners to store a file in the server. The default filetype is "LIST" and causes a normal list-storing operation to be performed (this can be useful for list owners whose networking system does not allow them to send the file with a spool filetype of "LIST"). Note that the spool fileid is completely ignored by the PUT command. "NODIST" indicates the file should not be distributed to the other servers (in case the file is not a local one). The optional para- meters may be required for files which receive special handling -- con- tact the local LISTEARN operation staff if you have any doubt on this. A more detailed description of this command can be found in LISTFILE MEMO, which you can obtain by means of an "Info FILE" command. RELEASE Sends you information messages containing the release number of the server and the names and network addresses of the server's postmasters. This is the same information that you obtain from a HELP command, but without the help information itself. > Servers which have not yet installed version 1.4 or better of LISTEARN > will not understand that command. SERVE userid@node Returns service to a disabled user. To prevent loops and 'message wars' to occur, LISTEARN will automatically "disable" a user after receiving 10 invalid commands from him. Further commands will be completely igno- red without any error message being sent back, until service is resto- red from another userid/account by means of the SERVE command. DISTribute < > > A complete description of the DISTRIBUTE command can be found in LIST DIST MEMO, which can be obtained from LISTEARN by sending it an "INFO DIST" command. ********************************************************** * Command keywords: why, when, and where to specify them * ********************************************************** Command keywords provide a means whereby some command-independent information can be passed to the LISTEARN "supervisor" in a standard way. Command keywords will be accepted on ANY LISTEARN command and they will always be processed the same way; however, there will be commands for which some or all of the accepted control keywords are irrelevant. Only relevant keywords are listed in the commands description (see above). All command keywords can be specified anywhere in the command-text, AFTER the command name itself. They can appear at the end, in the mid- dle of the arguments of before the command arguments. A command keyword is an expression of the form: " keywordname=keywordvalue " (the double- quotes are not part of the keyword expression). The blank before the keyword name is mandatory, while there must be NO blank between the keyword name and the equal sign. There can be one or more blanks between the equal sign and the keyword value. The reason for these res- trictions is to avoid "finding keywords where none was intended". Valid examples: "REV F=Netdata CHAT-L (Countries" "REV CHAT-L F= Netdata (Countries" "REV CHAT-L (Countries F= Netdata" Examples of improperly specified keywords: "F=Netdata REV CHAT-L" (keyword must appear after command name) "REV CHAT-L F = Netdata" (blank between "F" and the equal sign) "REV CHAT-LF=Netdata" (missing blank before keyword name) ********************************************* * Description of available command keywords * ********************************************* Unrecognized keywords will be left unhampered in the command line, ie you can use equal signs in command arguments without problem. Since key words are processed before the command itself is analyzed, specifying an improper value for a keyword will cause the command to be terminated immediately without any further checking. F= Netdata | Disk | Card | Punch | * This keyword controls the "format" in which files will (possibly) be sent to you. The default value, ie the value taken if the keyword is omitted, is "*", which instructs LISTEARN to use the default file for- mat defined by your system administrator in the BITEARN NODES database. This format will (hopefully) be the most efficient format that your operating system is able to handle. However, if this default format is incorrect or if for some other reason you want files to be sent to you in another format, you can specify a "F=" keyword to override the default specification. Only the first letter of the format needs be given. "Punch" format is automatically changed to "LISTEARN-Punch" if the file being sent to you is larger than a card image (80 characters). PW= password This keyword provides a means whereby a "password" can be specified on a LISTEARN command. The password to be given will be different depen- ding on the category of command (list-maintenance, server-operation, server-maintenance) and will be processed accordingly. Generally spea- king, the command will be rejected or only partially honored if the password is incorrect. General user commands will never require any password, and thus the "PW=" keyword is irrelevant for general users. From "Don Hosek " Thu Jul 26 15:46:05 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Thu 26 Jul 90 15:40:44-MDT Date: Thu, 26 Jul 1990 14:39 PDT From: Don Hosek Subject: FWD: Request for Information on TeX/LaTeX Utility Programs To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive From: anita@sun.udel.edu (Anita Marie Hoover) Newsgroups: comp.text.tex Subject: Request for Information on TeX/LaTeX Utility Programs Keywords: TeX/LaTeX Utility Programs Message-ID: <12947@sun.udel.edu> Date: 26 Jul 90 15:06:24 GMT Organization: University of Delaware Lines: 44 ***************************************************************** Request for Information ***************************************************************** As a result of the presentation given by David Ness at the recent TUG meeting on utility programs for aiding TeX Users, there has been an interest to try to put together an article for TUGboat that lists existing utility programs and where you can get them. We are asking for people to please provide as much information about particular utility programs you use. Please use the following format for responding: Example 1: Program Name : s2latex Author : Van Jacobson of Lawrence Berkeley Laboratory Language : C and Lex Operating System : UNIX Description : convert Scribe input files to TeX/LaTeX input files Where did you get it? : science.utah.edu Example 2: Program Name : detex Author : Kamal Al-Yahya, Stanford University Language : C Operating System : UNIX Description : a filter to strip TeX and LaTeX's commands from a file Where did you get it? : I don't know originally, but you can get a copy from me by mailing to anita@vax1.udel.edu ***************************************************************** Please send responses to anita@vax1.udel.edu. thanks in advance, Anita Hoover University of Delaware From "bbeeton " Fri Jul 27 07:11:15 1990 Flags: 000000000001 Return-Path: Received: from MATH.AMS.COM ([130.44.1.5]) by SCIENCE.UTAH.EDU with TCP; Fri 27 Jul 90 07:11:13-MDT Date: Fri 27 Jul 90 09:17:18-EST From: bbeeton Subject: recent message to tex-archive and tex-implementors To: dhosek@hmcvax.claremont.edu, beebe@science.utah.edu Message-ID: <649084638.0.BNB@MATH.AMS.COM> Mail-System-Version: i've just added a couple of new names to the tex-implementors list, and assured them (they asked) that there would be no overlap of messages between tex-archive and tex-implementors. (i believe they have quite different functions, and the folks who want to be on both, i think already are.) so, i'd like to ask that messages to tex-archive not be sent also to tex-implementors. thanks. -- bb ------- From "Nelson H. F. Beebe " Fri Jul 27 10:35:34 1990 Flags: 000000000001 Mail-From: BEEBE created at 27-Jul-90 10:29:54 Date: Fri 27 Jul 90 10:29:54-MDT From: "Nelson H. F. Beebe" Subject: New: Astronomy journal BibTeX support To: tex-archive@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12609044462.45.BEEBE@SCIENCE.utah.edu> The new directory aps: on science.utah.edu contains BibTeX support for astronomy journals. There are two example LaTeX files, a BibTeX style file, and a file mnemonic.bib, which says: % This is MNEMONIC.BIB, a bibliography database file that provides mnemonics % for journal names, which can be used in the `journal' field of bibliography % entries in databases for BibTeX. % The abbreviations of the journal names in this file follow the rules of % the International List of Periodical Title Word Abbreviations. % From: Astronomy and Astrophysics Abstracts, 1990, Vol. 49A There are 419 standard journal abbrevs in this file. Here is the 00README.TXT file: >>... >> : 00README.TXT.1, 26-Jul-90 17:54:07, Edit by BEEBE >> >> This directory contains a BibTeX 0.99c style file for >> astronomical journals, plus test files, described in the >> READ.ME file. >> >> The files were retrieved from SARASERV%HASARA11.BITNET@CUNYVM.CUNY.EDU >> on [26-Jul-1990] by a message of the form >> >> get READ ME >> get ASTRON BST >> get ASTRON STY >> get ASTDOC TEX >> get ASTDOC AUX >> get ASTDOC TOC >> get ASTDOC BBL >> get ASTDOC BIB >> get EXAMPLE TEX >> get EXAMPLE BIB >> get MNEMONIC BIB >> get TEMPLATE BIB >> >> and then unpacked; those that arrived in LISTSERV punch >> format where converted to text files by the puntxt.c program >> written for the occasion. The .aux, .bbl, and .toc files >> have been regenerated by rerunning LaTeX and BibTeX. >> [the end] ------- From "Piet van Oostrum " Tue Jul 31 13:22:33 1990 Flags: 000000000001 Return-Path: <@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from ruuinf.cs.ruu.nl by science.utah.edu with TCP; Tue 31 Jul 90 13:13:56-MDT Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA11380; Tue, 31 Jul 90 21:16:55 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA10306; Tue, 31 Jul 90 21:17:49 met Date: Tue, 31 Jul 90 21:17:49 met From: Piet van Oostrum Message-Id: <9007311917.AA10306@praxis.cs.ruu.nl> To: tex-archive@science.utah.edu Subject: archive at cs.ruu.nl Here is a brief description of our archive of TeX stuff. The archive is available by FTP and by mail server. It contains various things, a.o. Atari ST software, GNU software, some Unix software and a lot of TeX things. I will concentrate on the TeX stuff in this message. How to get the software: ------------------------ By FTP: FTP sol.cs.ruu.nl [131.211.80.5], the main directory is pub. Note that this is a Unix system, so a file in a directory is accessed as dir/subdir/file. By mail server: Send a message to mail-server@cs.ruu.nl with any of the following commands: BEGIN ----- Begin processing. All commands and errors before this command are forgotten. Use this if your mailer inserts garbage. PATH
-------------- The return address used by the server is set to the indicated
. This must be a valid address by which you can be reached. It may contain a domain-based address. Use this command if you are not sure that the return addresses generated by your mail system are reliable. END or EXIT ----------- The remainder of the message is ignored. This can be useful if a .signature is appended to the message. LIMIT -------------- Specify the maximum number of bytes which may be sent in a single mail message. Transfers exceeding this amount will be split before sending. The amount may be specified in Kbytes, e.g. "30K". The default value is 64K. NOTE: setting the limit will only affect "send" and "resend" commands following this command. NOTE: due to mailer overhead, it is possible that the size of the mail which reaches you will (slightly) exceed this limit. UUENCODE -------- The requested items will be uuencoded before sending. Because most archives are binary files, they are always encoded before sending. Uuencoding is default. Use "send uudecode" to obtain the uudecode/uuencode programs. NOTE: setting the encoding will only affect "send" and "resend" commands following this command. BTOA ---- The requested files will be encoded using "btoa". Btoa encoded files are smaller than uuencoded files, but not everyone can handle btoa encoded files yet. Use "send btoa" to obtain the btoa/atob coding programs. NOTE: setting the encoding will only affect "send" and "resend" commands following this command. SEND ----------- The specified is looked up in the server archives. If found, it will be sent to you by e-mail. Multiple items may be specified with one SEND command. If is a directory, a listing of the directory will be sent, rather than the directory itself. NOTE: the names of the s are case sentive! On Unix a file within a directory is given as dir/file. RESEND [...] -------------------------------- Re-send the indicated s of this item. This is useful if not all parts of a multi-parts transmission did arrive correctly. When re-transmitting, the encoding and limit used must be identical to those of the original transmission. INDEX ----- This is equivalent to "send INDEX". HELP ---- This command gives a list of server commands. TEST ---- This command is for testing. No files will be sent if you use this, but a confirmation message will be sent to the return path as determined from the mail headers or the "path" command. You may use this to find out if your address is valid, and to check the status of your request. Sometimes the mail server is unable to reply to a person. We will recognize any internet address with a valid MX record. If you don't get a reply within a few days, try a TEST message with a PATH command. There are a few known reasons why an address is not recognised: Your mailer inserts a wrong from address. E.g. an internet style address while using a non-registered domain. In this case let your management register a proper internet domain. Or a hostname without an MX record. In this case you mignt use a different host name that knows about you. UUCP sites might try the following syntax: user@host.uucp or host!user BITNET users may try user@host.bitnet. Some mailers give user@host as from address which is bound to fail. If you are reachable from a known internet site (e.g. a.b.c), you may try user%host@a.b.c For example if you are a UUCP site connected to uunet, the following might work: user@host.uucp or uunet.uu.net!host!user or user%host@uunet.uu.net or a so called source route address <@uunet.uu.net,@host1,@host2:user@host> Never mix ! and @ style addresses, this is guaranteed to give problems. What is in the archive? ----------------------- The following subdirectories and files are available: ATARI-ST - A lot of public domain Atari 1040ST software (games, compilers, utilities, ...). Most of it retrieved from the UseNet distributions. DOC - Various documentation; among others Internet worm reports, a BSD socket programmer's primer. ELM-2.3 - The famous Elm Mail User Agent, version 2.3. The entire package and the PostScript documentation of course. FTP-LIST - a set of files, maintained by Jon Granrose, containing information about anonymous FTP sites worldwide. GNU - Various (up to date) software from the GNU project. HP-UX - Software that will most likely run under HP-UX 6.5 and what's also a good start for other System V alikes. See INDEX file in this directory for more information. NN-6.4 - Kim Storm's famous news reader, version 6.4. Contains the official release as well as official patches. TEX - (La)TeX software as well as the TeXhax and TeXmag articles. Also the *entire* TeX distribution tape. UNIX - Various UNIX software, easy-to-run on BSD systems as well as System V systems (with BSD enhancements). See the INDEX file in this directory for more information. ls-lR.Z - A "ls -lR" listing of the entire archive. Most directories contain a file INDEX with a brief description of the contents. The TEX subdirectory contains back issues of TeXhax, TeXmag, UKTeX, the TeX3.0 distribution from labrea, a copy of the latexstyle and bibtexstyle archives from clarkson, a number of DVI drivers (this collection will grow in the future), utilities like bibtex and makeindex, the files from Mittelbach and Schoepf (in the latexstyle directory). This is the INDEX file in the TEX subdirectory. For information contact Piet van Oostrum drwxr-xr-x 2 piet staff 1024 Jun 5 11:11 DVI -rw-r--r-- 1 piet archive 2854 Jun 14 17:59 INDEX -rw-r--r-- 1 piet staff 37155 Feb 25 20:36 MuTeX_doc.tar.Z drwxr-xr-x 2 piet staff 1024 May 23 16:05 NTG drwxr-xr-x 3 piet staff 1024 Jul 3 12:58 TEX3.0 drwxr-xr-x 2 piet staff 1024 May 14 10:07 bibtexstyle -rwxr--r-- 1 piet staff 76278 Dec 8 1989 diagram.tex -rwxr--r-- 1 piet staff 39944 Dec 8 1989 diagramdoc.tex lrwxr-xr-x 1 piet staff 16 May 14 13:42 dvi2ps.tar.Z -> DVI/dvi2ps.tar.Z lrwxr-xr-x 1 piet staff 16 May 14 13:42 dvi2tty.shar -> DVI/dvi2tty.shar lrwxr-xr-x 1 piet staff 16 May 14 13:42 dvi3ps.tar.Z -> DVI/dvi3ps.tar.Z -rw-r--r-- 1 piet staff 13018 Apr 5 12:01 edmac.doc -rw-r--r-- 1 piet staff 34321 Apr 5 12:01 edmac.tex drwxr-xr-x 2 piet staff 1024 Jun 7 10:57 fonts -r--r--r-- 1 henkp archive 30763 Jun 15 12:22 hyphen.dutch.Z drwxr-xr-x 4 piet staff 4096 Jun 12 16:41 latexstyle -rwxr--r-- 1 piet staff 390017 Jun 14 10:45 makeidx.zoo -rw-r--r-- 1 piet staff 97113 Apr 2 16:51 mtex.tar.Z -rwxr--r-- 1 piet staff 93579 Dec 13 1989 mtexfonts.tar.Z -rw-r--r-- 1 piet staff 401659 Jan 22 16:33 spiderweb.tar.Z drwxr-xr-x 7 piet archive 1024 Jan 20 10:49 texhax drwxr-xr-x 6 piet archive 1024 Jan 9 13:16 texmag drwxr-xr-x 2 piet staff 2048 Jun 10 08:41 tugboat drwxr-xr-x 2 piet staff 2048 Jun 10 08:43 uktex -rw-r--r-- 1 piet staff 70425 Apr 10 18:08 wp2latex.arc INDEX - This file DVI - directory with various dvi convertors NTG - directory with submissions from NTG (Dutch users group) TEX3.0 - The distribution files for TEX3.0 bibtexstyle - bibtex style files from clarkson diagram.tex - Macros for commutative diagrams (from Francis Borceux) diagramdoc.tex - Documentation for the above fonts - fonts and utilities for metafont hyphen.dutch.Z - Dutch hyphenation patterns (compressed) latexstyle - a copy of the latex-style directory at clarkson.edu makeidx.zoo - The famous makeindex program (sources) version 2.9 mtex.tar.Z - tex macros and metafont files for music typesetting, includes English manual MuTeX_doc.tar.Z - Manual only from the above mtexfonts.tar.Z - tfm files and 300dpi PK files for the above (not necessary if you have metafont) spiderweb.tar.Z - a WEB system for other programming languages than Pascal texhax - back copies of texhax magazine (texhax/19xx/yyy) A list of subjects per year is in texhax/19xx/Subjects. Some years have an index in texhax/19xx/INDEX. texmag - back copies of texmag magazine (texmag/19xx/yyy) tugboat - a copy of the tugboat directory at labrea.stanford.edu wp2latex.arc - an MSDOS program to convert Wordperfect 5.0 files to LaTeX -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') From "Don Hosek " Tue Jul 31 22:23:56 1990 Flags: 000000000001 Return-Path: Received: from ARGON.CLAREMONT.EDU by science.utah.edu with TCP; Tue 31 Jul 90 22:23:53-MDT Date: Tue, 31 Jul 1990 21:22 PDT From: Don Hosek Subject: TeX-archive list To: isaac@goanna.cs.rmit.oz.au, beebe@science.utah.edu Message-id: X-Envelope-to: beebe@science.utah.edu X-VMS-To: in%"isaac@goanna.cs.rmit.oz.au" X-VMS-Cc: nelson_beebe There is a TeX archive list run at science.utah.edu on which all sorts of archive management issues are discussed for those managing TeX-related archives. If you like we can have you added to the list. -dh From isaac@goanna.cs.rmit.OZ.AU Tue Jul 31 22:27:28 1990 Flags: 000000000011 Return-Path: Received: from goanna.cs.rmit.oz.au by science.utah.edu with TCP; Tue 31 Jul 90 22:27:22-MDT Received: from localhost by goanna.cs.rmit.oz.au with SMTP. (5.61+++) id AA06252; Wed, 1 Aug 90 14:30:38 +1000 Message-Id: <9008010430.6252@goanna.cs.rmit.oz.au> To: Don Hosek Cc: beebe@science.utah.edu Subject: Re: TeX-archive list Date: Wed, 01 Aug 90 14:30:35 +1000 From: isaac@goanna.cs.rmit.OZ.AU | | | There is a TeX archive list run at science.utah.edu on which all sorts | of archive management issues are discussed for those managing | TeX-related archives. If you like we can have you added to the list. | Okay then, could you add tex@goanna.cs.rmit.oz.au to the list? Thanks. From "Karl Berry " Tue Jul 31 22:37:23 1990 Flags: 000000000001 Return-Path: <@RELAY.CS.NET:karl@aten.umb.edu> Received: from RELAY.CS.NET by science.utah.edu with TCP; Tue 31 Jul 90 22:31:36-MDT Received: from relay2.cs.net by RELAY.CS.NET id aa12695; 1 Aug 90 0:36 EDT Received: from umb.edu by RELAY.CS.NET id ab07038; 1 Aug 90 0:25 EDT Received: by umb.umb.edu (5.51/5.17) id AA03514; Tue, 31 Jul 90 14:47:58 EDT Received: by aten.cs.umb.edu (3.2/5.17) id AA06776; Tue, 31 Jul 90 14:47:53 EDT Date: Tue, 31 Jul 90 14:47:53 EDT From: Karl Berry Message-Id: <9007311847.AA06776@aten.cs.umb.edu> To: tex-archive@SCIENCE.UTAH.EDU Subject: font names yet again I don't know if my last message made it out, but anyway. In preparing the PostScript fonts, I found that things would be nicer if the font names end with weight-shape-expansion instead of weight-expansion-shape, because the expansion is so often ``normal''. If there are no problems with this, perhaps I will write a brief note to TUGboat about this. ::= FTTWSEDD where F = foundry TT = typeface family W = weight S = shape/variation (omitted when normal and expansion is normal) E = expansion (omitted when normal) DD = design size (omitted for scaled fonts) foundry: a = Autologic b = Bitstream c = Compugraphic g = Free Software Foundation (i.e., GNU) h = Bigelow&Holmes (with apologies to Chuck) i = ITC p = Adobe (i.e., PostScript) s = Sun typeface families: ag = Avant Garde ao = Antique Olive at = American Typewriter bb = Bembo bd = Bodoni bg = Benguiat bk = Bookman bv = Baskerville bw = Broadway cb = Cooper Black cr = Courier cs = Century Schoolbook hv = Helvetica gm = Garamond gs = Gill Sans lc = Lucida nc = New Century Schoolbook op = Optima pl = Palatino rw = Rockwell tm = Times un = Univers uy = University zc = Zapf Chancery special: symbol = PostScript Symbol zdingbt = Zapf Dingbats weight: (hairline thin extra light light book regular medium demibold semi bold extra bold heavy black ultra) a = hairline b = bold c = black d = demi h = heavy i = extra light k = book l = light m = medium o = extra bold r = regular s = semi t = thin u = ultra shape/variation: r = normal (roman) (omitted when the expansion is normal, also) b = bright c = small caps h = shadow i = (text) italic l = outline o = oblique \equiv slanted s = sans serif t = typewriter u = unslanted italic expansion: (extra condensed condensed narrow extended expanded wide) c = condensed (by hand) e = expanded (automatic) n = narrow (automatic) o = extra condensed regular (normal, medium) (always omitted) w = wide x = extended (by hand) Univers translation table: 45 = light (unl) 46 = light italic (unli) 47 = light condensed (unlrc) 48 = light condensed italic (unlic) 49 = light extra condensed (unlro) 53 = medium extended (unmrx) 55 = medium (unm) 56 = medium italic (unmi) 57 = medium condensed (unmrc) 58 = medium condensed italic (unmic) 59 = medium extra condensed (unmro) 63 = demibold extended (undrx) 65 = demibold (und) 66 = demibold italic (undi) 67 = demibold condensed (undrc) 68 = demibold condensed italic (undic) 73 = bold extended (unbrx) 75 = bold (unb) 76 = bold italic (unbi) 83 = extra bold extended (unorx) From "bbeeton " Wed Aug 1 02:53:22 1990 Flags: 000000000001 Return-Path: Received: from VAX01.AMS.COM by science.utah.edu with TCP; Wed 1 Aug 90 02:53:20-MDT Date: Wed 1 Aug 90 04:55:02-EST From: bbeeton Subject: info on tex mailing lists To: beebe@science.utah.edu Message-ID: <649500902.0.BNB@MATH.AMS.COM> Mail-System-Version: here is some information for your collection. the following isn't complete -- i know that don hosek has one more list that he's established, and i think i heard that the nordic group has a list -- but these are the ones that i or someone else here at ams is on. as i'm a congenital pack rat, i've archived them all (after some editing for header compression, and for the unmoderated lists, organization), and believe that the collections are pretty complete. TeX help lines -- electronic exchanges LaTeX-help@cs.stanford.edu (new address as of 30 July 90) not a bulletin board or distribution list, but a cooperative venture founded by Max Hailperin and now managed by Ed Sznyter; questions sent to this address are distributed round-robin to volunteers who answer the questioner personally; there may be some "canned" answers emerging for frequently-asked questions, and these may be offered to TUGboat GUT@FRULM11.BITNET non-moderated, non-digested mailing list sponsored by GUTenberg and resident at l'Ecole Normale Superieure de la rue d'Ulm; in French TeX-D-L@DEARN.BITNET, TeX-D-PC@DEARN.BITNET non-moderated, non-digested mailing lists sponsored by DANTE and resident at Univ of Heidelberg; in German (there is also a private DANTE list) TeX-NL@HEARN.BITNET non-moderated, non-digested mailing list sponsored by NTG; in Dutch IVRITEX@TAUNIVM.BITNET Hebrew TeX list established by Don Hosek; non-moderated, non-digested TeX-ED@UICVM.uic.edu TeX Education Forum list established by Yin Kean; non-moderated, non-digested ancillary lists begun as spin-offs from TeX-specific lists Laser-lovers@cs.umd.edu established by Rick Furuta; moderated, non-digested SUEARN-L@UBVM.BITNET Soviet Union to EARN Connections Technical Discussion recently split off from RUSTEX-L; established by Dimitri Vulis; non-moderated, non-digested; probably of marginal interest to most of the TeX community "private" lists: (all non-moderated, non-digested) DRIV-L@TAMVM1.BITNET TUG DVI driver standards discussion list established by Don Hosek LaTeX-L@DHDURZ1.BITNET established by Rainer Schoepf TeX-archive@science.utah.edu TeX Archive Site Maintainers mailing list established by Nelson Beebe TeX-CHAR@DHDURZ1.BITNET TeX-Character-Set Mailing list established by Joachim Lammarsch TeX-implementors@math.ams.com TeX implementors mailing list established by Barbara Beeton ------- From AHLQUIST@METSAT.MET.FSU.EDU Thu Aug 2 18:19:09 1990 Flags: 000000000001 Return-Path: Received: from METSAT.MET.FSU.EDU by science.utah.edu with TCP; Thu 2 Aug 90 18:19:00-MDT Date: Wed, 1 Aug 1990 20:27:27 EDT From: AHLQUIST@METSAT.MET.FSU.EDU Message-Id: <900801202727.8fb@METSAT.MET.FSU.EDU> Subject: TEX font metrics for MS-DOS To: Beebe@science.Utah.EDU X-Vmsmail-To: SMTP%"Beebe@science.Utah.EDU" 1) I am looking for TeX font metric files for MS-DOS that match the many "*.tfm" files on labrea.stanford.edu. Are such available from any FTP site that you know? 2) Here at Florida State University, we are nearly ready to set up an "anonymous FTP" account on which public domain TeX packages for MS-DOS and Macintosh will be available. The Macintosh package will be OzTeX, and the MS-DOS package will be Wayne Sullivan's SB-TeX with your printer drivers. I have written "overview" and installation documentation for the MS-DOS package. 3) Attached is an augmented version of bintnx.c, which I modified to run on my microcomputer. It allows the user to specify the input and output file names. It may be used by anyone who wishes. Quite possibly, some of the documentation at the beginning needs to be revised. Thank you. - Jon Jon Ahlquist, Dept. of Meteorology, Florida State University ahlquist@metsat.met.fsu.edu ---------------- CUT HERE --------------------- /* bintnx.c Suppose you want to "get" a binary file over Internet via FTP >From a computer running the TOPS-20 operating system, such as science.utah.edu or wsmr-simtel20.army.mil. These computers have 36 bit words. The preferable way to get such a file is with the FTP commands tenex get file_name where file_name is the name of the file you want. Unfortunately, not all FTP software recognizes the "tenex" command. If yours does not, try type l 8 (that is, type lower-case-L 8) or quote type l 8 or quote "TYPE L 8" followed by get file_name If that still does not work, try binary get file_name Then run this C program to try to make the file usable on your computer. Here is what this program does. Out of each 36 bits in the input file, it writes out the first 32 bits "as is" and throws away the next 4 bits. So 9 bytes of input become 8 bytes of output. Warning: Some FTP software does not correctly capture a file in "binary" mode from a TOPS-20 computer. (The FTP software I had dropped bytes here and there.) Although bintnx.c functions as documented, it connot restore dropped bits, so look hard to find a local computer that offers "tenex" mode before you are forced to use "binary" mode followed by an attempt to straighten things out with this program. This program tests for end of file on input, but not on output. The original version of this program, dated 08-Oct-87 and written by an unnamed programmer, can be found on both science.utah.edu and wsmr-simtel20.army.mil. Those servers also have a version specifically for VAX/VMS. Program revised and documented by Jon Ahlquist, 30 May 1990. */ #include /* exit() */ #include /* getc(), printf(), putc() */ #include /* strnicmp() */ void main(int argc, char *argv[]) { register unsigned char c, d, i; FILE *fp_in, *fp_out; /****** Print help information if no command line arguments were specified. ******/ if (argc < 3) { printf("This program tries to recover a binary file transferred via FTP\n"); printf("from a TOPS-20 computer using 'binary' instead of 'tenex' mode.\n"); printf("It discards 4 bits after each 32 bits in the input file.\n"); printf("To invoke this program, enter:\n"); printf("bintnx filein fileout\n"); printf("where filein and fileout are the names\n"); printf("of the separate input and output files.\n"); exit(0); } /****** Open the input and output files. ******/ if((fp_in = fopen(argv[1], "rb")) == NULL) { printf("Unable to open input file.\n"); exit(0); } if (strnicmp(argv[1], argv[2], 80) == 0) { printf("The input and output files must be different.\n"); exit(0); } if((fp_out = fopen(argv[2], "wb")) == NULL) { printf("Unable to open output file.\n"); exit(0); } /****** Create a usable output file from the input file. ******/ while(1) { /* The first 4 bytes come in and go straight out. */ for (i=0; i<4; i++) { c = fgetc(fp_in); if (feof(fp_in) != 0) break; fputc(c, fp_out); } /* We discard the next 4 bits. Getting the next 32 bits after that requires repacking. */ d = fgetc(fp_in); if (feof(fp_in) != 0) break; for (i=0; i<4; i++) { c = (d << 4); d = fgetc(fp_in); if (feof(fp_in) != 0) break; c |= (d >> 4); fputc(c, fp_out); } } fclose(fp_in); fclose(fp_out); printf("\n\nDone.\n"); } /* End main. */ From "Don Hosek " Fri Aug 3 00:11:42 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Fri 3 Aug 90 00:03:59-MDT Date: Thu, 2 Aug 1990 23:03 PDT From: Don Hosek Subject: MTeX now available from ymir.claremont.edu To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive The MTeX/MuTeX music typesetting package is now available from ymir.claremont.edu in the directory [anonymous.tex.music.mtex]; the 00readme.txt for that directory follows: This directory contains the MTeX macros and fonts and the MuTeX extensions to them. This is a package for typesetting single-staff music (with optional lyrics). It should work with either plain TeX or LaTeX. 00readme.txt This file. guide.tex MuTeX users manual. Explains how to install and use the package. (Written by Fran\c{c}ois Jalbert; formatted with LaTeX) mtex.tex The MTeX macro package mplain.tex File for creating a plain TeX with MTeX macros preloaded mtexdemo.tex Demo of MTeX (calls two following files) bach.tex Sample file (by J.S. Bach) distler.tex Sample file (by H. Distler) mtexinfo.tex Original documentation (in German) acc16.mf MF source for the fonts beam16.mf music16.mf noten16.mf pause16.mf slur16.mf slurdd16.mf slurdu16.mf slurud16.mf sluruu16.mf sonder16.mf vio16.mf musicdef.mf All but this file are top-level input files. From "Don Hosek " Fri Aug 3 01:22:33 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Fri 3 Aug 90 01:15:40-MDT Date: Fri, 3 Aug 1990 00:15 PDT From: Don Hosek Subject: Computer Duerer fonts now available from ymir.claremont.edu To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive Alan Hoenig's Computer Duerer fonts have been installed on ymir.claremont.edu in the directory [anonymous.tex.mf.duerer]. The 00readme.txt file from that directory follows: This directory contains the "Computer Duerer" fonts designed by Alan Hoenig (see the 1990 TUG Conference Proceedings for a full background on this). The version here is for use as titling only and consists of the uppercase letters A-Z. 00readme.txt This file cdb10.mf Computer Duerer Boldface cdi10.mf Computer Duerer "Informal" (modeled in part, after Stone Informal) This font does not generate properly at resolutions under ~400dpi. cdr10.mf Computer Duerer Roman cdsl10.mf Computer Duerer Slanted cdss10.mf Computer Duerer Sans Serif cdtt10.mf Computer Duerer Typewriter Type dromani.mf Low level MF files for the Computer dromanu.mf Duerer fonts dtitle.mf From "Don Hosek " Wed Aug 8 22:12:12 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Wed 8 Aug 90 22:07:13-MDT Date: Wed, 8 Aug 1990 21:06 PDT From: Don Hosek Subject: DVICOPY available from ymir.claremont.edu To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive DVIcopy is now available from ymir.claremont.edu in the directory [anonymous.tex.utilities.dvicopy] This is a utility (like Wayne Sullivan's DVF) for converting a DVI file referencing VF fonts into a DVI file which does not contain such references. It is written in WEB. No change files are currently available, but change files for CMS, VMS, WEB2C and MS-DOS are in the works. -dh From "Don Hosek " Tue Aug 14 01:29:29 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Tue 14 Aug 90 01:24:02-MDT Date: Tue, 14 Aug 1990 00:24 PDT From: Don Hosek Subject: german.sty To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: in%"tex-archive@science.utah.edu" A new version of german.sty by H. Partl is now available from ymir.claremont.edu in [anonymous.tex.babel.german] Thanks to Rainer Schoepf for supplying this file. -dh From "Network Mailer " Wed Aug 15 09:30:23 1990 Flags: 000000000001 Return-Path: Received: from CC.UTAH.EDU by science.utah.edu with TCP; Wed 15 Aug 90 09:29:40-MDT Received: from MAILGATE.DBIUNI19 by CC.UTAH.EDU; Wed, 15 Aug 90 09:35 MDT Received: by DBIUNI19 (Mailer R2.07) id 0159; Wed, 15 Aug 90 15:57:00 SET Date: Wed, 15 Aug 90 15:56:57 SET From: Network Mailer Subject: Undelivered mail To: Beebe@science.utah.EDU Message-id: <4C659B90F83F800125@CC.UTAH.EDU> X-Envelope-to: Beebe@science.utah.EDU Your mail was not delivered to some or all of its intended recipients for the following reason(s): No recipients for this node. --------------------RETURNED MAIL FILE-------------------- Received: from MITVMA(MAILER) by DBIUNI19 (Mailer R2.07) id 0158; Wed, 15 Aug 90 15:56:58 SET Received: from MITVMA by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 6037; Wed, 15 Aug 90 09:56:55 EDT Received: from science.utah.edu by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with TCP; Wed, 15 Aug 90 09:56:52 EDT Date: Wed 15 Aug 90 07:40:14-MDT From: "Nelson H. F. Beebe" Subject: Announcing web mode editing support for GNU Emacs To: tex-archive@science.utah.edu cc: Beebe@science.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12613994310.21.BEEBE@SCIENCE.utah.edu> At long last, Mark Motl's web mode for GNU Emacs has been released. Here are the details from Bart Childs: --------------- Return-Path: Received: from cssun.tamu.edu by science.utah.edu with TCP; Tue 14 Aug 90 10:38:31-MDT Received: from cs.tamu.edu (PHOTON.TAMU.EDU) by cssun.tamu.edu (AA25035); Tue, 14 Aug 90 11:40:32 CDT Date: Tue, 14 Aug 90 11:40:32 CDT From: bart@cs.tamu.edu (Bart Childs) Message-Id: <9008141640.AA25035@cssun.tamu.edu> To: ajcd%lfcs.edinburgh.ac.uk@cunyvm.cuny.edu, bd@sde.hp.com, beebe@science.utah.edu, caillat%frmeu51.earn@cunyvm.cuny.edu, damerell%ac.uk@cunyvm.cuny.edu, eho@clarity.princeton.edu, furuta@mimsy.umd.edu, krommes@LYMAN.pppl.GOV, levy@princeton.edu, mackay@june.cs.washington.edu, mebrown@ua1vm.ua.edu, nr@princeton.edu, steiner@topaz.retugers.edu, svb@integin.cs.purdue.edu Subject: New Version of web-mode.el from Texas A&M From: Bart Childs bart@cs.tamu.edu 409-845-5470 Department of Computer Science TeXas A&M University College Station, TX 77843-3112 Mark Motl motl@cs.tamu.edu soon to move to Angelo State Univ. Subject: web-mode.el for gnu-emacs A significantly improved version of Mark's web-mode for gnu-emacs is now available. Sometime today it should be available for anonymous FTP from ``csseq.tamu.edu''. A significant change is that the output of weave is used to have the same INDEX and list of MODULE NAMES. We are using this with Don Knuth's WEB, Silvio Levy's CWEB, and John Krommes FWEB. The files included in source and compressed tar are: -rw-r--r-- 1 bart 2057 Aug 14 11:05 cweave.ch -rw-r--r-- 1 bart 1824 Aug 14 11:04 fweave.ch -rw-r--r-- 1 bart 1101 Aug 14 11:06 limbo.material -rw-r--r-- 1 bart 13198 Aug 14 11:24 litprog.bib -rw-r--r-- 1 bart 21416 Aug 14 11:05 weave.ch -rw-r--r-- 1 bart 54431 Aug 14 11:04 web-mode-manual.tex -rw-r--r-- 1 bart 215220 Aug 14 11:04 web-mode.el 1) web-mode-manual.tex --- TeX source of a manual that describes web-mode. 2) web-mode.el --- Contains the source for the GNU Emacs Lisp functions to extend Emacs. 3) limbo.material --- Contains statements that commonly appear in the limbo portion of a WEB. This `limbo' code is adapted from Don Knuth's WEBs. 4) Change files for the various weaves that cause these filters to output separate files INDEX.tex and MODULE_NAMES.tex. These changes also cause these files to be input. 5) Nelson Beebe's literate programming bibliography as of July 7, 1990. It has about 40 entries. We would appreciate any constructive (and maybe destructive) criticisms you may offer on this project. We plan to make it available on a wide distribution if your input warrants it. The following list of email addresses indicates those we know of who have indicated some interest. If you know of others who would like to receive it, please distribute it to them and let us know who they are. Don Knuth is no longer using email because he is working on the Art of Computer Programming, otherwise he would be on the list. furuta@mimsy.umd.edu mackay@june.cs.washington.edu svb@integin.cs.purdue.edu beebe@science.utah.edu levy@princeton.edu nr@princeton.edu mebrown@ua1vm.ua.edu krommes@ss01.pppl.gov eho@clarity.princeton.edu bd@sde.hp.com steiner@topaz.retugers.edu wran@cgch.uucp "ajcd%lfcs.edinburgh.ac.uk"@cunyvm.cuny.edu "damerell%ac.uk"@cunyvm.cuny.edu "caillat%frmeu51.earn"@cunyvm.cuny.edu We are also building a list of webs that have been written and authors are willing to distribute. We have a dozen or so in the various webs. The list has not been checked at all and should be available by next week. Thanks Bart Childs August 14, 1990 ------- From "Don Hosek " Fri Aug 17 02:32:31 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Fri 17 Aug 90 02:25:31-MDT Date: Fri, 17 Aug 1990 01:24 PDT From: Don Hosek Subject: C version of DVItoVDU available from ymir.claremont.edu To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: TEX_ARCHIVE Dave Osbourne has supplied the C version of DVItoVDU to me and it is now available from ymir.claremont.edu in [anonymous.tex.drivers.dvitovdu_c_1] The file [anonymous.tex.drivers.dvitovdu_c_1]00readme.txt follows: This directory contains the C version of Andrew Trevorrow's DVItoVDU program. It has been compiled under both BSD and System V Unix. To extract the files, the following sequence of Unix commands is suggested: cat dvitovdu_tar_z.btoa_a? | atob | zcat > dvitovdu.tar tar -xfv dvitovdu.tar The following files are present in this directory: 00readme.txt This file. dvitovdu_tar_z.btoa_aa The C version of DVItoVDU tar'd dvitovdu_tar_z.btoa_ab compressed, btoa'd and split. dvitovdu_tar_z.bota_ac From "Don Hosek " Fri Aug 24 19:21:28 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Fri 24 Aug 90 19:18:44-MDT Date: Fri, 24 Aug 1990 18:10 PDT From: Don Hosek Subject: ymir archive group To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive The ymir.claremont.edu TeX archive is now a group effort (just like Aston). Assisting me in maintaining things are: AndrewMarc Greene (Massachusetts Institute of Technology) Viswnathan Narayanan (Syracuse University) Rodney Peck II (Rensselaer Polytechnic Institute) Jon Radel (Stanford Telecommunications) David C Royster (University of North Carolina at Charlotte) David Steiner (Rutgers University) Cynthia Rodriguez (University of Illinois at Chicago) Pat Wilcox (Ohio State University) James Wilkinson (University of California--Los Angeles) Bill Wisner (University of Alaska) Mail to the group should be addressed to tex-group@ymir.claremont.edu The exact allocation of duties &c. is still in the planning stages, but I hope to have everything stable by the end of the year. -dh From "Don Hosek " Sat Aug 25 01:33:31 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Sat 25 Aug 90 01:32:49-MDT Date: Sat, 25 Aug 1990 00:24 PDT From: Don Hosek Subject: New on ymir.claremont.edu To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive I now have two fonts for typesetting Thai, one in [anonymous.tex.babel.thai.rmit] and the other in [anonymous.tex.babel.thai.usl] The latest version of Brian Hamilton Kelly's DVI to LN03 driver is available from [anonymous.tex.drivers.ukln03]. (Copped this from the Aston archive) There is now a font of astronomical symbols in [anonymous.tex.mf.planets] (another item off of Aston) The TeX sources for issues 6-10 of TeXline are available from [anonymous.tex.periodicals.texline] in subdirectories no6 through no10. (Guess where THIS is from) We're down to 24meg free on the disk... Guess I'll have to talk the sysadmin into moving some stuff off of it. -dh From "Don Hosek " Mon Aug 27 13:09:24 1990 Flags: 000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by science.utah.edu with TCP; Mon 27 Aug 90 13:07:20-MDT Date: Mon, 27 Aug 1990 01:12 PDT From: Don Hosek Subject: Slight change to the organization of the ymir archive To: tex-archive@HMCVAX.CLAREMONT.EDU Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: TEX_ARCHIVE As I write this, a batch job is running on the local VAX installing a file 00files.txt into every directory in the TeX tree. This file will contain in it the size and last modification date of each file in its directory (created with dir/date=m/size/col=1) These files will automatically be updated whenever any file is added or changed (checking for deleted files is somewhat more complicated and I don't really want to deal with it if I can avoid doing so). -dh From "Don Hosek " Mon Aug 27 13:09:59 1990 Flags: 000000000001 Return-Path: Received: from ARGON.CLAREMONT.EDU by science.utah.edu with TCP; Mon 27 Aug 90 13:07:40-MDT Date: Mon, 27 Aug 1990 04:49 PDT From: Don Hosek Subject: PiCTeX and LaTeX To: tex-archive, wichura Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: TEX_ARCHIVE X-VMS-Cc: IN%"wichura@galton.uchicago.edu" While working on a local document, I noticed that PiCTeX as it stands does not work with the new LaTeX font selection scheme. As such, I've updated two files in the ymir.claremont.edu PiCTeX set: prepictex.tex and piclatex.sty (a concatenation of prepictex.tex, pictex.tex and postpictex.tex of indeterminate origin) to include the line \font\fiverm=cmr5 This should fix things with no appreciable cost in the old or new font selection scheme. -dh From "Karl Berry " Tue Aug 28 15:29:33 1990 Flags: 000000000001 Return-Path: <@MATH.AMS.COM,@RELAY.CS.NET:karl@aten.cs.umb.edu> Received: from MATH.AMS.COM by science.utah.edu with TCP; Tue 28 Aug 90 15:29:02-MDT Received: from RELAY.CS.NET by MATH.AMS.COM via SMTP with TCP; Tue, 28 Aug 90 17:21:55-EDT Received: from relay2.cs.net by RELAY.CS.NET id ad05445; 28 Aug 90 17:17 EDT Received: from umb.edu by RELAY.CS.NET id ao16314; 28 Aug 90 17:10 EDT Received: from aten.cs.umb.edu by cs.umb.edu (3.2/1.34) id AA24334; Tue, 28 Aug 90 10:13:15 EDT Received: by aten.cs.umb.edu (3.2/1.34) id AA22279; Tue, 28 Aug 90 10:13:00 EDT Date: Tue, 28 Aug 90 10:13:00 EDT From: Karl Berry Message-Id: <9008281413.AA22279@aten.cs.umb.edu> To: tex-implementors@MATH.AMS.COM, web2c-wizards@aten Subject: web2c 5.0e (The announcement I am sending to texhax and comp.text.tex.) You can get the following files from ics.uci.edu [128.195.1.1], in the subdirectory TeX: web2c-5.0e.tar.Z web-5.0e.tar.Z The latter file is actually different from previous versions: it includes dvicopy.web (see below). You can pick it up by itself from ymir.claremont.edu, and probably other places as well. The files will also probably be available to JANET sites with NIFTP from uk.ac.aston.tex (username public, password public), as [tex-archive]web2c-5_0e.tar_Z [tex-archive]web-5_0.tar_Z They will probably be available shortly from june.cs.washington.edu [128.95.1.4] and labrea.stanford.edu [36.8.0.47] and probably other places, too. Look for a site near you! Hints: 1) If you don't have tar and (un)compress, you have to get them. 2) I strongly suggest you get the GNU C compiler and related software from prep.ai.mit.edu, tut.cis.ohio-state.edu, or any of the other places that make GNU programs available. The number of bugs with gcc has been significantly smaller than that with system C compilers. You can also order a tape from the Free Software Foundation, 675 Mass. Ave., Cambridge, MA 02139, if you wish to support their efforts with cash. 3) If you have to make changes to any files besides site.h and Makefile, I want to know about them. Send me context diffs, and ChangeLog entries if possible. This release incorporates a number of significant changes since 5.0c (5.0d was never a general release, although many people have been using it, anyway), some of which even are visible to users: 1) You now get the ** prompt when you don't give a filename on the command line, as the TeXbook (Metafontbook) says you should. 2) Files are looked for first with the extension .tex (.mf), as usual, and then without any extension, so that you can read a file named just `foo' if you want. 3) A complete set of man pages is part of the distribution. You can easily make them to reflect your local paths. 4) The Makefiles can now make and install the .fmt and .base files you want, so you don't have to do it by hand. 5) A patch file to build a TeX with more than 256 trie ops is included. 6) The programs now (optionally) search subdirectories of the directories named in the paths, instead of just the top-level directories. This means that, for example, you can set up your font directory with subdirectories `cm', `pandora', `concrete', `ams', etc. -- and when you add another font family, you don't have to recompile TeX to add the directory to your path! The same goes for the macro directories, etc. I have hacked the device drivers xdvi, dvips, and postscript to support this search method (and sent the changes to the authors). If you want my changes, I'll send them to you. 7) There is a change file to make a ``big'' BibTeX. 8) The restriction on the length of the environment variables has been removed (as long as you have a working malloc and realloc; again, you can get the GNU versions if your system ones fail). 9) The `dvicopy' program, written by P. Breitenlohner, is included. It resolves references to VF fonts in DVI files, and writes another DVI file without any such references. The change file was contributed by Klaus Guntermann. Send me mail if you encounter trouble. karl@cs.umb.edu karl@ai.mit.edu ...!harvard!umb!karl From "Don Hosek " Thu Aug 30 20:47:23 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Thu 30 Aug 90 20:42:57-MDT Date: Thu, 30 Aug 1990 18:17 PDT From: Don Hosek Subject: Latest versions of TeX and MF available for VMS. To: tex-archive@science.utah.edu, vmstex-l@uicvm.uic.edu, texhax@cs.washington.edu, infotex@aston.ac.uk Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive,in%"vmstex-l@uicvm.uic.edu",texhax,uktex The latest versions of TeX and MF for VMS are now available from ymir.claremont.edu. A few bug fixes and minor enhancements have been made to the TeX change file bringing it to 3.0/3.2 (the latter number is the change file version). The upgrade of this change file is not necessary if you have 3.0/3.1a, but is worthwhile. Files are in [anonymous.tex.sources.tex3_0]. MF 2.0/2.1a is now officially available for VMS. There is an increase in the speed of the system through some assembly routines contributed by John Lavagnino and all on-line displays are accessed through VMS sharable libraries. At present only one library, the GraphOn-140 1.0a library is available, although others are under development (contact Don Hosek, dhosek@ymir.claremont.edu if you intend to create a library to find out if anyone else is working on one and for advice in creating the library). Files are in [anonymous.tex.sources.mf2_0]. The files 00readme.txt in each directory indicate what the files are. Below are vms_tex_notes.txt and vms_mf_notes.txt from those directories. Help files are under development and will be announced shortly. Those without FTP access can obtain the files from mailserv@ymir.claremont.edu. Directory specifications are identical, but without the :anonymous" at the beginning. The command to retrieve a file is "send", e.g., send [sources.tex3_0]00readme.txt Binary files are not currently available via mailserv. Nothing can be done about this deficiency at this time. These versions of TeX and MF will be available on tape from DECUS and Stanford by mid-September (I think). ------ Some notes on the version of TeX for VMS located in this directory: - The version number on the change file is currently 3.2 - Note that a larger version of TANGLE is necessary to Tangle this code. I used max_names=5000 and max_toks=52000 to get it compiled. - The Pascal code generated by TANGLEing TEX.WEB will not compile properly with Pascal versions prior to 4.0. - TeX is now called through the CLI. You should install the file TEX.CLD in the system DCL tables. The following options are provided: /BATCH Run TeX in batch mode sending no output to the terminal and ending with a fatal error if input is necessary. The default is /NOBATCH. /CONTINUE Indicate that TeX is to continue execution after the editor is invoked with an 'E' response at an error prompt. The default is /NOCONTINUE /DIAGNOSTICS Indicate that an LSE Diagnostics file be written. A file name can be specified using /DIAGNOSTICS=fn. The default is /NODIAGNOSTICS. /DVI_FILE= Indicate the name of the DVI file to write. The default is to use the name of the TeX job for the DVI file name. This qualifier is negatable. /EDITOR= Indicate the name of the editor to be used at the 'E' response. The options are: + Callable_EDT + Callable_LSE + Callable_TECO + Callable_TPU + The name of a command to be run in a subprocess which will take three arguments: 'p1 is the name of the file to edit, 'p2 is the line number with the error and 'p3 is the column number of the error. If the value given with /EDITOR ends in a colon, TeX will assume that it's a logical name and attempt to translate it. The default is /EDITOR=TEX_EDIT:. This qualifier is negatable. /FORMAT= Indicate the name of a format to pre-load when running. The default varies depending on the specific verb used. This qualifier is negatable. /INIT Run IniTeX rather than TeX. The default is /NOINIT. INITEX should be set equivalent to TEX/INIT/NOFORMAT. /JOBNAME_SYMBOL= Indicate the name of a DCL symbol to which the TeX jobname is to be written. The default is /JOBNAME_SYMBOL=TEX_JOBNAME. This qualifier is negatable. Negation causes the symbol to not be written. /LOG_FILE= Indicate the name of the LOG file to write. The default is to use the name of the TeX job for the LOG file name. This qualifier is negatable. /TEXFONTS= These qualifiers are not intended to be used /TEXFORMATS= by the end-user; they specify the names of the /TEXINPUTS= logicals to be used for the locations of TFMs, format and pool files, and input files respectively. They are provided to allow sites to customize these values without recompiling TeX. - INITEX is part of the main TeX module. Thus, there is only one change file and one executable. The price that we pay is trivial: three if statements operating on a boolean variable and an executable 25K larger. The three if statements are all out of the inner loop so other than a slightly increased startup time, TeX will not be slower. - This is 64bit TeX. If memory is really a problem, you can reduce the main memory array and recompile. Personally, I think that it's inconvenient to try and run TeX at two memory sizes so I don't recommend it. - In previous versions of VMS TeX with an editor interface, TeX continued after leaving the editor. This behavior is incorrect and has been changed. ----- Some notes on the version of MF for VMS located in this directory: - The version number on the change file is currently 2.1a - Note that a larger version of TANGLE is necessary to Tangle this code. I used max_names=5000 and max_toks=54000 to get it compiled. - MF is now called through the CLI. You should install the file MF.CLD in the system DCL tables. The following options are provided: /BASE= Indicates the base file to be "preloaded" by MF. The default varies depending on the version of MF being used. The default CLD uses /BASE=plain for MF and /NOBASE for INIMF. /BATCH Run MF in batch mode sending no output to the terminal and ending with a fatal error if input is necessary. The default is /NOBATCH. /CONTINUE Indicates that MF should continue after editing a file. The default is /NOCONTINUE /DIAGNOSTICS= Indicate that an LSE Diagnostics file be written. A file name can be specified using /DIAGNOSTICS=fn. The default is /NODIAGNOSTICS. /DISPLAY= Indicates the name of the display for on-line graphics. The default is /DISPLAY=MFTERM: /EDITOR= Indicate the name of the editor to be used at the 'E' response. The options are: + Callable_EDT + Callable_LSE + Callable_TECO + Callable_TPU + The name of a command to be run in a subprocess which will take three arguments: 'p1 is the name of the file to edit, 'p2 is the line number with the error and 'p3 is the column number of the error. If the value given with /EDITOR ends in a colon, TeX will assume that it's a logical name and attempt to translate it. The default is /EDITOR=TEX_EDIT:. This qualifier is negatable. /GF_FILE The GF file to which output should be written. The default is to write to a file with file name equivalent to the MF jobname and extension given by the resolution * magnification of the MF run. This qualifier is not negatable. /GLIB_INDEX= Indicates the name of the index file for displays. /INIT Run IniMF rather than MF. The default is /NOINIT. The INIMF verb automatically selects /NOBASE /JOBNAME_SYMBOL= Indicates the name of a symbol in which MF should store the name of the GF file it writes. The default is /JOBNAME_SYMBOL=MF_JOBNAME This qualifier is negatable. If either it or /JOBSIZE_SYMBOL is negated, no symbols are written. /JOBSIZE_SYMBOL= Indicates the name of a symbol in which MF should store the numeric portion of the GF file which it writes. The default is /JOBSIZE_SYMBOL=MF_JOBSIZE. If either it or /JOBNAME_SYMBOL is negated, no symbols are written. /LOG_FILE= Indicate the name of the LOG file to write. The default is to use the name of the TeX job for the LOG file name. This qualifier is negatable. /MFBASES= These qualifiers are not intended to be used /MFINPUTS= by the end-user; they specify the names of the logicals to be used for the locations of base input files respectively. They are provided to allow sites to customize these values without recompiling MF. - INIMF is part of the main MF module. Thus, there is only one change file and one executable. - In previous versions of VMS MF with an editor interface, MF continued after leaving the editor. This feature is now controlled by the switch /CONTINUE. - On-line displays are now stored in separate sharable libraries. Each library intended to be used with MF must contain the following routines. (Note: C protocols are untested and may be wrong for libdrrow.) + LIBINITSC: Handles whatever initializations are necessary to use the display and prints a banner line on the display. This routine is always called, even if no graphics are used, so it may be wise to hold off initializations of the display itself until LIBSTARTS is called and only initialize static variables etc. This routine is passed the addresses of two integer variables whose values should be set to the horizontal and vertical sizes of the display. PROTOCOL: Pascal procedure LIBINITSC(var x_size, y_size : integer); C void LIBINITSC(x_size, y_size) int *x_size, *y_size; + LIBSTARTS: Called before the first write to the screen. should handle any screen initializations and leave the graphics screen blank and ready-to-write. Upon completion, the terminal should be in text mode, if possible. PROTOCOL: Pascal procedure LIBSTARTS; C void LIBSTARTS() + LIBBLRECT: Erases a rectangle whose boundaries are given as arguments to the procedure in integer quantities. Upon completion, the terminal should be in text mode, if possible. PROTOCOL: Pascal procedure LIBBLRECT(left_col,right_col,top_row,bot_row:integer); C void LIBBLRECT(left_col, right_col, top_row, bot_row) int left_col, right_col, top_row, bot_row; + LIBDRWROW: Draws a row of alternatingly black and white pixels which alternate between black and white between columns a[i] on row r for n columns. With initial color b. See the MF source or a sample library for details. Should leave the terminal in TEXT mode if at all possible. PROTOCOL: Pascal type trans_spec= array[0..65536] of integer; procedure LIBDRWROW(r: integer; b:0..1; a:trans_spec; n: integer); C void LIBDRROW(r, b, a, n) int r, b, n; int a[65536]; + LIBUPDTSC: Makes sure that everything on the display is up-to-date. This is particularly valuable for those displays which cannot easily erase portions of the screen. Should leave the terminal in TEXT mode if at all possible. PROTOCOL: Pascal procedure LIBUPDTSC; C void LIBUPDTSC() + LIBCLOSSC: Restores the terminal back to a normal state. It is not necessary to clear the graphics screen unless not doing so would interfere with use of the terminal's text mode. PROTOCOL: Pascal procedure LIBCLOSSC; C void LIBCLOSSC() + LIBLEVEL: A function which returns 0. This is meant for future expansion of the graphics library functionality. PROTOCOL: Pascal function LIBLEVEL: integer; C int LIBLEVEL() From "Nelson H. F. Beebe " Sat Sep 1 15:31:48 1990 Flags: 000000000001 Mail-From: BEEBE created at 1-Sep-90 15:28:22 Date: Sat 1 Sep 90 15:28:22-MDT From: "Nelson H. F. Beebe" Subject: xxencode pending name change To: tex-archive@SCIENCE.utah.edu cc: Beebe@SCIENCE.utah.edu X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12618535980.19.BEEBE@SCIENCE.utah.edu> Peter Flynn has just pointed out that the name xxencode is already in existence for another program that has nothing to do with mine. I'm about to leave for Ireland, so for now, I've made TUGlib revert to using uuencoding, and on my return, will pick a new name, probably **encode, where ** = ww, yy, or zz. Let me know if any of these are already in use. Also, if anyone has specifications of the pre-existing xxencode, please send them to me. ------- From "Don Hosek " Mon Sep 3 19:37:05 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Mon 3 Sep 90 19:35:17-MDT Date: Mon, 3 Sep 1990 18:32 PDT From: Don Hosek Subject: New version of german.sty To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: TEX_ARCHIVE I've just received yet another new version of german.sty from Rainer Schoepf. It's on ymir.claremont.edu in [anonymous.tex.babel.german]german.sty -dh From "JANET TEX@UK.AC.CRANFIELD.RMCS " Tue Sep 4 06:48:41 1990 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by science.utah.edu with TCP; Tue 4 Sep 90 06:47:55-MDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id aa02263; Tue, 4 Sep 90 12:37:19 +0000 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa04917; 4 Sep 90 13:00 BST Date: Tue, 4 SEP 90 13:39:57 BST From: TEX@rmcs.cranfield.ac.uk To: TEX-ARCHIVE <@nsfnet-relay.ac.uk:TEX-ARCHIVE@science.utah.edu> Subject: Aston archive 00* listing files Actually-to: Sender: "JANET TEX@UK.AC.CRANFIELD.RMCS" Reply-to: Niel Kempson Originally-to: TEXHAX Originally-from: TEX "Niel Kempson " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) In response to customer suggestions (and to make use of a program that I wrote a year ago), I've made some changes to the 00*.* listing files scattered around the archive. ARCHIVE LISTINGS ~~~~~~~~~~~~~~~~ At the top of the archive you will now find the files: disk$tex:[tex-archive]00directory.list disk$tex:[tex-archive]00directory.size disk$tex:[tex-archive]00last7days.files disk$tex:[tex-archive]00last30days.files Their contents are summarised briefly below: 00directory.list - all of the files in the archive grouped by directory. 00directory.size - all of the files in the archive grouped by directory. The size and date of each files is also listed. 00last30days.files - files in the archive which have been changed in the last 30 days listed in descending date order. The date, size, contents and full file specification is listed for each file in '00files.txt' format (see below). 00last7days.files - files in the archive which have been changed in the last 7 days listed in descending date order. The date, size, contents and full file specification is listed for each file in '00files.txt' format (see below). NOTES: With the exception of 00last7days.files (which didn't exist), these names used to begin with THREE zeros. The old files will remain for a while but will not be updated. The new files will be updated every day at about 0130 UK time (BST/GMT). DIRECTORY LISTINGS ~~~~~~~~~~~~~~~~~~ In every (non-empty) directory of the archive, you should find a file called 00files.txt which lists all of the files in that directory in descending date order. The date, size, contents and full file specification is listed for each file. For example, here is the 00files.txt from the directory DISK$TEX:[TEX-ARCHIVE.AMSTEX] > Files matching DISK$TEX:[TEX-ARCHIVE.AMSTEX]*.* > listed in reverse time order (listing updated: 26-Aug-90 15:52). > > Last change Size Type File specification > ------------------------------------------------------------------------------ > 30-Apr-90 11:13 - DIR disk$tex:[tex-archive.amstex]trip.dir > 30-Apr-90 11:13 - DIR disk$tex:[tex-archive.amstex]doc.dir > 30-Apr-90 11:13 - DIR disk$tex:[tex-archive.amstex]amstex-style.dir > 13-Jul-89 20:06 12110 BIN disk$tex:[tex-archive.amstex]amstex.doc_z > 13-Jul-89 20:05 10166 BIN disk$tex:[tex-archive.amstex]amsppt.doc_z > 13-Jul-89 20:05 30856 BIN disk$tex:[tex-archive.amstex]amsman.tex_z > 13-Jul-89 20:05 1296 BIN disk$tex:[tex-archive.amstex]amsman.hdr_z > 13-Jul-89 20:05 1014 BIN disk$tex:[tex-archive.amstex]amsman.errata_z > 14-Apr-86 21:32 1018 TXT disk$tex:[tex-archive.amstex]amstex.chg > ------------------------------------------------------------------------------ NOTES: The size is in bytes (not VMS blocks). The Type will be one of: BIN - binary file (use /ENCODE with the mail server) DIR - VMS directory (don't try to fetch these) TXT - ordinary text file The directory contents are checked every day, and the 00FILES.TXT files updated only if something has changed in the directory. The contents of 00LAST7DAYS.FILES and 00LAST30DAYS.FILES in the top level directory are in this format, except that the first two lines are slightly different: > Files matching DISK$TEX:[TEX-ARCHIVE...]*.* > modified since 21-Aug-90 00:00 (listing updated: 27-Aug-90 01:49). > > Last change Size Type File specification > ------------------------------------------------------------------------------ If you find any problems, errors, or have any comments to make, please direct them to me or . Niel Kempson Aston University TeX archive group +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ukacrl + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: {mcvax,ukc,uunet}!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785687 (UK), +44-793-785687 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From "Don Hosek " Tue Sep 4 10:13:16 1990 Flags: 000000000001 Return-Path: Received: from MIMIR.CLAREMONT.EDU by science.utah.edu with TCP; Tue 4 Sep 90 10:12:42-MDT Date: Tue, 4 Sep 1990 03:06 PDT From: Don Hosek Subject: Re: double spaced To: spqr@ecs.southampton.ac.uk, tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: IN%"spqr@ecs.southampton.ac.uk" X-VMS-Cc: tex_archive Sebastian Rahtz' improved doublespace.sty (works with both font selection schemes for LaTeX) is now available from ymir.claremont.edu FTP: [anonymous.tex.inputs.latex-contrib]singlespace.sty Mailserv (to mailserv@ymir.claremont.edu) send [tex.inputs.latex-contrib]singlespace.sty -dh From "Don Hosek " Tue Sep 4 10:13:52 1990 Flags: 000000000001 Return-Path: Received: from MIMIR.CLAREMONT.EDU by science.utah.edu with TCP; Tue 4 Sep 90 10:12:49-MDT Date: Tue, 4 Sep 1990 03:08 PDT From: Don Hosek Subject: More regarding double spaced. To: tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: tex_archive Oh, one other note. Sebastian's macro should be considered to supersede the original doublespace.sty -dh From "Don Hosek " Sat Sep 22 19:53:15 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Sat 22 Sep 90 19:47:27-MDT Date: Sat, 22 Sep 1990 18:44 PDT From: Don Hosek Subject: Re: Changes for Tex3.0 To: kolk@smiley.Stanford.EDU, tex-archive@science.utah.edu Message-id: X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: IN%"kolk@smiley.Stanford.EDU" X-VMS-Cc: TEX_ARCHIVE As most of you already know, Knuth has just put a new bunch of files up on labrea.stanford.edu; Dan Kolkowicz (did I get that right?) posted a list of files that had changed. It's worth noting that some of the files listed as being changed are the same. When I copied the files over to ymir, I checked them against the old files and determined that the files below are the minimal changes (I'm including the list also for the benefit of those subscribers to this list who can only FTP with difficulty who may want to obtain the files by mailserv@ymir.claremont.edu: to request a file, send one line per file with the form SEND [directory]filename.ext e.g., SEND [TEX.SOURCES.TEX3_1]tex.web01_13 I did not retrieve any of the tex/local files except those in local/lib which I distributed through my tree according to how best they'd fit in. I'd like to thank Dan for notifying us of the changes in the manner in which he did and hope that he continues to do so in the future (by the way, Dan, are you on the tex-archive list?). Looking over the changes to the programs, they seem largely minor and updating change files should be trivial (as soon as I finish some other items, I'm going to do the VMS change files). What happened to MF 2.1-2.6? -dh Directory LOCAL:[TEX.INPUTS.PLAIN-CONTRIB] EPSF.TEX;1 FONTCHART.TEX;1 GKPMAC.TEX;2 LETTER.TEX;1 LIST.TEX;1 LLIST.TEX;1 PICMAC.TEX;1 ROTATE.TEX;1 Total of 8 files. Directory LOCAL:[TEX.INPUTS.STANDARD] PLAIN.TEX;10 WEBMAC.TEX;11 Total of 3 files. Directory LOCAL:[TEX.MF.CM.STANDARD] CMBASE.MFT;3 Total of 1 file. Directory LOCAL:[TEX.MF.LATEX] LCIRCLE.MF;1 LCIRCLE10.MF;2 LCIRCLEW10.MF;2 LINE.MF;4 Total of 4 files. Directory LOCAL:[TEX.MF.MISC] ART.MF;1 Total of 1 file. Directory LOCAL:[TEX.MF.STANDARD] BLACK.MF;3 BLACKAPS.MF;1 BLACKIMAGEN.MF;1 GRAY.MF;3 GRAYAPS.MF;1 GRAYIMAGEN.MF;1 GRAYIMAGEN3.MF;1 GRAYIMAGENLIGHT.MF;1 MFMAN.MF;3 ONEONE.MF;3 PLAIN.MFT;3 RANDOM.MF;3 SLANTAPS4.MF;1 SLANTIMAGEN6.MF;1 Total of 13 files. Directory LOCAL:[TEX.SOURCES.MF2_7] MF.WEB;3 MF.WEB01-12;2 MF.WEB02-12;2 MF.WEB03-12;2 MF.WEB04-12;2 MF.WEB05-12;2 MF.WEB06-12;2 MF.WEB07-12;2 MF.WEB08-12;2 MF.WEB09-12;2 MF.WEB10-12;2 MF.WEB11-12;2 MF.WEB12-12;2 MF84.BUG;2 MFBOOK.TEX;3 Total of 15 files. Directory LOCAL:[TEX.SOURCES.MFWARE] GFTODVI.WEB;7 GFTOPK.WEB;8 MFT.WEB;5 Total of 3 files. Directory LOCAL:[TEX.SOURCES.TEX3_1] CM85.BUG;1 ERRATA.FIVE;2 ERRATA.TEX;3 ERRORLOG.TEX;2 TEX.WEB;11 TEX.WEB01-13;2 TEX.WEB02-13;2 TEX.WEB03-13;2 TEX.WEB04-13;2 TEX.WEB05-13;2 TEX.WEB06-13;2 TEX.WEB07-13;2 TEX.WEB08-13;2 TEX.WEB09-13;2 TEX.WEB10-13;2 TEX.WEB11-13;2 TEX.WEB12-13;2 TEX.WEB13-13;2 TEX82.BUG;3 TEXBOOK.TEX;2 Total of 20 files. Directory LOCAL:[TEX.SOURCES.TEXWARE] DVITYPE.WEB;6 PLTOTF.WEB;6 TFTOPL.WEB;6 VFTOVP.WEB;2 VPTOVF.WEB;2 Total of 5 files. Directory LOCAL:[TEX.SOURCES.WEB] TANGLE.WEB;6 WEAVE.WEB;6 WEBMAN.TEX;3 Total of 4 files. Directory LOCAL:[TEX.TEST.TRAP] TRAP.FOT;5 TRAP.LOG;5 TRAP.MF;6 TRAP.PL;5 TRAP.TYP;5 TRAPIN.LOG;5 TRAPMAN.TEX;5 Total of 7 files. Directory LOCAL:[TEX.TEST.TRIP] TRIP.FOT;6 TRIP.LOG;6 TRIP.PL;5 TRIP.TEX;6 TRIP.TYP;5 TRIPIN.LOG;5 TRIPMAN.TEX;4 Total of 7 files. Grand total of 16 directories, 96 files. From "Don Hosek " Tue Oct 2 11:34:48 1990 Flags: 000000000001 Return-Path: Received: from SIF.CLAREMONT.EDU by science.utah.edu with TCP; Tue 2 Oct 90 11:29:26-MDT Date: Tue, 2 Oct 1990 10:27 PDT From: Don Hosek Subject: Another PiCTeX-LaTeX inconsistency To: tex-archive@science.utah.edu, wichura@galton.uchicago.edu Message-id: <59903251C0600EB1@HMCVAX.CLAREMONT.EDU> X-Envelope-to: tex-archive@science.utah.edu X-VMS-To: TEX_ARCHIVE,IN%"wichura@galton.uchicago.edu" The definition of \$ in LaTeX apparently runs into problems when it occurs in certain contexts in a PiCTeX PiCture. I've applied a fix to the copy on ymir based on a suggestion by Eberhard Mattes which takes care of the problem (with either font selection scheme). The appropriate code is: \@ifundefined{normalshape}{% \def\pdollar{{\ifdim \fontdimen\@ne\font >\z@ \sl \fi\char36}}}{% \def\pdollar{\text{\ifdim \fontdimen\@ne\font >\z@ \sl \else \normalshape \fi\char36}}} % Added 2-Oct-1990 Don Hosek at suggestion of Eberhard Mattes to allow % use of \$ inside a PiCTeX PiCture. and affects prepictex.tex and piclatex.sty (which are in [anonymous.tex.inputs.pictex] for anonymous FTP users, [tex.inputs.pictex] for mailserv users). -dh From "Piet van Oostrum " Wed Oct 17 08:00:31 1990 Flags: 000000000001 Received: from [128.110.192.2] by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA00907; Wed, 17 Oct 90 08:00:30 MDT Return-Path: <@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from math.utah.edu by [128.110.192.2] with TCP; Wed 17 Oct 90 05:02:19-MDT Received: from ruuinf.cs.ruu.nl by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA27029; Wed, 17 Oct 90 05:03:15 MDT Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA16228; Wed, 17 Oct 90 12:02:56 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA07136; Wed, 17 Oct 90 12:03:56 -0100 Date: Wed, 17 Oct 90 12:03:56 -0100 From: Piet van Oostrum Message-Id: <9010171103.AA07136@praxis.cs.ruu.nl> To: tex-archive@csc-sun.math.utah.edu Subject: Web2c newest version Resent-Date: Wed 17 Oct 90 07:59:23-MDT Resent-From: "Nelson H. F. Beebe" Resent-To: beebe@math.utah.edu Resent-Message-Id: <12630512869.36.BEEBE@SCIENCE.utah.edu> I want to install the newest versions of TeX (3.1) and Metafont (2.7) on one of our machines. I have web2c version 5.0e. I have replaced the web files with the newest ones from labrea. Two questions: 1. Labrea has older versions of web2c. I forgot where I got the 5.0e version (they were announced on the net sometime ago). Is this 5.0e version considered to be an "official" version? 2. To get this version updated to TeX3.1 and MF 2.7 I have to make a few changes to the change files. This is probably not much work, but if anyone else has already done that, it is much more useful to share his/her work. Otherwise I want to share my work (and probably call it version 5.0f). Has anybody done this already? By the way, I found already a small error in one of the modules. I will report this when I am finished. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') From "Piet van Oostrum " Wed Oct 17 12:13:50 1990 Flags: 000000000001 Received: from [128.110.192.2] by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02468; Wed, 17 Oct 90 12:13:48 MDT Return-Path: <@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from math.utah.edu by [128.110.192.2] with TCP; Wed 17 Oct 90 05:02:19-MDT Received: from ruuinf.cs.ruu.nl by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA27029; Wed, 17 Oct 90 05:03:15 MDT Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA16228; Wed, 17 Oct 90 12:02:56 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA07136; Wed, 17 Oct 90 12:03:56 -0100 Date: Wed, 17 Oct 90 12:03:56 -0100 From: Piet van Oostrum Message-Id: <9010171103.AA07136@praxis.cs.ruu.nl> To: tex-archive@csc-sun.math.utah.edu Subject: Web2c newest version Resent-Date: Wed 17 Oct 90 12:12:35-MDT Resent-From: "Nelson H. F. Beebe" Resent-To: beebe@math.utah.edu Resent-Message-Id: <12630558963.23.BEEBE@SCIENCE.utah.edu> I want to install the newest versions of TeX (3.1) and Metafont (2.7) on one of our machines. I have web2c version 5.0e. I have replaced the web files with the newest ones from labrea. Two questions: 1. Labrea has older versions of web2c. I forgot where I got the 5.0e version (they were announced on the net sometime ago). Is this 5.0e version considered to be an "official" version? 2. To get this version updated to TeX3.1 and MF 2.7 I have to make a few changes to the change files. This is probably not much work, but if anyone else has already done that, it is much more useful to share his/her work. Otherwise I want to share my work (and probably call it version 5.0f). Has anybody done this already? By the way, I found already a small error in one of the modules. I will report this when I am finished. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') From "mrd@ddd.prepnet.com (Michael DeCorte)" Wed Oct 17 12:13:52 1990 Flags: 000000000001 Received: from [128.110.192.2] by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02472; Wed, 17 Oct 90 12:13:51 MDT Return-Path: Received: from math.utah.edu by [128.110.192.2] with TCP; Wed 17 Oct 90 08:51:34-MDT Received: from ddd.prepnet.com by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01177; Wed, 17 Oct 90 08:52:30 MDT Received: by ddd.prepnet.com (5.61/4.7) id AA10690; Wed, 17 Oct 90 10:42:20 -0500 Date: Wed, 17 Oct 90 10:42:20 -0500 From: mrd@ddd.prepnet.com (Michael DeCorte) Message-Id: <9010171542.AA10690@ddd.prepnet.com> To: piet@cs.ruu.nl, tex-archive@csc-sun.math.utah.edu Subject: Re: Web2c newest version Resent-Date: Wed 17 Oct 90 12:12:38-MDT Resent-From: "Nelson H. F. Beebe" Resent-To: beebe@math.utah.edu Resent-Message-Id: <12630558971.23.BEEBE@SCIENCE.utah.edu> I don't really know what the current status of the change files and web2c is (I effectivly lost my ability to read mail for 6 months). I would suggest that you ask U of Washington. mackay@june.cs.washington.edu he is in charge of the Unix distribution. From "Nelson H.F. Beebe " Wed Oct 17 13:15:00 1990 Flags: 000000000001 Return-Path: Received: from sandy.math.utah.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02753; Wed, 17 Oct 90 13:14:50 MDT Date: Wed, 17 Oct 1990 13:14:47 MDT From: "Nelson H.F. Beebe" To: tex-archive Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics,\ University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Subject: Clarkson archive status -- an update Message-Id: Michael DeCorte, maintainer of the Clarkson archive, has been away (even from e-mail) for 6 months, and consequently, the archive has gotten out of date. He has this report: >> Date: Wed, 17 Oct 90 14:15:29 -0500 >> From: mrd@ddd.prepnet.com (Michael DeCorte) >> >> Right now I haven't the time to deal with the archive (working >> 80-90 hours/week to make our toy ready for the big conference) >> but in December I'll be living a fairling normal schedule and >> will be able to update everything. I'll probably take a little >> vacation at Clarkson to wind down and the archive is by comparison >> wildly relaxing. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@science.utah.edu ======================================================================== From "mackay@cs.washington.edu (Pierre MacKay)" Wed Oct 17 17:50:12 1990 Flags: 000000000001 Received: from [128.110.192.2] by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA06032; Wed, 17 Oct 90 17:50:09 MDT Return-Path: Received: from math.utah.edu by [128.110.192.2] with TCP; Wed 17 Oct 90 16:28:13-MDT Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA03760; Wed, 17 Oct 90 16:29:08 MDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA20514; Wed, 17 Oct 90 15:28:35 -0700 Date: Wed, 17 Oct 90 15:28:35 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9010172228.AA20514@june.cs.washington.edu> To: piet@cs.ruu.nl Cc: tex-archive@csc-sun.math.utah.edu In-Reply-To: Piet van Oostrum's message of Wed, 17 Oct 90 12:03:56 -0100 <9010171103.AA07136@praxis.cs.ruu.nl> Subject: Web2c newest version Resent-Date: Wed 17 Oct 90 17:49:04-MDT Resent-From: "Nelson H. F. Beebe" Resent-To: beebe@math.utah.edu Resent-Message-Id: <12630620219.36.BEEBE@SCIENCE.utah.edu> Try ics.uci.edu and look for files with the serial number 5.8a in the filename. I have successfully compiled everything but bibtex from this new package. Elderly compilers, which cannot make the distinction between ANSI style declarations and Kernighan and Ritchie style declarations will cough on the declaration of string_copy (char *s) in common/extra.c but that can easily be changed. Ultimately, I suupose it will be necessary to have a full set of alternative procedure headers, selected by an #ifdef It is hard at the moment to know what is "official" The lplain.tex on labrea will not even work with TeX3.0. since it does not properly initialize the \language stack. From "MITTELBACH FRANK " Tue Oct 30 21:50:34 1990 Flags: 000000000001 Return-Path: <@MATH.AMS.COM,@CUNYVM.CUNY.EDU:PZF5HZ@DRUEDS2.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA15932; Wed, 31 Oct 90 04:50:25 MST Message-Id: <9010311150.AA15932@math.utah.edu> Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Wed, 31 Oct 90 06:47:26-EDT Received: from RUIPC1E.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5981; Wed, 31 Oct 90 06:42:38 EST Date: 10/31/90 12:20:46 GMT+1 From: MITTELBACH FRANK To: TEX-IMPLEMENTORS@MATH.AMS.COM Subject: RE: RE: LABREA ARCHIVE FILES. > > There exist versions of lplain.tex and splain.tex for TeX 3.x > (they also work with older TeXs as well) created by Frank and > Rainer and some others I think. These are on ymir.claremont.edu > in [anonymous.tex.inputs.latex] and > [anonymous.tex.inputs.slitex]. Before placing them into LABREA one should probably change the message ``setting things up for TeX 3.0'' into something more sensible since it is actually a section that allows to use TeX 3.0 commands in an enviroment which runs TeX 2.xx (i.e. making \errorcontextlines a counter if undefined etc.) > > Leslie has said that any changes to the files that Frank and > Rainer can make official changes to the files and I've been > considering these as the official lplain.tex and splain.tex; > there has seemed to be some difficulty getting the change to > propogate if it doesn't make it to labrea; perhaps we can finally > get this taken care of? Yes please place it in the official archive since this is slowing things up otherwise. Frank P.S. To Don Hosek (and some others having VAX systems): I don't get your mail at all. It arrives in a way so that my system is unable to figure out which userid is involved. In IBM language: the writer field is empty. Looking at the input in the spool it looks as if there is a small shift to the right in the received netdata format so that the receive command on my system does not get the fields correct. Since several VAX machines became silent that way at nearly the same time I wonder whether is could be an `upgrade' of some mail software which does not produce a `correct' (well, correct to my IBM) netdata format. Any help is of interest because I suppose that I loose some incoming mail that way. From "Piet van Oostrum " Mon Nov 19 01:51:42 1990 Flags: 000000000001 Return-Path: <@[128.110.192.2],@ruuinf.cs.ruu.nl:piet@praxis.cs.ruu.nl> Received: from [128.110.192.2] by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA04102; Mon, 19 Nov 90 08:51:40 MST Received: from math.utah.edu by [128.110.192.2] with TCP; Mon 19 Nov 90 08:44:05-MST Received: from ruuinf.cs.ruu.nl by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA04087; Mon, 19 Nov 90 08:46:28 MST Received: from ecu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA29864; Mon, 19 Nov 90 16:39:57 +0100 Received: by praxis.cs.ruu.nl (15.11/15.6) id AA01145; Mon, 19 Nov 90 16:43:14 -0100 Date: Mon, 19 Nov 90 16:43:14 -0100 From: Piet van Oostrum Message-Id: <9011191543.AA01145@praxis.cs.ruu.nl> To: kwok@iris.ucdavis.edu, podar@sbcs.csnet, tex-archive@csc-sun.math.utah.edu Subject: [e]epic.sty I noticed that the [e]epic.sty files as archived in the clarkson latex-style directory contains explicit \makeatletter and \makeatother commands. This makes them screw any style option that is given after them. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') From "Don Hosek " Mon Nov 19 09:02:37 1990 Flags: 000000000001 Return-Path: <@[128.110.192.2]:DHOSEK@HMCVAX.CLAREMONT.EDU> Received: from [128.110.192.2] by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA06786; Mon, 19 Nov 90 16:02:33 MST Received: from math.utah.edu by [128.110.192.2] with TCP; Mon 19 Nov 90 15:58:37-MST Received: from SIF.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA06780; Mon, 19 Nov 90 16:01:01 MST Date: Mon, 19 Nov 1990 14:56 PST From: Don Hosek Subject: Re: [e]epic.sty To: piet@cs.ruu.nl, tex-archive@science.utah.edu, kwok@iris.ucdavis.edu, podar%sbcs.csnet@relay.cs.net Message-Id: <3739CCF89AC00EE2@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: IN%"piet@cs.ruu.nl",tex_archive,in%"kwok@iris.ucdavis.edu",in%"podar%sbcs.csnet@relay.cs.net" The copies of epic.sty and eepic.sty on ymir have been appropriately updated. -dh From "Jan Michael Rynning " Fri Nov 30 09:27:06 1990 Flags: 000000000001 Return-Path: Received: from nada.kth.se (cyklop.nada.kth.se) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA06959; Fri, 30 Nov 90 16:25:35 MST Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24691; Sat, 1 Dec 90 00:25:33 +0100 Date: Sat, 1 Dec 90 0:25:32 +0100 From: Jan Michael Rynning To: tex-archive@science.utah.edu Subject: archie - an archive of archives Message-Id: One of our students passed this on to me. It may be of interest to you all. > McGill School of Computer Science Operating "archie" > ------------------------------------------------------ > - An Internet Archive Server Listing Service > ---------------------------------------------- > > Given the number of hosts being used as archive sites nowadays, there can > be great difficulty in finding needed software in a distributed > environment. You may know that the software that you need is out there, > but it can sometimes be difficult to find. The School of Computer > Science at McGill University has one solution to the problem - "archie". > > Getting To The Point: > --------------------- > > So how do you get to use archie? If you are Internet connected, it's > easy. Telnet to quiche.cs.mcgill.ca (132.206.2.3 or 132.206.51.1) and > login as user "archie". You should get a banner message and status > report on our latest additions (there's no password, although we do log > the sessions to provide rudimentary stats). "help" gets a list of valid > commands. Feedback welcome and can be sent to archie@cs.mcgill.ca > (please see list of current limitations below). > Please note that at the time of writing the database has not been fully > built: there are still some 50 (out of over 600) sites to be entered. > Long version for those who are interested...... > > What is archie ? > ---------------- > Archie is a pair of software tools. the first maintains a list of about > 600 Internet ftp archive sites. Each night software executes an > anonymous ftp to a subset of these sites and fetches a recursive > directory listing of each. We hit about 1/30th of the list each time, > so each site gets hit about once a month, hopefully balancing timely > updates against unnecessary network load. The listings are stored on > one of our machines quiche.cs.mcgill.ca (132.206.2.3) where they are > made available to the entire Internet community via anonymous ftp > in the directory ~ftp/archie/listings in compressed form. > > The second tool is the interesting one as far as the users are > concerned. It consists of a program running on a dummy user code that > allows outsiders to log onto the archive host to query the database. > This is in fact the program we call archie. > We have just finished implementing a database scheme, which both greatly > speeds lookup and reduces storage requirements. > Users can ask archie to search for specific name strings. For example, > "prog kcl" would find all occurences of the string "kcl" and tell you > which hosts have entries with this string, the size of the program, its > last modification date and where it can be found on the host along with > some other useful information. In this example, you could thus find > those archive sites that are storing Kyoto Common Lisp. With one central > database for all the archive sites we know about, archie greatly speeds > the task of finding a specific program on the net. > > Archie is currently running in "proof of concept" mode, but already it > has proved its popularity (we are getting up to 50 queries a day and the > number is increasing daily as word spreads). We still consider archie to > be in "beta" and there are a number of features to be added before it > becomes fully operational. > > At present archie has two useful commands. The first ("prog") lets you > specify a search string (using "ed" regular expressions for wildcard > matching). The second ("site") lets you ask for a site listing by name. > In this case, it lists all programs at the given site, in effect > reconstructing the original recursive listing. There is also a > rudimentary help, but not much more. > Limitations and future plans > ---------------------------- > These are limitations that we plan to change in the near to the > not-so-near future. > - The regular expressions are CASE SENSITIVE. We need to be able > to turn this off if desired. (near) > - Only UNIX sites are included in the database. We don't yet have a > parser for VMS or VM sites (near) > - Exact match lookups (as opposed to regular expressions) are much faster > given the current database architecture. However the user interface > currently doesn't allow access to this feature (near) > - Don't provide a list of sites currently maintained (near) > - Cannot limit searches to specific sites... hopefully using regular > expressions to specify the site names (eg "prog *kcl *.de" will find > the kcl sites from among the German archive sites) (near) > - Retrieval scripts are brain-damaged (near) > - No email interface (hopefully near) > - No X11 interface (not quite so near) > One may now also use a pager on the output so that things don't go flying > past you as they did before. > > Currently we are not releasing the software which provides this service: > there still remains much work to be done on it and it is non-portable at > the moment. The aim was to get archie up and running and see what kind of > response we got before sending it out to the world at large. Even though > the database is now about half the size of the version of archie that we > have been running for the past couple of months... it still occupies > about 40 Mb and the updates and searches can still put a noticable load > on a Sun 4/280 which is doing little else. > > Other things? We hope to distribute archie to a few key sites around the > world. A few sites in Europe and North America have volunteered, and > having a few servers around would lessen the backbone load and ensure > reachability. Once we get a bit more code in place we plan to do this. A > GUI interface (for both Xwindows and maybe NeXTstep) would be nice. > > We welcome feedback, comments and suggestions from both satisfied and > unsatisfied customers and this can be sent to archie@cs.mcgill.ca. > ----------------------------------------------------------------------------- > Alan Emtage, "Ashore it's wine, women and song; > McGill University,CANADA abord it rum, bum and concertina" > -19th Century British Naval Saying > > INTERNET: bajan@cs.mcgill.ca UUCP: ...!mit-eddie!musocs!bajan > listmaster@cs.mcgill.ca > BITNET: bajan@musocs.BITNET > ----------------------------------------------------------------------------- From isaac@goanna.cs.rmit.OZ.AU Sun Jan 6 09:36:39 1991 Flags: 000000000001 Return-Path: Received: from goanna.cs.rmit.oz.au ([131.170.24.40]) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA24354; Sun, 6 Jan 91 16:35:29 MST Received: from localhost by goanna.cs.rmit.oz.au with SMTP. (5.61+++) id AA17235; Mon, 7 Jan 91 10:35:17 +1100 (from isaac for tex-archive@math.utah.edu) Message-Id: <9101062335.17235@goanna.cs.rmit.oz.au> To: tex-archive@math.utah.edu Subject: pub/tex/unix on labrea Date: Mon, 07 Jan 91 10:35:12 +1100 From: isaac@goanna.cs.rmit.OZ.AU Pardon the ignorance, but what is the need to retain this directory given that unix3.0 exists as well? From "Don Hosek " Fri Jan 11 03:29:32 1991 Flags: 000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10879; Sun, 13 Jan 91 11:28:52 MST Date: Sun, 13 Jan 1991 10:28 PST From: Don Hosek Subject: Re: Free TeX Primer Available for Anonymous FTP... To: JOE@oregon.uoregon.edu, nabtexm@tamvenus.BITNET, tex-archive@science.utah.edu Cc: tex-ed@uicvm.uic.edu Message-Id: <49D0F26D30E006D3@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: IN%"JOE@oregon.uoregon.edu" X-Vms-Cc: neil_burleson,tex_archive,in%"tex-ed@uicvm.uic.edu" Joe St. Sauver's primer for TeX on VMS is available from ymir.claremont.edu in the directory [anonymous.tex.documentation.oregon-primer] The file 00readme.txt in that directory has more information on the primer which can serve as a basis for a local introduction to TeX. Mailserv users can retrieve the files by sending messages to mailserv@ymir.claremont.edu with lines of the form SEND [TEX.DOCUMENATATION.OREGON-PRIMER]filename to retrieve the files. The first file that should be retrieved is 00files.txt which is a list of all files in the directory. -dh From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Sun Jan 13 17:43:50 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA28785; Wed, 16 Jan 91 01:33:35 MST Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA05369; Wed, 16 Jan 91 09:35:15 +0100 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA05943; Wed, 16 Jan 91 09:35:13 +0100 Date: Wed, 16 Jan 91 09:35:13 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9101160835.AA05943@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: TeX-archive@science.utah.edu Subject: XTeX I've made Xtex available at LISTSERV@DHDURZ1.BITNET, in DRIVER FILELIST. It's a uuencoded zoo file, split in six parts, called XTEX UAAZOO ... XTEX UAFZOO. I prefer it much over xdvi. Here's the README file: ---------------------------------------------------------------- This directory contains several tools to manipulate the DVI files produced by TeX and LaTeX. Additionally, it includes a re-distribution of the DVI library routines written by Chris Torek at the University of Maryland. The utilities included are: dviselect select specific pages from a DVI file iptex print a dvi file on an Imagen texx a dvi previewer for X-11 windows texsun a dvi previewer for SunView windows xtex a much improved dvi previewer for X-11 windows To install this package, read the documentation in the file doc/installation.tex. The short instructions follow. FOR xtex: + Change the binary path names in the ./Makefile. + Determine the fonts you'll be using. You have two options: (see subdirectory 'Fonts' for more information) (1) Using existing fonts (i.e. 300dpi) and ``shrink'' them to make them smaller. See xtex/build-initial-fonts for ideas on how to do this. This has the advantage that you don't need to generate any new Metafont fonts; however, the font's do match your screen resolution & are sort of hard to read. Also, you can only shrink things intergral (1/2, 1/3) amounts -- since TeX typically scales things by magsteps, this means you build two complete sets of your fonts in the two different mag sizes. (2) Using screen resolution fonts. On a Sun-3 lores (normal) display, this is 85dpi. This allows you to see things at actual size, measure junk on your display, etc. But, it takes about a day or two to generate all the fonts (you can cut down on this a lot if you know what you use). You can pick up 85dpi fonts from a.cs.uiuc.edu in pub/TeX/pk-85dpi.tar This also has the advantage that you follow the TeX magsteps; i.e. if you normally view things at mag 1000, you'll have fonts in mags 1000, 1098, 1200, 1440, 1728, 2074, 2489. If your ``large view'' is at mag 1440, you can ``double up'' your fonts by using 1728, 2074, 2489 and then adding e.g., 2989, 3587, etc. Don't worry if this doesn't make much sense, but you might ask a local TeX-guru to tell you why this is A Good Thing. In anycase, the ``complete set'' of 85dpi fonts in compressed SNF format is about 2.5Mb, which isn't bad. + Select a location for your ``font description'' file, and copy and modify the file in fontdesc-example to suit your local installation. Change the main makefile to use that path for variable FONTDESC The default is /usr/local/lib/tex82/fontdesc Note that you can use the fontdesc to partition metafont output based on DPI. + Edit the upper-level Imakefile. Do ``make Makefile'' followed by ``make Makefiles'' and ``make''. This should build all software selected by SUBDIRS in the main Imakefile + Once you've decided what kind of fonts you'll be using, edit xtex/xtex.ad to set the following values (I'm showing what we use). 85dpi 300dpi ----------------------------------- *.dpi: 85 300 *.mag: 1000 333 *.smallMag: 1000 333 *.largeMag: 1440 500 + if you are using the 300dpi (type 1 above) + in run xtex/mftobdf -mag 1000 -scaled 1000 cmr10. If mftobdf can't find your font, you've got a bad fontdesc file or the path to it is wrong. + assuming that this works, edit xtex/buildfonts to suit your local X configuration. I keep fonts in /usr/local/lib/X11/fonts/cmr, and have added this to my font path using % xset +fp /usr/local/lib/X11/fonts/cmr % xset fp rehash + in xtex, run "buildfonts -mag 500 `cat FONTS` " to build a fair number of standard fonts. Note that the default is 300 dpi. If you want a smaller set too, say ``-mag 333''. + if you are using the 85dpi (type 2 above) + cd to Fonts + run ``make fonts'' + after everything is built, move all the .snf.Z files and the font.dir files to a directory that everyone can access. You could include this in your default font path. + test the system out by storing xtex.ad in the proper place, using ``make install'' in the xtex directory, and viewing a .dvi file + You can use other DPI's -- both xtex & mftobdf have switches for this. TeXSun is known to work on: Sun-3/monochrome (normal & hires) Sun-3/color Sun-4/monochome (normal & hires) xtex is known to work on: Sun-3/monochome (normal & hires) PC/RT/monochome Silicon Graphics 4D/20 You need to add "-I/usr/include/bsd" to the CFLAGS line when compiling the X11 code. You also need to use "-law -lXt -lX11 -lbsd -lm" for linking. Vaxstation, DECstation-3100 Sun-4/Monochrome normal res. Gould NPS1 NUX/32 Encore Multimax Dirk Grunwald Univ. of Colorado at Boulder grunwald@foobar.colorado.edu grunwald@colorado.edu From "Don Hosek " Fri Jan 18 06:12:28 1991 Flags: 000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09176; Sun, 20 Jan 91 14:11:44 MST Date: Sun, 20 Jan 1991 13:11 PST From: Don Hosek Subject: Oregon TeX primer To: tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: TEX_ARCHIVE The copy of the file TEX_PRIMER.TEX on ymir.claremont.edu has been edited so that no line is greater than 80 chars (for those retrieving the file by mail). If you have retrieved this file, you may wish to get the updated version. No changes to the text were made --- Don Hosek To retrieve files from ymir via the | dhosek@ymir.claremont.edu mailserver, send a message to | Quixote TeX Consulting mailserv@ymir.claremont.edu with a | 714-625-0147 line saying send [DIRECTORY]FILENAME where DIRECTORY is the FTP directory (sans "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt Binary files are not available by this technique. From "karl@cs.umb.edu (Karl Berry)" Thu Feb 28 11:46:04 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10748; Thu, 28 Feb 91 11:46:02 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA10316; Thu, 28 Feb 91 13:45:47 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA08955; Thu, 28 Feb 91 13:44:31 EST Date: Thu, 28 Feb 91 13:44:31 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9102281844.AA08955@ra.cs.umb.edu> To: tex-archive-request@math.utah.edu Subject: [MAILER%DBIUNI19@CUNYVM.CUNY.EDU: Undelivered mail] Reply-To: karl@cs.umb.edu I've never seen this one before! Received: from cs.umb.edu by ra.cs.umb.edu (4.1/1.34) id AA08624; Thu, 28 Feb 91 13:30:54 EST Received: from CUNYVM.CUNY.EDU by cs.umb.edu (4.1/1.34) id AA09776; Thu, 28 Feb 91 13:32:01 EST Message-Id: <9102281832.AA09776@cs.umb.edu> Received: from DBIUNI19.UNI-BIELEFELD.DE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4058; Thu, 28 Feb 91 13:32:07 EST Received: by DBIUNI19 (Mailer R2.07) id 7139; Thu, 28 Feb 91 19:31:54 SET Date: Thu, 28 Feb 91 19:31:52 SET From: Network Mailer Subject: Undelivered mail To: Your mail was not delivered to some or all of its intended recipients for the following reason(s): No recipients for this node. --------------------RETURNED MAIL FILE-------------------- Received: from MITVMA(MAILER) by DBIUNI19 (Mailer R2.07) id 7138; Thu, 28 Feb 91 19:31:52 SET Received: from MITVMA by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 1409; Thu, 28 Feb 91 12:23:19 EST Received: from math.utah.edu by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with TCP; Thu, 28 Feb 91 12:23:14 EST Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10338; Thu, 28 Feb 91 10:19:50 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA07874; Thu, 28 Feb 91 12:19:36 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA07298; Thu, 28 Feb 91 12:18:24 EST Date: Thu, 28 Feb 91 12:18:24 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9102281718.AA07298@ra.cs.umb.edu> To: tex-archive@math.utah.edu Subject: Metafont modes Reply-To: karl@cs.umb.edu I have collected all the Metafont modes I could find, with Doug Henderson's help, and also auxiliary definitions for write-write printers, GF specials, etc., etc. I hope people will start using this as their ``local'' file. It's on ftp.cs.umb.edu [192.12.26.23] in pub/tex/modes.mf. karl@cs.umb.edu From "karl@cs.umb.edu (Karl Berry)" Tue Mar 12 11:35:16 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05060; Tue, 12 Mar 91 11:30:38 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA02326; Tue, 12 Mar 91 13:11:54 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA19640; Tue, 12 Mar 91 13:28:00 EST Date: Tue, 12 Mar 91 13:28:00 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103121828.AA19640@ra.cs.umb.edu> To: tex-archive@math.utah.edu Subject: Michael Ferguson's \charsubdef extension to TeX Reply-To: karl@cs.umb.edu I have put an updated version of the files relating to Michael Ferguson's \charsubdef extension to TeX (which allows hyphenation of accented characters, among other things) on ftp.cs.umb.edu [192.12.26.23], in pub/tex/charsubdef.tar.Z. karl@cs.umb.edu From "karl@cs.umb.edu (Karl Berry)" Thu Mar 14 11:32:08 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA19081; Thu, 14 Mar 91 11:29:12 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA20336; Thu, 14 Mar 91 13:26:21 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA27786; Thu, 14 Mar 91 13:26:15 EST Date: Thu, 14 Mar 91 13:26:15 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103141826.AA27786@ra.cs.umb.edu> To: tex-archive@math.utah.edu Subject: revision to charsubdef Reply-To: karl@cs.umb.edu Michael Ferguson just sent me a minor revision to one of the files in his charsubdef extension, so I've updated ftp.cs.umb.edu [192.12.26.23], pub/tex/charsubdef.tar.Z. karl@cs.umb.edu From "Oren Patashnik " Fri Mar 15 10:25:05 1991 Flags: 000000000001 Return-Path: Received: from Neon.Stanford.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA26278; Fri, 15 Mar 91 10:24:16 MST Received: by Neon.Stanford.EDU (5.61/25-eef) id AA00801; Fri, 15 Mar 91 09:24:14 -0800 Date: Fri, 15 Mar 91 9:24:13 PST From: Oren Patashnik To: tex-archive@math.utah.edu Subject: New version of the btxmac macros Message-Id: The current version of file btxmac.tex (which contains the macros that let you use BibTeX with plain TeX) is 0.99g. It's available via FTP >From area .../tex/bibtex on labrea.stanford.edu. --Oren From "mackay@cs.washington.edu (Pierre MacKay)" Sun Mar 24 17:23:48 1991 Flags: 000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25557; Sun, 24 Mar 91 17:22:54 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA24740; Sun, 24 Mar 91 16:22:47 -0800 Date: Sun, 24 Mar 91 16:22:47 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103250022.AA24740@june.cs.washington.edu> To: opbibtex@Neon.Stanford.EDU Cc: tex-archive@math.utah.edu In-Reply-To: Oren Patashnik's message of Fri, 15 Mar 91 9:24:13 PST Subject: New version of the btxmac macros That will be deeply appreciated. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 From "George D. Greenwade " Mon Mar 25 09:33:16 1991 Flags: 000000000001 Return-Path: Received: from post-office.uh.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA29468; Mon, 25 Mar 91 09:33:13 MST Received: from SHSU.BITNET (MXMAILER@SHSU) by Post-Office.UH.EDU with PMDF#10188; Mon, 25 Mar 1991 10:32 CST Received: by SHSU.BITNET (MX V2.2-1) id 14908; Mon, 25 Mar 1991 10:32:23 CST Date: Mon, 25 Mar 1991 10:32:23 CST From: "George D. Greenwade" Subject: Status of SHSU archives To: beebe@math.utah.edu Message-Id: <00946215.213788E0.14908@SHSU.BITNET> > Glad to have you on the tex-archive list. How soon will your Internet > connection be in place? How to do plan to keep a mirror of Aston > up-to-date? Nelson: Thanks for including me on the list (I feel as if I am sending this to one of the TeX gods, please pardon any quivering I may be showing 8-)). The Internet connection is in place currently in beta mode. We have very limited access presently for some tests we are running. I expect that the lines will be opened prior to the end of April unless something strange comes up. The new line directly links to a new mVAX dedicated to communications and operates at 56kB (a significant improvement over 9600 baud!). Our connection is via the U.Texas M.D.Anderson Health Sciences Center (one hop from Rice, so we are effectively on the BITNET/CREN backbone, as well). We plan on having a T1 line in place prior to March 1993, and have a committal to link directly to Rice on that. Brian {H.K.} and I have been discussing how to best handle updates. What we have tentatively worked out is a transfer of the "last 7 days" files between TeX.ac.uk and shsu.edu. We still have some work to do here to get an accurate last 7 days file automatically generated, but that will be easily overcome. Ken Selvia (in our Computer Services) is presently working on a VMS command file to ftp interface our sites for direct off-hours transmittal and receipt of updates, based on the last 7 days files (probably on Saturdays). In all likelihood, these will be compressed VVENCODEd files which we will uncompress and VVDECODE at each site. A significant benefit is the fact that we are both operating on VMS platforms. Any other questions, comments, or suggestions will be more than welcomed. Thanks again for including me on tex-archive! Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg%shsu.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "George D. Greenwade " Sun Apr 7 16:44:52 1991 Flags: 000000000001 Return-Path: Received: from post-office.uh.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA11112; Sun, 7 Apr 91 16:42:24 MDT Received: from SHSU.BITNET (MXMAILER@SHSU) by Post-Office.UH.EDU with PMDF#10188; Sun, 7 Apr 1991 17:41 CDT Received: by SHSU.BITNET (MX V2.2-1) id 3712; Sun, 07 Apr 1991 16:40:59 CDT Date: Sun, 07 Apr 1991 16:40:59 CDT From: "George D. Greenwade" Subject: Georg Denk's eslides.sty set available To: tex-archive@math.utah.edu Message-Id: <00946C7F.C68F3EE0.3712@SHSU.BITNET> Wanted to announce that Georg Denk has forwarded me the files associated with his TUGboat article (V11, #2, 1990) "An Easy Way Making Slides With LaTeX". They are available from STYle collection I keep at FILESERV@SHSU.BITNET. Forward/edit the following four SENDME lines to FILESERV and you should get the full distribution for this: SENDME STY.ESLIDES SENDME STY.ESLIDES_TEX SENDME STY.ESLIDES-EXAMPLE.TEX SENDME STY.ESLIDES-LOGO-DENK STY.ESLIDES is eslides.sty (the style file; 13 512-byte blocks); STY.ESLIDES_TEX is eslides.tex (the text of the TUGboat article; 18 blocks); STY.ESLIDES-EXAMPLE.TEX is eslides-example.tex (an example of use; 7 blocks); STY.ESLIDES-LOGO-DENK is a picture environment of Denk's \logo for use as an example -- Denk defined \logo as null in eslides.sty so one would have to intentionally define their own logo. Also of interest (maybe) is a set of three brand new files the author (Martin Ward) forwarded to me which can be retrieved by forward/editing the next three SENDME lines to FILESERV (in the same message for ESLIDES, if you wish): SENDME STY.PROGRAM-DEMO_TEX SENDME STY.PROGRAM_1OF2 SENDME STY.PROGRAM_2OF2 STY.PROGRAM_1OF2 (30 blocks) and STY.PROGRAM_2OF2 (10 blocks) need to be concatenated and retained as program.sty. program.sty does some interesting things to tabs in a program environment for listing of programs (among other things). STY.PROGRAM-DEMO_TEX (13 blocks) should be saved as program-demo.tex, a demonstration of program.sty. Hope I haven't abused bandwidth by announcing these on tex-archive; if so, please advise me directly. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg%shsu.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Tue Apr 9 12:43:14 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA23056; Tue, 9 Apr 91 12:38:52 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA17164; Tue, 9 Apr 91 20:37:49 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA16410; Tue, 9 Apr 91 20:37:46 +0200 Date: Tue, 9 Apr 91 20:37:46 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9104091837.AA16410@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: tex-archive@math.utah.edu Subject: changebar (was: Contribution for TeX server / distribution) Joachim Schrod wrote: BTW: If you know other archive sites (besides those listed in the mail header) which might be interested, you should include a respective mail address in your note. (I installed them on the Bitnet Listserver listserv@ddathd21.bitnet [filelist ttools] already.) ^^^^^^^^ nonono, it's DHDURZ1.bitnet Dr. Rainer Schoepf Konrad-Zuse-Zentrum ,,Ich mag es nicht, wenn fuer Informationstechnik Berlin sich die Dinge so frueh Heilbronner Strasse 10 am Morgen schon so D-1000 Berlin 31 dynamisch entwickeln!'' Federal Republic of Germany or From "George D. Greenwade " Tue Apr 9 13:22:46 1991 Flags: 000000000001 Return-Path: <@MATH.AMS.COM,@post-office.uh.edu:bed_gdg@SHSU.BITNET> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA23401; Tue, 9 Apr 91 13:22:36 MDT Received: from post-office.uh.edu by MATH.AMS.COM via SMTP with TCP; Tue, 9 Apr 91 15:10:00-EDT Received: from SHSU.BITNET (MXMAILER@SHSU) by Post-Office.UH.EDU with PMDF#10188; Tue, 9 Apr 1991 14:09 CDT Received: by SHSU.BITNET (MX V2.2-1) id 6915; Tue, 09 Apr 1991 13:56:39 CDT Date: Tue, 09 Apr 1991 13:56:39 CDT From: "George D. Greenwade" Subject: RE: security To: tex-implementors@math.ams.com Message-Id: <00946DFB.28BD71A0.6915@SHSU.BITNET> The security discussion is fascinating, but there is one major assumption being made which needs to be considered. How many TeX users out there on multiuser platforms really understand even a part of what this discussion focuses on? I may be at a very unique university, but most of our users see (La)(AMS)TeX as a document processor and nothing more. For example, few have any idea about how tables of contents are created in LaTeX -- they just know it is done (of course, by writing to a jobname.toc file). If you hit most of our users with a style file or a macro which they \include'd or \input, they could no more explain how it does what it does than they could explain the properties of cold fusion (which no one can explain). Even if the filenames were output to screen, most would have no idea what the message was even about, much less what to do if they saw it! I don't personally see any need to re-write the code for the sources as TeX is really nothing more than an extraordinarily impressive IO language. Now, if someone DID know how to write the code and distributed it, that author has created a system manager's problem. You can't preclude that without major revisions in the underlying source. These underlying changes in the source could easily increase overhead in an already IO-intense environment, possibly reduce some flexibility, and would still be, for the most part, site-specific and system-dependent. Speaking now as an archive maintainer, I do look for anything which points to a \write-type statement before putting it up for access. I'm not 100% sure I am not distributing viruses and never will be. My methodology for testing is two-phase: first, I search for strings which could be suspect, especially in deeply nested definitions; second, I use the VMS option SET WATCH FILES/CLASS=ALL and run the file. After 15 iterations of small files and up to 50 iterations on complex files using various permutations of the commands defined in the style, along with various other input files, if I haven't seen something strange by then, I think there is a pretty good chance that there isn't a problem. The real problem is getting system administrators/managers to properly write protect files which are mission critical and not with a recoding of TeX. I think that it is important to point out to these individuals that TeX is an IO language (if they haven't already figured that out) and that the use of *all* IO languages on their system exposes them to potential risk. >From a computer non-professional, and with apologies if I have said something really dumb due to this status, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg%shsu.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "karl@cs.umb.edu (Karl Berry)" Tue Apr 9 13:48:43 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA23571; Tue, 9 Apr 91 13:43:31 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA18587; Tue, 9 Apr 91 14:43:18 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA01032; Tue, 9 Apr 91 15:42:16 EDT Date: Tue, 9 Apr 91 15:42:16 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9104091942.AA01032@ra.cs.umb.edu> To: tex-archive@math.utah.edu Subject: macros for change bars Reply-To: karl@cs.umb.edu Joachim Schrod has sent me some macros to do changebars. I haven't tried them, but the stuff does unpack. It's on ftp.cs.umb.edu [192.12.26.23] in pub/tex/chbar.tar.Z. The relevant part of the mail from him follows. karl@cs.umb.edu From: XITIJSCH%DDATHD21.BITNET@CUNYVM.CUNY.EDU This archive contains macros for the insertion of changebars WITHOUT ANY \special's. Up to now it may only be used with Plain TeX. The macros were presented by me at the EuroTeX89 conference in Karlsruhe. They were now brought back to my attention because some people have asked me for them. Please note, that the archive name chbar.tar.Z instead of changebars.tar.Z is intentional as the second name is not POSIX compliant and makes difficulties on System V's. (I installed them on the Bitnet Listserver listserv@ddathd21.bitnet [filelist ttools] already.) From "George D. Greenwade " Wed Apr 10 10:41:31 1991 Flags: 000000000001 Return-Path: Received: from post-office.uh.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05580; Wed, 10 Apr 91 10:40:37 MDT Received: from SHSU.BITNET (MXMAILER@SHSU) by Post-Office.UH.EDU with PMDF#10188; Wed, 10 Apr 1991 11:40 CDT Received: by SHSU.BITNET (MX V2.2-1) id 8776; Wed, 10 Apr 1991 11:40:36 CDT Date: Wed, 10 Apr 1991 11:40:36 CDT From: "George D. Greenwade" Subject: Filenames - recommendation To: tex-archive@math.utah.edu Message-Id: <00946EB1.4F5AE200.8776@SHSU.BITNET> Donald Arseneau or submitted five style files to me today which are updates of prior work (cite.sty, overcite.sty, tabls.sty, and ulem.sty) and one new file (draftcite.sty). These are all in testing right now to verify that they work and we have the right (uncorrupted) code. I will post something to INFO-TeX (hence, to comp.text.tex) once this is finished telling where they are available and how to get them. If you don't have comp.text.tex and aren't subscribed to INFO-TeX (shame on you, in either case) or don't see a post on this in the next few days, let me know directly and I will send you the information. How does this tie to my Subj: line? Simple. The new file, draftcite.sty, has a filename which is, by default, incompatible with DOS and VM systems. I have asked Donald to consider renaming the file drftcite.sty to stay within the filename and extension limitations of 8 and 3, respectively. It may be because I (shamelessly) advertise FILESERV that I have gotten the responses I have, but more than a few (i.e., 37) people have corresponded and asked why some of the "Save file as:" suggested.filename at the top of FILESERV's files don't meet the 8 and 3 limitations of their OS. This is principally attributable to the exponential growth of emTeX under PC/MS-DOS. My only response to these "inquiring minds" is that I am suggesting the standard filename found on the servers and archives around the world (which I am). Is there any way to control this? I will specifically ask authors of all non-conforming new submissions which come in via the address STY-Mgr@SHSU.BITNET to stay within this limit (and if the author says "no", then the name stays as is -- can't force this). I know that some of the "old time standards" out there, such as doublespace.sty, can probably never be easily changed to another filename, but is there any mecahnism by which the 8 and 3 can be suggested when you get submissions of new files? I recognize that flexible-filename operating systems (Unix/Ultrix, VMS,...) aren't subject to this, but a growing segment of TeX use is emTeX (a great package!), which does face 8 and 3. This may be a nebulous concern, but it is one I hope you will think of as you accept and add files. Anyone know how this can be enforced or how "old time standards" can at least get an 8-character "quasi-standard" consistent variation for the systems locked into filename limitations? I am not asking to head up anything on this, but it would be nice if an alternate for long file names could be worked up so that, say, a consistent variation of doublespace were 2space (which I am unilaterally suggesting to inquirers, by the way; is there something else which is standard on this?). Anyway, look for the announcement on the files and continue to think of me as worried about something beyond worrying about..... 8-) Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg%shsu.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "JANET TEX@UK.AC.CRANFIELD.RMCS " Thu Apr 11 11:07:50 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA12614; Thu, 11 Apr 91 11:05:56 MDT Received: from rmcs.cranfield.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <17417-1@sun2.nsfnet-relay.ac.uk>; Thu, 11 Apr 1991 17:17:44 +0100 Date: Thu, 11 APR 91 12:06:09 BST From: TEX@rmcs.cranfield.ac.uk To: tex-archive <@nsfnet-relay.ac.uk:tex-archive@MATH.UTAH.edu> Subject: RE: (702) Filenames - recommendation Actually-To: Sender: JANET "TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <00000AA4_0017C338.00946F7E09F83140$12_3@UK.AC.CRANFIELD.RMCS> Reply-To: Brian {Hamilton Kelly} Originally-To: CBS%UK.AC.NSFNET-RELAY::BITNET.SHSU::BED_GDG,CBS%UK.AC.TEX::ARCHIVE-GROUP Originally-From: TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) In message <00946EB1.4F5AE200.8776@SHSU.BITNET> of Wed, 10 Apr 1991 11:40:36 CDT (originally to ), "George D. Greenwade" wrote: > How does this tie to my Subj: line? Simple. The new file, draftcite.sty, > has a filename which is, by default, incompatible with DOS and VM systems. > I have asked Donald to consider renaming the file drftcite.sty to stay > within the filename and extension limitations of 8 and 3, respectively. It > may be because I (shamelessly) advertise FILESERV that I have gotten the > responses I have, but more than a few (i.e., 37) people have corresponded > and asked why some of the "Save file as:" suggested.filename at the top of > FILESERV's files don't meet the 8 and 3 limitations of their OS. This is > principally attributable to the exponential growth of emTeX under > PC/MS-DOS. My only response to these "inquiring minds" is that I am > suggesting the standard filename found on the servers and archives around > the world (which I am). > > Is there any way to control this? I will specifically ask authors of all > non-conforming new submissions which come in via the address > STY-Mgr@SHSU.BITNET to stay within this limit (and if the author says "no", > then the name stays as is -- can't force this). I know that some of the > "old time standards" out there, such as doublespace.sty, can probably never > be easily changed to another filename, but is there any mecahnism by which > the 8 and 3 can be suggested when you get submissions of new files? I > recognize that flexible-filename operating systems (Unix/Ultrix, VMS,...) > aren't subject to this, but a growing segment of TeX use is emTeX (a great > package!), which does face 8 and 3. I don't think this is a consideration that's significant, either to archivists or to users. At Aston, we have taken the conscious decision to use the most descriptive filename possible; when people transfer files to their systems, they are almost certain to have some mechanism by which they may specify an abbreviated name that is meaningful to them. The only exception to this rule is that files intended for a particular operating system, such as MS-DOS, conform to the conventions of that system, at least, to the extent to which they can be represented under the VMS operating system used at the Aston Archive. So there are, for example, boo-encoded archives of files intended for MS-DOS, and these usually have names that conform to 8+3; obviously the files contained within these archives will have file names conformant to MS-DOS, because that's how they were generated in the first place. (An example of a system-specific file name that cannot be represented under VMS is the Unix tar archive, with a name of the form archive.tar.Z under Unix, that has to be held under VMS as ARCHIVE.TAR_Z) One other class of files at Aston are the 00files.txt which appear in every subdirectory (and the 00readme.txt that appear in some); we decided to make these names conform to 8+3 to reduce the amount of `fetch file xxx as yyy' operations required by these poor benighted people. I see no reason why the file you mention shouldn't go into your archive as `draftcite.sty': when referenced in the \documentstyle options, it should always be called as `draftcite', regardless of whether the file has been stored as `draftcite.sty' (under Unix), `DRAFTCITE.STY' (under VMS) or even as `DRAFTCIT.STY' (under MS-DOS --- the latter will always quietly truncate filenames that don't meet the 8+3 criterion). The only potential problem is if someone else comes up with a `draftcitation' style option. > This may be a nebulous concern, but it is one I hope you will think of as Yes! Brian HK From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Thu Apr 11 11:42:04 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA12867; Thu, 11 Apr 91 11:38:18 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA21394; Thu, 11 Apr 91 19:38:00 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA21154; Thu, 11 Apr 91 19:37:56 +0200 Date: Thu, 11 Apr 91 19:37:56 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9104111737.AA21154@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: TeX@rmcs.cranfield.ac.uk Cc: tex-archive@math.utah.edu, info-tex@shsu.bitnet, PZF5HZ@RUIPC1E.bitnet In-Reply-To: TEX@rmcs.cranfield.ac.uk's message of Thu, 11 APR 91 12:06:09 BST <00000AA4_0017C338.00946F7E09F83140$12_3@UK.AC.CRANFIELD.RMCS> Subject: RE: (702) Filenames - recommendation Brian Hamilton Kelly writes in answer to George D. Greenwade's message about file names: I don't think this is a consideration that's significant, either to archivists or to users.files to their systems, they are almost certain to have some mechanism by which they may specify an abbreviated name that is meaningful to them. The only exception to this rule is that files intended for a particular operating system, such as MS-DOS, conform to the conventions of that system, at least, to the extent to which they can be represented under the VMS operating system used at the Aston Archive. So there are, for example, boo-encoded archives of files intended for MS-DOS, and these usually have names that conform to 8+3; obviously the files contained within these archives will have file names conformant to MS-DOS, because that's how they were generated in the first place. (An example of a system-specific file name that cannot be represented under VMS is the Unix tar archive, with a name of the form archive.tar.Z under Unix, that has to be held under VMS as ARCHIVE.TAR_Z) I think his point of view is wrong, for two reasons: the first is rather technical, but significant: in some versions of the Novel network on PCs the extra characters in the file name are not ignored. Example: TeX tries to read twocolumn.sty, on the disk it's called twocolum.sty, and with Novel running, it cannot find it. That's a pain! I assume you can find similar behaviour on other systems as well. The second reason is more basic: one of the basic ideas behind TeX is its portability and that does also mean that those files that can be exchanged, like TeX input files, LaTeX style files, etc. should have the same name on all machines. Otherwise you will end up with the situation that people write \documentstyle[doublesp]{article} (and why not, if that's the name of the file on their system!), and suddenly it does no longer run on systems with long file names. I agree that 8+3 characters stiffles creativity and that it's a bad design decision, BUT it's THE standard. I think I can safely say that the number of TeX users on MS-DOS and similar systems far exceeds the number of those on all other systems together. We, who are blessed with better machines tend to forget that we are only a minority. So, we have to settle for the only thing that can be used on all systems, and that's 8+3 (notwithstanding the fact that TeX was developed on a machine with 6+3, but which is now practically extinct). One thing I can say by now is that the new LaTeX will conform to this. Rainer Sch\"opf Dr. Rainer Schoepf Konrad-Zuse-Zentrum ,,Ich mag es nicht, wenn fuer Informationstechnik Berlin sich die Dinge so frueh Heilbronner Strasse 10 am Morgen schon so D-1000 Berlin 31 dynamisch entwickeln!'' Federal Republic of Germany or From "George D. Greenwade " Thu Apr 11 13:47:15 1991 Flags: 000000000001 Return-Path: Received: from post-office.uh.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA13432; Thu, 11 Apr 91 13:46:15 MDT Received: from SHSU.BITNET (MXMAILER@SHSU) by Post-Office.UH.EDU with PMDF#10188; Thu, 11 Apr 1991 14:45 CDT Received: by SHSU.BITNET (MX V2.2-1) id 11653; Thu, 11 Apr 1991 14:46:36 CDT Date: Thu, 11 Apr 1991 14:46:36 CDT From: "George D. Greenwade" Subject: REVTeX version 2.0 To: tex-archive@math.utah.edu Message-Id: <00946F94.75B95420.11653@SHSU.BITNET> I've been working with Chris Hamlin of the American Physical Society on getting their REVTeX, version 2.0, up and available for network access. I am aware that labrea and at least one other site (ymir, Don?) are also "official" retrieval sites, as well. Chris asked me to pass this along to this group and to request that if you have any old versions of REVTeX in your archive (on or about March, 1991, is the release date for v 2.0), to please remove them as they are not consistent with what the APS will accept in the very near future. If you would like to retrieve the REVTeX package of macros, niord.shsu.edu now supports anonymous ftp, and the files are all in the directory [FILESERV.REVTEX] (on ftp retrieval, you will need to correct for FILESERV's package quirkiness by removing the REVTEX filename and saving according to the extension; i.e., the file REVTEX.APS10_STY should be stored as APS10.STY). If you wish to retrieve this package via mail, please include the command SENDME REVTeX in the body of a mail message addressed to FILESERV@SHSU.BITNET. Even if you don't wish to get these, if you have any pre-March, 1991, REVTeX files in your repository, please remove them as soon as possible as they are outdated. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg%shsu.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "Karl Berry " Thu Apr 11 18:51:37 1991 Flags: 000000000001 Return-Path: Received: from RELAY.CS.NET by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA14732; Thu, 11 Apr 91 18:49:27 MDT Received: from cs.umb.edu by RELAY.CS.NET id aa26001; 11 Apr 91 20:23 EDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA04871; Thu, 11 Apr 91 19:22:56 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA06919; Thu, 11 Apr 91 20:21:39 EDT Date: Thu, 11 Apr 91 20:21:39 EDT From: Karl Berry Message-Id: <9104120021.AA06919@ra.cs.umb.edu> To: schoepf%sc.zib-berlin.de@RELAY.CS.NET Cc: TeX%rmcs.cranfield.ac.uk@RELAY.CS.NET, tex-archive%math.utah.edu@RELAY.CS.NET, PZF5HZ%ruipc1e.bitnet@RELAY.CS.NET In-Reply-To: Rainer Schoepf's message of Thu, 11 Apr 91 19:37:56 +0200 <9104111737.AA21154@sc.zib-berlin.dbp.de> Subject: (702) Filenames - recommendation Reply-To: karl%cs.umb.edu@RELAY.CS.NET Rainer> I agree that 8+3 characters stiffles creativity and that it's a bad > design decision, Yes. > BUT it's THE standard. Least common denominator, anyway. > I think I can safely say that the number of TeX users on MS-DOS and > similar systems far exceeds the number of those on all other systems > together. I've heard this claim before, but never any numbers. I have one substantive comment to make: the problem of arbitrary length filenames could be fixed by introducing a mapping file layer between TeX and the operating system. Then the names in the .tex files could be fully descriptive, and the operating system names could be whatever they have to do. This is the same suggestion I made for font files a while back. I realize this is not a panacea. But it does make it at least possible for .tex files to be portable in the one major way in which they are not now -- filenames. From "Don Hosek " Wed May 22 19:45:33 1991 Flags: 000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25998; Wed, 22 May 91 19:44:42 MDT Date: Wed, 22 May 1991 18:44 PDT From: Don Hosek Subject: UPLOAD: EGA2MF To: TEX-GROUP@HMCVAX.CLAREMONT.EDU, texhax@cs.washington.edu, info-tex@shsu.bitnet, tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: tex-group,texhax,in%"info-tex@shsu.bitnet",tex_archive Thomas Ridgeway's EGA2MF package has been placed in the ymir.claremont.edu archive in the directory [anonymous.tex.mf.ega2mf]. The package includes programs for converting EGA and VGA bitmaps to MF code, several fonts, and the MF code for a PC font based on the EGA bitmaps. The file 00readme.txt in that directory has more information. Note that all *.ega and *.vga files are binary and cannot be retrieved by the mailserver. Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Wed May 22 20:07:15 1991 Flags: 000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26308; Wed, 22 May 91 20:04:03 MDT Date: Wed, 22 May 1991 19:03 PDT From: Don Hosek Subject: UPLOAD: rmacro.sty--macros for Russian typesetting in LaTeX To: TEX-GROUP@HMCVAX.CLAREMONT.EDU, texhax@cs.washington.edu, tex-archive@science.utah.edu, info-tex@shsu.BITNET Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: tex-group,texhax,tex_archive,in%"info-tex@shsu" Updated versions of rmacro.sty received from the author are now available from ymir.claremont.edu. Two versions are available. rmacro.sty assumes that the Mittelbach & Schoepf font selection scheme (available from ymir in [anonymous.tex.inputs.latex-mainz]) is used while rmacro.sty-old assumes that the default font selection scheme is used. If these macros are to be used with russian.sty (also available from ymir), they should be renamed to cyrillic.sty Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Wed May 22 20:12:10 1991 Flags: 000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26380; Wed, 22 May 91 20:11:16 MDT Date: Wed, 22 May 1991 19:10 PDT From: Don Hosek Subject: UPLOAD: version.sty--LaTeX macros for excluding or including portions of text To: TEX-GROUP@HMCVAX.CLAREMONT.EDU, texhax@cs.washington.edu, tex-archive@science.utah.edu, info-tex@shsu.BITNET Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: tex-group,texhax,tex_archive,in%"info-tex@shsu" version.sty has been installed on ymir.claremont.edu in [anonymous.tex.inputs.latex-contrib]. The following is from the documentation: % Version control macros. These let you define environments whose contents % will be optionally added to or deleted from the text when you run LaTeX. % Usage: place either of the following near the start of your file: % \includeversion{NAME} % \excludeversion{NAME} % Here, "NAME" is any name you choose. The first one indicates that text % between \begin{NAME} and \end{NAME} will be processed in the normal way. % The second indicates that text between \begin{NAME} and \end{NAME} will % be totally deleted. % You can define environments for as many versions as you want. % A ``comment'' environment has already been pre-defined for you with % \excludeversion{comment}; you can override this using \includeversion. % % Example: % \includeversion{abridged}\excludeversion{unabridged} % Text for the % \begin{abridged} % short % \end{abridged} % \begin{unabridged} % long and really longwinded, opaque and boring % \end{unabridged} % version of the paper. Punctuation works correctly\begin{unabridged} % because sphack is used\end{unabridged}. % \begin{comment} This is deleted by default. \end{comment} The macros are attributed to Stephen Bellanton and were posted to comp.text.tex on 12 May 1991. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Wed May 22 21:15:47 1991 Flags: 000000000001 Return-Path: Received: from LINUS.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26715; Wed, 22 May 91 21:15:05 MDT Date: Wed, 22 May 1991 20:14 PDT From: Don Hosek Subject: UPLOAD: TeXdraw--macros for drawing PostScript diagrams with TeX. To: TEX-GROUP@HMCVAX.CLAREMONT.EDU, texhax@cs.washington.edu, tex-archive@science.utah.edu, info-tex@shsu.BITNET Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: tex-group,texhax,tex_archive,in%"info-tex@shsu" TeXdraw 1.3 has been installed on ymir.claremont.edu in [anonymous.tex.graphics.texdraw] and its subdirectories. It was obtained by anonymous FTP from aldebaran.insl.mcgill.ca on 22-May-1991. The following is extracted from the documentation: ////// The TeXdraw package consists of a set of macro definitions for the TeX typesetting program. These macros allow the user to produce PostScript drawings from within TeX. The main benefits of TeXdraw accrue from the ability to produce drawings >From TeX, using TeX fonts for labelling the drawing. TeXdraw interfaces with the dvips (dvi to PostScript) print program. Basic drawing features include: (1) moves, lines and arrow vectors - selectable gray level, line width pattern, arrowhead size and type (2) circles, ellipses, arcs, and Bezier curves (3) general fill command to fill a region defined by lines and Bezier curves (selectable gray level) (4) TeX text, including mathematics, can be positioned and superimposed on the drawing TeXdraw has been designed to be extensible. Drawing "segments" are relocatable, self-contained units. Using a combination of the begingroup/ endgroup mechanism in TeX and the gsave/grestore mechanism in PostScript, drawing segments allow for local changes to the scaling and line parameters. Using TeX's macro definition capability, new drawing commands can be constructed from drawing segments. The extensibility features include, (1) relocatable drawing segments to keep changes local (2) local segment scaling (3) saving and restoring positions using symbolic positions \\\\\\\ -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Wed May 22 21:20:32 1991 Flags: 000000000001 Return-Path: Received: from LINUS.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26741; Wed, 22 May 91 21:19:57 MDT Date: Wed, 22 May 1991 20:19 PDT From: Don Hosek Subject: UPLOAD: PopInput--resident input enhancer for TeX on MS-DOS To: texhax@cs.washington.edu, tex-archive@science.utah.edu, info-tex@shsu.BITNET Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: texhax,tex_archive,in%"info-tex@shsu" PopInput is available from ymir.claremont.edu as popinput.zip in [anonymous.tex.ibm_pc.misc]. The file was retrieved from wsmr-simtel20.army.mil on 22-May-1991. Please note that this is a binary file and cannot be retrieved via mailserv. The following is extracted from the documentation: >PopInput is a program for input of characters to your editor by the >use of a pop-up window. It is especially useful for TeX where it >can be used together with a user designed font. It provides for the >possibility of representing an arbitrary length TeX macro by one >user defined character on the screen, and a user friendly way of >inputing this character. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Wed May 22 21:43:04 1991 Flags: 000000000001 Return-Path: Received: from LINUS.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26781; Wed, 22 May 91 21:42:24 MDT Date: Wed, 22 May 1991 20:41 PDT From: Don Hosek Subject: UPLOAD: Shalom--PostScript font for printing Hebrew To: texhax@cs.washington.edu, tex-archive@science.utah.edu, info-tex@shsu.BITNET, ivritex@taunivm.BITNET Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: texhax,tex_archive,in%"info-tex@shsu",in%"ivritex@taunivm" Shalom is a type 3 public domain Hebrew PostScript font written by Jonathan Brecher. It is available from ymir.claremont.edu in [anonymous.tex.babel.hebrew.fonts-ps-shalom]. Included is a PL file which can be converted into a TFM for use with TeX. The files were FTP'd from shum.huji.ac.il on 22-May-1991. The following is quoted from a message to ivritex: >...we have "discovered" a public domain type 3 >Hebrew PostScript font, written by Jonathen Brecher - >brecher@husc9.harvard.edu >The author has called his font "Shalom". >This was originally written using a Mac, and it contains three styles- >"old fashioned" letters, Ktav letters and "narrow" letters, >as well as Nikud. The font seems a little problematic, that is, >work has to be done in order to make it usable to all. >I am trying to do the work - it might take a month or so. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Wed May 22 21:49:36 1991 Flags: 000000000001 Return-Path: Received: from LINUS.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26805; Wed, 22 May 91 21:48:54 MDT Date: Wed, 22 May 1991 20:48 PDT From: Don Hosek Subject: UPLOAD: xarticle.sty--modified article.sty supporting 7-9pt sizes To: texhax@cs.washington.edu, tex-archive@science.utah.edu, info-tex@shsu.BITNET, ivritex@taunivm.BITNET Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: texhax,tex_archive,in%"info-tex@shsu",in%"ivritex@taunivm" xarticle.sty and its support files, art7.sty, art8.sty and art9.sty have been placed on ymir.claremont.edu in [anonymous.tex.inputs.latex-contrib]. It is a modified article.sty which supports document style options for 7-9pt typesetting. It was posted to comp.text.tex on 8-May-1991 by Paul Kirkaas. (The file article.sty in that posting was renamed to xarticle.sty to avoid name conflicts.) -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Wed May 22 22:34:45 1991 Flags: 000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26986; Wed, 22 May 91 22:33:56 MDT Date: Wed, 22 May 1991 20:03 PDT From: Don Hosek Subject: UPLOAD: PBMplus--Convert PBM files to TeX PK files for VMS. To: TEX-GROUP@HMCVAX.CLAREMONT.EDU, texhax@cs.washington.edu, tex-archive@science.utah.edu, info-tex@shsu.BITNET Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: tex-group,texhax,tex_archive,in%"info-tex@shsu" PBMplus has been installed on ymir.claremont.edu in [anonymous.tex.graphics.pbmplus]. This copy was obtained from vmsserv@wkuvx1.bitnet on 22-May-1991. Please note that the files are stored in VMS_SHARE format split into multiple parts exactly as distributed from that source. The following is from a posting by the author in comp.text.tex: -Do you know about the Extended Portable Bitmap Toolkit? This package -consists of a number of programs to convert image files to portable -bitmaps and back. For example, MacPaint, .PCX, and X11 bitmaps can -all be converted to portable bitmaps; each of the portable bitmaps can -then be converted to other formats. -I bring this up because there is also a (separate) program to convert -a Portable Bitmap to a TeX .PK file, letting you convert PC images to -"normal" TeX fonts. The program generates both a .PK file and a .TFM -file; the image is stored as character "A" in that font and is -referenced as any other font would be referenced. -Ever since I happened upon these, this is how I've included graphics into -my TeX files. Since they're stored as .PK files, even previewers like -XDVI can display the graphics images. -The PBMPLUS programs are all written in C; the PBM_TEX program is written in -C and FORTRAN. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Thu May 23 00:49:15 1991 Flags: 000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27729; Thu, 23 May 91 00:48:37 MDT Date: Wed, 22 May 1991 23:48 PDT From: Don Hosek Subject: UPLOAD: Enhanced Emacs-lisp TeX mode To: info-tex@shsu.bitnet, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <17EF6924AAE02C25@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: IN%"info-tex@shsu.bitnet",TEXHAX,TEX_ARCHIVE Three files composing an enhanced emacs lisp TeX mode have been installed on ymir.claremont.edu in the directory [anonymous.tex.utilities.emacs-modes] The files are auc-tex.el, minor-map.el and outline-m.el. The files were FTP'd from iesd.auc.dk on 22 May 1991. The following is from the original announcement in comp.text.tex: If anyone is Interested, I've made a much enchanced LaTeX mode for Emacs. The features discussed here concerning the ability to run both a printer driver and a previewer are there. Also BibTeX and Makeindex are bound to seperate keys. But thats not all. I've also made a parser, for the (La)TeX output, so that the errors may be parsed. That means, pressing C-c C-n (TeX-next-error), will move the cursor to the file and position of the given error. Using this feature all errormessages are documented - online. I got most of this documentation from Leslie. The distribution package comes with a minor-outline-mode, an outlinemode that can run under LaTeX mode. Other features: Intelligent macros for often used controlsequences like Intelligent macros for often used controlsequences like \section{ ... } and anvironments. Indentation by environments -dh -- Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Thu May 23 19:22:40 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02080; Thu, 23 May 91 19:19:37 MDT Date: Thu, 23 May 1991 18:18 PDT From: Don Hosek Subject: UPLOAD: MacBibTeX 2.0 -- BibTeX for the Macintosh To: tex-archive@science.utah.edu, texhax@cs.washington.edu, info-tex@shsu.BITNET, kahn@informatics.wustl.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: TEX_ARCHIVE,TEXHAX,IN%"info-tex@shsu",IN%"kahn@informatics.wustl.edu" MacBibTeX 2.0 is available from ymir.claremont.edu as macbibtex2_0-sit.hqx in the directory [anonymous.tex.macintosh.bibtex] The file was received direct >From the author. The following is quoted from a note from the author: >MacBibTex 2.0 is an update of MacBibTeX 1.1 MacBibTex is a macintosh >port of BibTex 0.99c for users of Textures and OzTex. The file is >in binhex and Stuffit 1.5 format and can be transferred as an ASCII >file. The archive contains only the MacBibTex application and a >README files. Instructions for obtaining the source code from me >are included in the application. > >MacBibTex is free. -dh -- Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "JANET TEX@UK.AC.CRANFIELD.RMCS " Fri May 24 04:25:20 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03814; Fri, 24 May 91 04:24:22 MDT Received: from rmcs.cranfield.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <6767-0@sun2.nsfnet-relay.ac.uk>; Fri, 24 May 1991 11:03:29 +0100 Date: Fri, 24 MAY 91 10:49:33 BST From: TEX@rmcs.cranfield.ac.uk To: TEX-ARCHIVE <@nsfnet-relay.ac.uk:TEX-ARCHIVE@SCIENCE.UTAH.edu> Subject: RE: EGA2MF Actually-To: Sender: JANET "TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <0000015D_00191958.0094913D768901A0$135_1@UK.AC.CRANFIELD.RMCS> Reply-To: Brian {Hamilton Kelly} Originally-To: INTERNET%EDU.UTAH.SCIENCE::TEX-ARCHIVE Originally-From: TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) In message of Wed, 22 May 1991 18:44 PDT, Don Hosek wrote: > Thomas Ridgeway's EGA2MF package has been placed in the ymir.claremont.edu > archive in the directory [anonymous.tex.mf.ega2mf]. > > The package includes programs for converting EGA and VGA bitmaps to MF code, > several fonts, and the MF code for a PC font based on the EGA bitmaps. The > file 00readme.txt in that directory has more information. > > Note that all *.ega and *.vga files are binary and cannot be retrieved by the > mailserver. I have retrieved the files, and they will be installed on uk.ac.tex this afternoon. I have modified ega2mf.c and vga2mf.c, as described by the following insertion in 00readme.txt: > % 91/05/24 Brian {Hamilton Kelly}, checking that the programs would work > % under VAX/VMS, replaced the line reading > FILE *f1,*f2; > % in each source with these lines > FILE *f1=(FILE *) NULL; > FILE *f2=(FILE *) NULL; > % (In C, there's no guarantee that automatic variables will have _any_ > % particular value, let alone the (FILE *)NULL that was necessary here > % with the method the program uses to prompt for missing command-line > % arguments. Perhaps he was just lucky with his Unix & DOS :-) I am sending this message to all other archivists so that they can consider making the same change; I'm also copying it to Thomas Ridgeway. BTW, Thomas, the program's *great* : many thanx. Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: {mcsun,ukc,uunet}!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From "JANET TEX@UK.AC.CRANFIELD.RMCS " Fri May 24 12:36:26 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05690; Fri, 24 May 91 12:35:10 MDT Received: from rmcs.cranfield.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <20385-0@sun2.nsfnet-relay.ac.uk>; Fri, 24 May 1991 19:06:39 +0100 Date: Fri, 24 MAY 91 17:41:44 BST From: TEX@rmcs.cranfield.ac.uk To: tex-archive <@nsfnet-relay.ac.uk:tex-archive@SCIENCE.UTAH.edu> Subject: RE: EGA2MF Actually-To: Sender: JANET "TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <000002DE_001B8218.009491770AF15160$22_1@UK.AC.CRANFIELD.RMCS> Reply-To: Brian {Hamilton Kelly} Originally-To: INTERNET%EDU.UTAH.SCIENCE::"tex-archive" Originally-From: TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) In message of Wed, 22 May 1991 18:44 PDT, Don Hosek wrote: > Thomas Ridgeway's EGA2MF package has been placed in the ymir.claremont.edu > archive in the directory [anonymous.tex.mf.ega2mf]. > . > . > . > Note that all *.ega and *.vga files are binary and cannot be retrieved by the > mailserver. A warning to those running other archives: the file wnpc10.tex contains eight-bit characters, so take care to transfer this in whatever mode is necessary to preserve them. The uk.ac.ft-relay through which I fetched this (and the other files) obviously thinks it's a Unix machine (even though I _know_ that it's running VMS!) and truncated all the bytes to seven bits, until I retransferred in binary mode (which then meant that it lost the record structure, so I had to rebuild it --- [another great use for VV{en/de}code, shortly to be released!] Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: {mcsun,ukc,uunet}!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From "Don Hosek " Mon May 27 16:17:06 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17053; Mon, 27 May 91 16:16:29 MDT Date: Mon, 27 May 1991 15:15 PDT From: Don Hosek Subject: UPLOAD: Update to AUC Emacs lisp TeX mode To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: in%"info-tex@shsu",texhax,tex_archive An updated version of the AUC Emacs lisp TeX mode has been installed in ymir.claremont.edu:[anonymous.tex.utilities.emacs-modes] If you already have a copy of the previous version, only the file auc-tex.el needs to be uploaded. A 00readme.txt file has been created in that directory explaining its contents. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Mon May 27 17:00:41 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17120; Mon, 27 May 91 16:59:49 MDT Date: Mon, 27 May 1991 15:59 PDT From: Don Hosek Subject: UPLOAD: bibtex-mode.el--Emacs mode for BibTeX file entry/editing To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: in%"info-tex@shsu",texhax,tex_archive An emacs mode for BibTeX file entry/editing is now available as ymir.claremont.edu:[anonymous.tex.utilities.emacs-mode]bibtex-mode.el This mode was created by Mike Newton and was obtained by anonymous FTP from tut.cis.ohio-state.edu on 27-May-1991 -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Mon May 27 17:03:42 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17135; Mon, 27 May 91 17:02:45 MDT Date: Mon, 27 May 1991 16:02 PDT From: Don Hosek Subject: UPDATE: cvtbib.el moved in ymir archive To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: in%"info-tex@shsu",texhax,tex_archive The file cvtbib.el which was previously available in ymir.claremont.edu:[anonymous.tex.bibtex.utilities] is now available as ymir.claremont.edu:[anonymous.tex.utilities.emacs-lisp]cvtbib.el. This EMACS Lisp file allows one to convert Bibliographies between Scribe and BibTeX formats. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Mon May 27 17:23:49 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17187; Mon, 27 May 91 17:22:58 MDT Date: Mon, 27 May 1991 16:22 PDT From: Don Hosek Subject: UPLOAD: New versions of ega2mf.c and vga2mf.c To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: in%"info-tex@shsu",texhax,tex_archive A small patch has been applied to ega2mf.c and vga2mf.c to allow those programs to be compiled with VAX C (and possibly others). The following files have been affected: ymir.claremont.edu:[anonymous.tex.mf.ega2mf]ega2mf.c ymir.claremont.edu:[anonymous.tex.mf.ega2mf]vga2mf.c ymir.claremont.edu:[anonymous.tex.mf.ega2mf]00readme.txt The patches were received from Brian Hamilton Kelly and applied manually to the programs. The following is the update to 00readme.txt: % 91/05/24 Brian {Hamilton Kelly}, checking that the programs would work % under VAX/VMS, replaced the line reading FILE *f1,*f2; % in each source with these lines FILE *f1=(FILE *) NULL; FILE *f2=(FILE *) NULL; % (In C, there's no guarantee that automatic variables will have _any_ % particular value, let alone the (FILE *)NULL that was necessary here % with the method the program uses to prompt for missing command-line % arguments. Perhaps he was just lucky with his Unix & DOS :-) -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek " Mon May 27 17:43:13 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17224; Mon, 27 May 91 17:42:16 MDT Date: Mon, 27 May 1991 16:41 PDT From: Don Hosek Subject: Getting archives to conform to each other To: tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: tex_archive We have in the past begun talking about trying to standardize archive structures and let it slip off, I'd like to try and restart that discussion, if we can. It seems to me that we want the following out of a global structure to an archive: - It should be as system-independent as possible. We have four types of s systems hosting archives at present: > VAXen reachable through FTP/mail service > Unix boxes reachable through FTP/mail service > DEC-20s (or not) reachable through FTP > VM/CMS machines reachable through Listserv we should try to stay within these confines which still gives us a fair amount of flexibility. - It should be structured in a logical way so that someone browsing has a good chance of locating the files that they want easily - It should be structured in such a way so that sites can easily only support the parts of the archive that they find appropriate. The first item above gives us the parameters of a directory tree structure, no case-significance in file names and symbolic links at the directory level at _most_. The second and third don't really offer us concrete guidelines for organizing the archives but do, at least give some guidelines. I would recommend the idea of breaking the archiving down into minor archives, which have their own directory structure. This basic principle is followed by most of the archives anyway so I wouldn't expect a great deal of debate on the principal, but what the minor archives are could lead to some debate. Here is the division on ymir: BABEL Foreign language support (fonts and macros). BIBTEX BibTeX files (.bst and .bib). See [TEX.SOURCES.BIBTEX0_99] for the actual programs. DOC Miscellaneous documentation (to go away). DOCUMENT Miscellaneous documentation (to go away). DRIVERS Assorted DVI driver programs. DVI-STANDARD DVI driver standards information. EXE VMS executables. FONTS TFM, PK, and PL files. FORMATS FMT, BAS, and POO files. GRAPHICS Graphics utilities for TeX HELP VMS Help files HERSHEY Utility programs for use with Hershey fonts. IBM_PC IBM PC stuff. INPUTS TeX/LaTeX/AmSTeX input files. MACINTOSH Macintosh files MF MF input files. MUSIC Files for typesetting Music (fonts and macros) PERIODICALS Files and back issues of TeXhax, TUGboat, UKTeX, and TeXMaG. SITE-INFO Information on TeX for different systems. SORTTHROUGH Stuff which hasn't been mulled over yet (to be removed). SOURCES Sources for TeX, MF, BibTeX, TeXware, MFware, WEB. TEST Trip and Trap tests. UTILITIES Assorted TeX-related utility programs. From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Tue May 28 02:01:51 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE ([130.73.76.1]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01087; Tue, 28 May 91 02:00:04 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA24944; Tue, 28 May 91 09:59:52 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA08046; Tue, 28 May 91 09:59:49 +0200 Date: Tue, 28 May 91 09:59:49 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9105280759.AA08046@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: tex-archive@science.utah.edu In-Reply-To: Don Hosek's message of Mon, 27 May 1991 16:41 PDT Subject: Getting archives to conform to each other OK, Don, seems that we can finally try something.... - It should be as system-independent as possible. We have four types of s systems hosting archives at present: > VAXen reachable through FTP/mail service > Unix boxes reachable through FTP/mail service > DEC-20s (or not) reachable through FTP > VM/CMS machines reachable through Listserv You can forget the latter at the moment. You will never have the same amount of disk space on Listserv machines as on VAXen or Unixen. Besides, the only Listserv so far is the one at Heidelberg, so that I can safely tell you to ignore it. As for DEC-20: which one? Is there any of them left? If so, will it remain in the future? we should try to stay within these confines which still gives us a fair amount of flexibility. ... The first item above gives us the parameters of a directory tree structure, no case-significance in file names and symbolic links at the directory level at _most_. The second and third don't really offer us concrete guidelines for organizing the archives but do, at least give some guidelines. I don't see why it doesn't give us hard links. You have that on Unix and VAX. Forget about the rest of systems (see above). Here is the division at Stuttgart: AMS Files supplied by the AMS (AMS-TeX, AMS-LaTeX, ...) AMS-corrections-and-changes Corrected versions of files from AMS, to go away as soon as the ams manages to incoporate them into their distribution DANTE You know what drivers All kinds of .dvi drivers education Teaching TeX fonts What it says. Subdirectories are: gf-files metafont pk-files tfm-files hints General hints how to find things, (to go away) ILaTeX ILaTeX sources LaTeX LaTeX sources LaTeX-style LaTeX style files has two subdirectories: supported and unsupported lib copy of LaBrea's lib dir (to go away) machines system specific things like emTeX, ... Subdirectories are: OS2 acorn amiga atari mac pc unix vms mf LaBrea's mf dir. (to go away) mfware LaBrea's mfware dir (to go away) MTeX Music TeX MakeIndex MakeIndex distribution PiCTeX PiCTeX sources TUGboat TUGboat related files TeX-files another one from LaBrea (to go away) TeX-macros Useful macros for plain (Urgh!) aasmacros changebars edmac TeX-sources The official sources TeXMaG TeXhax TeXware Some TeX utilites in web (to go away) UKTeX utilities Utilities for use with TeX (TeXDraw, transfig, ...) WEB Rainer From "George D. Greenwade " Tue May 28 08:13:38 1991 Flags: 000000000001 Return-Path: Received: from niord.shsu.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01712; Tue, 28 May 91 08:12:40 MDT Received: by Niord.SHSU.edu (MX V2.3) id 28439; Tue, 28 May 1991 09:11:14 CDT Date: Tue, 28 May 1991 09:11:14 CDT From: "George D. Greenwade" To: tex-archive@science.utah.edu Message-Id: <00949454.65B065C0.28439@Niord.SHSU.edu> Subject: RE: Getting archives to conform to each other On Mon, 27 May 1991 16:41 PDT, Don Hosek resumed a very good topic! Ranier's comments which followed are also helpful. I would like to add a few points, as well, if I may (recognizing, of course, that our site is the "baby" among archive sites). > We have in the past begun talking about trying to standardize archive > structures and let it slip off, I'd like to try and restart that > discussion, if we can. > It seems to me that we want the following out of a global structure to an > archive: > - It should be as system-independent as possible. We have four types of s > systems hosting archives at present: And, once again, I will argue that the filename syntax should also be as system-independent as possible (8.3) for files with general applicability. This, naturally, means that (for example) VMS-specific EXE files, etc., can avoid 8.3 filename structure, but for most files, we have to recognize that TeX and its variants are, for the most part, platform independent. > - It should be structured in a logical way so that someone browsing has > a good chance of locating the files that they want easily Hence, a few major (i.e., first-level) subdirectories with multiple branched trees (like YMIR and Aston) or many major subdirectories (like SHSU)? You cannot believe the amount of mail I receive weekly (usually around 15 totally non-requested responses) from users worldwide who compliment our simplistic approach (put on us by our software -- it was not an intentional design originally, but is now one I think needs consideration). While we now support ftp, I hope we will always be noted for FILESERV (I have nothing to really compare our performance against, but an average ot 200+ TeX-related transfers daily isn't real bad, I don't think)! I can see that many first-level subdirectories would be required to achieve a large archive (and we do hope to join the world of big repositories -- we've recently ordered a 1.5 gig device for TeX archive support alone and plan on getting the Aston tapes as soon as we have the space on-line). > - It should be structured in such a way so that sites can easily only > support the parts of the archive that they find appropriate. Which many major subdirectories allows for (at least accroding to my mail). Presently, I am also involved in the IETF list server device project (don't ask how an economist got on this one). Standards and an ultimate RFC will come from this group (yes, something like a LISTSERV, but for VMS and U*ix platforms -- maybe even DOS! -- and since Eric Thomas is tangentially involved, I expect he will have a revised revised LISTSERV sometime in the future to meet these standards for VM/CMS). We've even discussed peering in the context of file servers (like mail server peering for subscribe and signoff now on LISTSERV, but for file requests!). While I cannot say at this juncture precisely how or what this beast will evolve into, it appears that multiple-level directory trees will be supported. I expect that the fruits of this project (at least on the VMS side) will be a public domain application, so our discussion of standardization maybe should be put on hold until at least command and directory design in addressed by this committee (one of the earliest topics scheduled in designing the architecture -- hopefully to be basically outlined this summer). I am making the humble assumption that VMS sites would wish to follow along on the standard now in development (possibly a very bad assumption) since it is being designed with all existing mailers, NJE transport agents (file transport, where supportable), and major TCP/IP drivers in mind (lots and lots of documented hooks!). Anyway, as noted earlier, we are a very young site with great aspirations. Our present directory structure for FILESERV (which is imposed on ftp) is: AMSLATEX_DOC AMS-LaTeX distribution; the doc subdirectory AMSLATEX_FONTSEL AMS-LaTeX distribution; fontsel subdirectory AMSLATEX_INPUTS AMS-LaTeX distribution; inputs subdirectory DVI2TTY Files for DVI2TTY (for VMS) DVIDVI Files for DVIDVI (for VMS) DVIPS547 Files for version 5.47 of DVIPS (for VMS) DVITOLN03 Files for DVItoLN03 (for VMS) EEPIC Files for eepic (LaTeX Extensions to EPIC) EPIC Files for epic (LaTeX Enhanced Picture Environment) ESSENTIAL Files for John Warbrick's "Essential LaTeX" FAQ comp.text.tex's "Frequently Asked Questions" and "FAQ Supplement" GENTLE Files for Michael Doob's "A Gentle Introduction to TeX" INFO-TEX INFO-TeX archives (TeX-related discussion list) LZW Files for Lempel-Ziv-Welch file compression/decompression (for VMS; output is optionally Unix-compatible) LZW_SOURCES C source code for LZW (above) MFTU Files for Mail File Transfer Utility (encoding/decoding; VMS) MODES Files for Karl Berry's MODES.MF REVTEX Files for American Physical Society's REVTEX Version 2.0 STY LaTeX style file archives TEXHAX TeXhax Digest archives TEXMAG TeXMaG archives TEXSERVER HELP file from TeXServer@TeX.ac.uk TEX_PRIMER Files for Joe St Sauver's "Using TeX on the VAX to Typeset Documents: A Primer" TROFFTOTEX Files for TROFFtoTeX (LaTeX version) TUGABS Abstracts of TeX Users Group Proceedings for various years. UKTEX UKTeX Digest archives I left in LZW, LZW_SOURCES, and MFTU as we use these for non-ftp delivery (i.e., can send binaries and backup savesets via MAIL). These all represent first-level subdirectories. Virtually all of these have compressed files for ftp in a second-level subdirectory named [.ftp]. While this does use more space, users seem to really like it, especially on the ftp side since ftp stuff is in a true ftp area associated with the directory). Well, now it's time to flame this simplistic approach. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg@Niord.SHSU.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "bbeeton " Tue May 28 12:57:30 1991 Flags: 000000000001 Return-Path: Received: from VAX02.AMS.COM (VAX01.AMS.COM) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03327; Tue, 28 May 91 12:57:23 MDT Date: Tue 28 May 91 14:26:53-EST From: bbeeton Subject: dek's glue.web -- corrected version for the archives To: tex-implementors@VAX02.AMS.COM Message-Id: <675455213.0.BNB@MATH.AMS.COM> Mail-System-Version: on may 23, eberhard mattes posted a question about dek's fixed-point glue setting: TUGboat Vol. 3 No. 1, pp. 10 (`[Subject] An Example of WEB') describes a program for fixed-point glue setting. When fed with the values 300000 314 199686 0 it displays Test data set number 1: Glue ratio is 0.7500 (2,12,12288) 314 234 199686 149763 Totals 200000 149997 (versus 300000) which is off by a factor of two (glue ratio & 2nd column). Is this a known (and fixed?) bug or a typo (is there an electronical version of that program?) or a bug in my Pascal compiler? Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) i've received a short item from dek for tugboat acknowledging the error, explaining the reasons, and giving the corrections. i have forwarded that to e.m. and (because i am very much behind in the production of tugboat 12 #2 -- the production assistance i have had in the past was not available for this issue -- so it still hasn't gone to the printer) it will appear in the tugboat 12 #2 under "late-breaking news". however, even though i'm not sending that to this list, i am attaching the revised version of glue.web . dek has asked that it be deposited in all the appropriate archives. i'm not sure what directory it will be installed in at labrea; if dan kolkowitz will let us know that, everyone else can handle it the same way. -- bb --------------- Date: Tue, 28 May 91 11:04:26 -0700 Subject: Don's file "glue.web" to be sent to all major TeX archives % This program by D. E. Knuth is not copyrighted and can be used freely. % It was written on 18 Dec 1981 and revised on 24 May 1991. % Here is TeX material that gets inserted after \input webmac \def\PASCAL{Pascal} \font\eightrm=cmr8 \def\title{GLUE} \def\topofcontents{\null \def\titlepage{F} % include headline on the contents page \def\rheader{\mainfont\hfil \contentspagenumber} \vfill \centerline{\titlefont Fixed-Point Glue Setting} \vfill} \def\botofcontents{\vfill \centerline{\hsize 6in\baselineskip9pt \vbox{\eightrm\baselineskip9pt\noindent The preparation of this report was supported in part by the National Science Foundation under grants IST-7921977 and MCS-7723728; by Office of Naval Research grant N00014-81-K-0330; and by the IBM Corporation. `\TeX' is a trademark of the American Mathematical Society.}}} @* Introduction. If \TeX\ is being implemented on a microcomputer that does 32-bit addition and subtraction, but with multiplication and division restricted to multipliers and divisors that are either powers of~2 or positive integers less than~$2^{15}$, it can still do the computations associated with the setting of glue in a suitable way. This program illustrates one solution to the problem. Another purpose of this program is to provide the first ``short'' example of the use of \.{WEB}. @ The program itself is written in standard \PASCAL. It begins with a normal program header, most of which will be filled in with other parts of this ``web'' as we are ready to introduce them. @^program header@> @p program GLUE(@!input,@!output); type @@; var @@; procedure initialize; {this procedure gets things started} var @@; begin @; end; @ Here are two macros for common programming idioms. @d incr(#) == #:=#+1 {increase a variable by unity} @d decr(#) == #:=#-1 {decrease a variable by unity} @* The problem and a solution. We are concerned here with the ``setting of glue'' that occurs when a \TeX\ box is being packaged. Let $x_1$, \dots,~$x_n$ be integers whose sum $s=x_1+\cdots+x_n$ is positive, and let $t$ be another positive integer. These $x_i$ represent scaled amounts of glue in units of sp (scaled points), where one sp is $2^{-16}$ of a printer's point. The other quantity $t$ represents the total by which the glue should stretch or shrink. Following the conventions of \TeX82, we will assume that the integers we deal with are less than $2^{31}$ in absolute value. After the glue has been set, the actual amounts of incremental glue space (in~sp) will be the integers $f(x_1)$, \dots,~$f(x_n)$, where $f$ is a function that we wish to compute. We want $f(x)$ to be nearly proportional to~$x$, and we also want the sum $f(x_1)+\cdots+f(x_n)$ to be nearly equal to~$t$. If we were using floating-point arithmetic, we would simply compute $f(x)\equiv(t/s)\cdot x$ and hope for the best; but the goal here is to compute a suitable~$f$ using only the fixed-point arithmetic operations of a typical ``16-bit microcomputer.'' The solution adopted here is to determine integers $a$, $b$, $c$ such that $$f(x)=\bigl\lfloor 2^{-b}c\lfloor 2^{-a}x\rfloor\bigr\rfloor$$ if $x$ is nonnegative. Thus, we take $x$ and shift it right by $a$~bits, then multiply by~$c$ (which is $2^{15}$ or less), and shift the product right by $b$~bits. The quantities $a$, $b$, and~$c$ are to be chosen so that this calculation doesn't cause overflow and so that $f(x_1)+\cdots +f(x_n)$ is reasonably close to~$t$. The following method is used to calculate $a$ and~$b$: Suppose $$y=\max_{1\le i\le n}\vert x_i\vert\,.$$ Let $d$ and $e$ be the smallest integers such that $t<2^ds$ and $y<2^e$. Since $s$ and~$t$ are less than~$2^{31}$, we have $-30\le d\le31$ and $1\le e\le31$. An error message is given if $d+e\ge31$; in such a case some $x_m$ has $\vert x_m\vert\ge 2^{e-1}$ and we are trying to change $\vert x_m\vert$ to $\vert(t/s)x_m\vert\ge2^{d+e-2}\ge2^{30}$~sp, which \TeX\ does not permit. (Consider, for example, the ``worst case'' situation $x_1=2^{30}+1$, $x_2=-2^{30}$, $t=2^{31}-1$; surely we need not bother trying to accommodate such anomalous combinations of values.) On the other hand if $d+e\le31$, we set $a=e-16$ and $b=31-d-e$. Notice that this choice of~$a$ guarantees that $\lfloor2^{-a}\vert x_i\vert\rfloor<2^{16}$. We will choose~$c$ to be at most~$2^{15}$, so that the product will be less than~$2^{31}$. The computation of $c$ is the tricky part. @^hairy mathematics@> The ``ideal'' value for $c$ would be $\rho=2^{a+b}t/s$, since $f(x)$ should be approximately $(t/s)\cdot x$. Furthermore it is better to have $c$ slightly larger than~$\rho$, instead of slightly smaller, since the other operations in $f(x)$ have a downward bias. Therefore we shall compute $c=\lceil\rho\rceil$. Since $2^{a+b}t/s<2^{a+b+d}=2^{15}$, we have $c\le2^{15}$ as desired. We want to compute $c=\lceil\rho\rceil$ exactly in all cases. There is no difficulty if $s<2^{15}$, since $c$ can be computed directly using the formula $c=\bigl\lfloor(2^{a+b}t+s-1)/s\bigr\rfloor$; overflow will not occur since $2^{a+b}t<2^{15}s<2^{30}$. Otherwise let $s=s_12^l+s_2$, where $2^{14}\le s_1<2^{15}$ and $0\le s_2<2^l$. We will essentially carry out a long division. Let $t$ be ``normalized'' so that $2^{30}\le2^ht<2^{31}$ for some~$h$. Then we form the quotient and remainder of $2^ht$ divided by~$s_1$, $$ 2^ht=qs_1+r_0, \qquad 0\le r_0-s$ we have $q=\lceil2^{h+l}t/s\rceil$; otherwise we can replace $(q,r)$ by $(q\pm1,r\mp s)$ repeatedly until $r$ is in the correct range. It is not difficult to prove that $q$ needs to be increased at most once and decreased at most seven times, since $2^lr_0-qs_2<2^ls_1\le s$ and since $qs_2/s\le(2^ht/s_1)(s_2/2^ls_1)<2^{31}/s_1^2\le8$. Finally, we have $a+b-h-l=-1$ or~$-2$, since $2^{28+l}\le2^{14}s=2^{a+b+d-1}s\le2^{a+b}t< 2^{a+b+d}s=2^{15}s<2^{30+l}$ and $2^{30}\le2^ht<2^{31}$. Hence $c=\lceil2^{a+b-h-l}q\rceil=\lceil{1\over2}q\rceil$ or~$\lceil{1\over4}q\rceil$. An error analysis shows that these values of $a$, $b$, and $c$ work satisfactorily, except in unusual cases where we wouldn't expect them to. @^error analysis@> When $x\ge0$ we have $$\eqalign{f(x)&=2^{-b}(2^{a+b}t/s+\theta_0)(2^{-a}x-\theta_1)-\theta_2\cr &=(t/s)x+\theta_02^{-a-b}x-\theta_12^at/s-2^{-b}\theta_0\theta_1-\theta_2\cr}$$ where $0\le\theta_0,\theta_1,\theta_2<1$. Now $0\le\theta_02^{-a-b}x <2^{e-a-b}=2^{d+e-15}$ and $0\le\theta_12^at/s<2^{a+d}=2^{d+e-16}$, and the other two terms are negligible. Therefore $f(x_1)+\cdots+f(x_n)$ differs from~$t$ by at most about $2^{d+e-15}n$. Since $2^{d+e}$ is larger than $(t/s)y$, which is the largest stretching or shrinking of glue after expansion, the error is at worst about $n/32000$ times as much as this, so it is quite reasonable. For example, even if fill glue is being used to stretch 20 inches, the error will still be less than $1\over1600$ of an inch. @ To sum up: Given the positive integers $s$, $t$, and $y$ as above, we set $$a\gets\lfloor\lg y\rfloor-15,\qquad b\gets29-\lfloor\lg y\rfloor- \lfloor\lg t/s\rfloor,\qquad\hbox{and}\qquad c\gets\lceil2^{a+b}t/s\rceil.$$ The implementation below shows how to do the job in \PASCAL\ without using large numbers. @ \TeX\ wants to have the glue-setting information in a 32-bit data type called |glue_ratio|. The \PASCAL\ implementation of \TeX82 has |glue_ratio =real|, but alternative definitions of |glue_ratio| are explicitly allowed. For our purposes we shall let |glue_ratio| be a record that is packed with three fields: The |a_part| will hold the positive integer |a+16|, the |b_part| will hold the nonnegative integer~|b|, and the |c_part| will hold the nonnegative integer~|c|. When the formulas above tell us to take |b>30|, we might as well set |c:=0| instead, because |f(x)| will be zero in all cases when |b>30|. Note that we have only about 25 bits of information in all, so it should fit in 32 bits with ease. @= @!glue_ratio=packed record @!a_part: 1..31; {the quantity |e=a+16| in our derivation} @!b_part: 0..30; {the quantity |b| in our derivation} @!c_part: 0..@'100000; {the quantity |c| in our derivation} end; @!scaled = integer; {this data type is used for quantities in sp units} @ The real problem is to define the procedures that \TeX\ needs to deal with such |glue_ratio| values: (a)~Given scaled numbers |s|, |t|, and~|y| as above, to compute the corresponding |glue_ratio|. (b)~Given a nonnegative scaled number~|x| and a |glue_ratio|~|g|, to compute the scaled number~|f(x)|. (c)~Given a |glue_ratio|~|g|, to print out a decimal equivalent of |g| for diagnostic purposes. The procedures below can be incorporated into \TeX82 via a change file without great difficulty. A few modifications will be needed, because \TeX's |glue_ratio| values can be negative in unusual cases---when the amount of stretchability or shrinkability is less than zero. Negative values in the |c_part| will handle such problems, if proper care is taken. The error message below should either become a warning message or a call to \TeX's |print_err| routine; in the latter case, an @^error message@> appropriate help message should be given, stating that glue cannot stretch to more than 18~feet long, but that it's OK to proceed with fingers crossed. @*Glue multiplication. The easiest procedure of the three just mentioned is the one that is needed most often, namely, the computation of~|f(x)|. \PASCAL\ doesn't have built-in binary shift commands or built-in exponentiation, although many computers do have this capability. Therefore our arithmetic routines use an array called `|two_to_the|', containing powers of~two. Divisions by powers of two are never done in the programs below when the dividend is negative, so the operations can safely be replaced by right shifts on machines for which this is most appropriate. (Contrary to popular opinion, the operation `|x div 2|' is not the same as shifting |x| right one binary place, on a machine with two's complement arithmetic, when |x| is a negative odd integer. But division {\it is\/} equivalent to shifting when |x| is nonnegative.) @= @!two_to_the: array[0..30] of integer; {$|two_to_the|[k]=2^k$} @ @= @!k:1..30; {an index for initializing |two_to_the|} @ @= two_to_the[0]:=1; for k:=1 to 30 do two_to_the[k]:=two_to_the[k-1]+two_to_the[k-1]; @ We will use the abbreviations |ga|, |gb|, and |gc| as convenient alternatives to \PASCAL's \&{with} statement. The glue-multiplication function |f|, which replaces several occurrences of the `|float|' macro in \TeX82, is now easy to state: @d ga==g.a_part @d gb==g.b_part @d gc==g.c_part @p function glue_mult(@!x:scaled;@!g:glue_ratio):integer; {returns |f(x)| as above, assuming that |x>=0|} begin if ga>16 then x:=x div two_to_the[ga-16] {right shift by |a| places} else x:=x*two_to_the[16-ga]; {left shift by |-a| places} glue_mult:=(x*gc) div two_to_the[gb]; {right shift by |b| places} end; {note that |b| may be as large as 30} @*Glue setting. The |glue_fix| procedure computes |a|, |b|, and |c| by the method explained above. \TeX\ does not normally compute the quantity~|y|, but it could be made to do so without great difficulty. This procedure replaces several occurrences of the `|unfloat|' macro in \TeX82. It would be written as a function that returns a |glue_ratio|, if \PASCAL\ would allow functions to produce records as values. @p procedure glue_fix(@!s,@!t,@!y:scaled; var@!g:glue_ratio); var @!a,@!b,@!c:integer; {components of the desired ratio} @!k,@!h:integer; {$30-\lfloor\lg s\rfloor$, $30-\lfloor\lg t\rfloor$} @!s0:integer; {original (unnormalized) value of |s|} @!q,@!r,@!s1:integer; {quotient, remainder, divisor} @!w:integer; {$2^l$, where $l=16-k$} begin @; if t30) then begin if b<0 then write_ln('! Excessive glue.'); {error message} @^error message@> b:=0; c:=0; {make |f(x)| identically zero} end else begin if k>=16 then {easy case, $s_0<2^{15}$} c:=(t div two_to_the[h-a-b]+s0-1) div s0 {here |1<=h-a-b<=k-14<=16|} else @; end; ga:=a+16; gb:=b; gc:=c; end; @ @= begin a:=15; k:=0; h:=0; s0:=s; while y<@'10000000000 do {|y| is known to be positive} begin decr(a); y:=y+y; end; while s<@'10000000000 do {|s| is known to be positive} begin incr(k); s:=s+s; end; while t<@'10000000000 do {|t| is known to be positive} begin incr(h); t:=t+t; end; end {now $2^{30}\le t=2^ht_0<2^{31}$ and $2^{30}\le s=2^ks_0<2^{31}$, hence $d=k-h$ if $t/s<1$} @ @= begin w:=two_to_the[16-k]; s1:=s0 div w; q:=t div s1; r:=((t mod s1)*w)-((s0 mod w)*q); if r>0 then begin incr(q); r:=r-s0; end else while r<=-s0 do begin decr(q); r:=r+s0; end; if a+b+k-h=15 then c:=(q+1) div 2 @+else c:=(q+3) div 4; end @*Glue-set printing. The last of the three procedures we need is |print_gr|, which displays a |glue_ratio| in symbolic decimal form. Before constructing such a procedure, we shall consider some simpler routines, copying them from an early draft of the program \TeX82. @d unity==@'200000 {$2^{16}$, represents 1.0000} @= @!dig:array[0..15] of 0..9; {for storing digits} @ An array of digits is printed out by |print_digs|. @p procedure print_digs(@!k:integer); {prints |dig[k-1]| \dots |dig[0]|} begin while k>0 do begin decr(k); write(chr(ord('0')+dig[k])); end; end; @ A nonnegative integer is printed out by |print_int|. @p procedure print_int(@!n:integer); {prints an integer in decimal form} var @!k:0..12; {index to current digit; we assume that $0\le n<10^{12}$} begin k:=0; repeat dig[k]:=n mod 10; n:=n div 10; incr(k); until n=0; print_digs(k); end; @ And here is a procedure to print a nonnegative |scaled| number. @p procedure print_scaled(s:scaled); {prints a scaled real, truncated to four digits} var k:0..3; {index to current digit of the fraction part} begin print_int(s div unity); {print the integer part} s:=((s mod unity)*10000) div unity; for k:=0 to 3 do begin dig[k]:=s mod 10; s:=s div 10; end; write('.'); print_digs(4); end; @ Now we're ready to print a |glue_ratio|. Since the effective multiplier is $2^{-a-b}c$, we will display the scaled integer $2^{16-a-b}c$, taking care to print something special if this quantity is terribly large. @p procedure print_gr(@!g:glue_ratio); {prints a glue multiplier} var @!j:-29..31; {the amount to shift |c|} begin j:=32-ga-gb; while j>15 do begin write('2x'); decr(j); {indicate multiples of 2 for BIG cases} end; if j<0 then print_scaled(gc div two_to_the[-j]) {shift right} else print_scaled(gc*two_to_the[j]); {shift left} end; @* The driver program. In order to test these routines, we will assume that the |input| file contains a sequence of test cases, where each test case consists of the integer numbers $t$, $x_1$, \dots,~$x_n$, 0. The final test case should be followed by an additional zero. @= @!x:array[1..1000] of scaled; {the $x_i$} @!t:scaled; {the desired total} @!m:integer; {the test case number} @ Each case will be processed by the following routine, which assumes that |t| has already been read. @p procedure test; {processes the next data set, given |t| and~|m|} var @!n: 0..1000; {the number of items} k:0..1000; {runs through the items} y:scaled; {$\max_{1\le i\le n}\vert x_i\vert$} @!g:glue_ratio; {the computed glue multiplier} @!s:scaled; {the sum $x_1+\cdots+x_n$} @!ts:scaled; {the sum $f(x_1)+\cdots+f(x_n)$} begin write_ln('Test data set number ',m:1,':'); @; @; if s<=0 then write_ln('Invalid data (nonpositive sum); this set rejected.') else begin @; @; end; end; @ @= begin n:=0; repeat incr(n); read(x[n]); until x[n]=0; decr(n); end @ @= begin s:=0; y:=0; for k:=1 to n do begin s:=s+x[k]; if y= begin glue_fix(s,t,y,g); {set |g|, perhaps print an error message} write(' Glue ratio is '); print_gr(g); write_ln(' (',ga-16:1,',',gb:1,',',gc:1,')'); end @ @= begin ts:=0; for k:=1 to n do begin write(x[k]:20); if x[k]>=0 then y:=glue_mult(x[k],g) else y:=-glue_mult(-x[k],g); write_ln(y:15); ts:=ts+y; end; write_ln(' Totals',s:13,ts:15,' (versus ',t:1,')'); end @ Here is the main program. @^main program@> @p begin initialize; m:=1; read(t); while t>0 do begin test; incr(m); read(t); end; end. @*Index. Here are the section numbers where various identifiers are used in the program, and where various topics are discussed. ------- From "Peter Flynn UCC " Wed May 29 04:23:14 1991 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07185; Wed, 29 May 91 04:22:08 MDT Received: from IRUCCIBM.BITNET (MAILER@IRUCCIBM) by CC.UTAH.EDU with PMDF#10043; Wed, 29 May 1991 04:22 MST Received: from IRUCCVAX.UCC.IE (CBTS8001) by IRUCCIBM.BITNET (Mailer R2.07) with BSMTP id 8222; Wed, 29 May 91 11:20:58 IST Date: Wed, 29 May 91 11:20 GMT From: Peter Flynn UCC Subject: RE: Getting archives to conform to each other To: DHOSEK@HMCVAX.CLAREMONT.EDU, tex-archive@science.utah.EDU Message-Id: X-Envelope-To: tex-archive@science.utah.EDU X-Vms-To: IN%"DHOSEK@HMCVAX.CLAREMONT.EDU" The only plea I would make at this stage is for the full filepath/name not to exceed 80 characters in total. This is more for convenience in editing/listing rather than an operational requirement: it just makes things a little more user-friendly for those who don't have X-Windows or similar facilities which allow 132-char displays etc. ///Peter From "Don Hosek " Thu May 30 15:04:57 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16532; Thu, 30 May 91 15:01:43 MDT Date: Thu, 30 May 1991 14:01 PDT From: Don Hosek Subject: Re: Getting archives to conform to each other To: tex-archive@science.utah.edu Message-Id: <0F355E1022000AA4@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: tex_archive Regarding single-level vs. multi-level archiving schemes, the ymir archive largely avoids excessive fragmenting of directories (e.g., the Mittelbach & Schoepf macros are all in one directory as opposed to one directory per style package). Even with this approach, the following statistics on the size of the archive might be of interest: 310 directories, 8977 files, 328070 blocks. (one block=512bytes so the archive weighs in at 164,035K) As you can imagine, I'm not too keen on having 310 top-level directories. A two-level scheme is still too simplistic. What do I do with the Babel archive where we have a tree that looks like (abbreviated): [BABEL] | [ARABIC] | [CHINESE] | [DANISH] | [DUTCH] | [FRENCH] | [GERMAN] | | [FONTS-YFRAK] | | [FONTS-YGOTH] | | [FONTS-YINIT] | | [FONTS-YSWAB] | [GREEK] | | [HAMILTON_KELLY] | | [LEVY] | | [YANNIS] ... It's simply not feasible to simplify this tree structure. There are some cases where the tree structure could be argued, e.g., in the MF subarchive where I say: [MF]-[CM] | [OE] | [OUTLINES] | [PICA] | [SAUTER] | [STANDARD] | [VARIANTS] but by and large the treeing to three levels (in places) seems essential. (another case is something like taking a treed distribution, e.g., amsfonts and installing it as a second-level archive). As furtherance for the tree discussion, I am sending a full tree of ymir in a separate message. -dh From "Don Hosek " Thu May 30 15:11:28 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16568; Thu, 30 May 91 15:07:47 MDT Date: Thu, 30 May 1991 14:07 PDT From: Don Hosek Subject: tree of ymir archive To: tex-archive@science.utah.edu Message-Id: <101341F502000AC5@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: tex_archive [TEX] | [BABEL] | | [ARABIC] | | | [ATEX] | | | [FONTS-YARB] | | [CHINESE] | | [DANISH] | | [DUTCH] | | [FRENCH] | | [GERMAN] | | | [FONTS-YFRAK] | | | [FONTS-YGOTH] | | | [FONTS-YINIT] | | | [FONTS-YSWAB] | | [GREEK] | | | [HAMILTON_KELLY] | | | [LEVY] | | | [YANNIS] | | [HEBREW] | | | [FONTS-HCLASSIC] | | | [FONTS-PS-SHALOM] | | | [FONTS-REDIS] | | | [IVD2DVI] | | | [MACROS] | | | [PRTEX] | | | [TEX-XET] | | [ICELANDIC] | | [ITALIAN] | | [JAPANESE] | | | [ASCII-JTEX] | | [KOREAN] | | [PORTUGUESE] | | [RUSSIAN] | | | [DOC] | | | [DOS] | | | [FONTS-IFVE] | | | [FONTS-UWASH] | | | [INPUTS] | | | [PROGRAMS] | | | [VT220] | | [SPANISH] | | [TAMIL] | | [THAI] | | | [RMIT] | | | [USL] | | [TURKISH] | | [VIETNAMESE] | [BIBTEX] | | [CONTRIB] | | | [ASTRON] | | [LOCAL] | | [STANDARD] | | [UTILITIES] | | | [BIBCARD] | | | [BIBMAKE] | | | [LOOKBIBTEX] | [DOC] | [DOCUMENT] | [DOCUMENTATION] | | [OREGON-PRIMER] | [DRIVERS] | | [BEEBE2_10] | | | [DOC] | | [BEEBE_EXTENSIONS] | | [CRUDETYPE] | | [DVIDIS] | | [DVIDOC] | | [DVIIMP] | | [DVILG] | | [DVIOUT] | | | [EXAMPLES] | | | [ORIGINALS] | | [DVIPS] | | | [AFM-EXTRA] | | | [DVIPS] | | | | [PC] | | | | [VMS] | | | [PSLATEX] | | [DVIPS544OLD] | | [DVIPS5_44] | | | [AFM-EXTRA] | | | [DVIPS] | | | | [PC] | | | | [VMS] | | | [PSLATEX] | | [DVIPS_NEW] | | | [VMS] | | [DVITOPS] | | [DVITOVDU3_0] | | [DVITOVDU_C_1] | | [DVITTY] | | [INFO] | | [PSPRINT2_0] | | [SCREENVIEW] | | [TEX8600] | | [UKLN03] | | [XDVI] | [DVI-STANDARD] | [EXE] | [FONTS] | | [AFM] | | [PK] | | | [WB_LASER200-KST] | | | [WB_LASER300-AMSFONTS-OLD] | | | [WB_LASER300-METAFOUNDRY] | | | [WB_LASER300] | | [PL] | | [PS] | | [TFM] | | [VF] | [FORMATS] | [GRAPHICS] | | [BBFIG] | | [DLVGRAPH] | | [GNUPLOT] | | | [LATEX] | | [MATHEMATICA] | | [MFPLOT] | | [PBMPLUS] | | [PSFIG] | | | [DOC] | | | | [FIGS] | | | [DVI2PS-LI] | | | [DVI2PS-SVB] | | | [DVIPS] | | [TEXDRAW] | | | [COMPACT] | | | [MANUAL] | [HELP] | [HERSHEY] | [IBM_PC] | | [BIBTEX] | | [DRIVERS] | | | [EMTEX] | | [FRONT_ENDS] | | | [WP2LATEX] | | | [WSLTEX] | | [MF] | | | [EMTEX] | | [MISC] | | | [3D] | | [PREVIEWERS] | | [TEX] | | | [DOSTEX] | | | [EMTEX] | | [UNPACK] | | [WEB] | [INPUTS] | | [AMSAUTHOR-INFO] | | | [GUIDELINES] | | | [STY-FILES] | | [AMSLATEX] | | | [DOC] | | [AMSTEX-CONTRIB] | | [AMSTEX] | | | [DOC] | | [EDMAC] | | [EEPIC] | | [EPLAIN] | | [HPTEX] | | [LATEX-CONTRIB] | | | [OBSOLETE] | | | [RAIL] | | [LATEX-MAINZ] | | [LATEX] | | [LOCAL] | | [MIDNIGHT] | | [PHYSE] | | [PHYZZX] | | [PICTEX] | | [PLAIN-CONTRIB] | | | [CHBAR] | | [PSIZZL] | | [PSLATEX] | | | [PSFONTS] | | [SAMPLES] | | [SCRIPTTEX] | | [SLITEX] | | [STANDARD] | | [TEXSIS] | | [TEXT1] | | | [CMS_HELP_FILES] | | [YTEX] | [MACINTOSH] | | [BIBTEX] | | [BINARY] | | [CTEX] | | [DVI2IMG] | | [METAFONT] | | [OZINP] | | [OZSRC] | | [OZTEX] | [MF] | | [AMS] | | | [EULER] | | | [EXTRACM] | | | [SYMBOLS] | | [CHESS] | | [CM] | | | [OE] | | | [OUTLINES] | | | [PICA] | | | [SAUTER] | | | [STANDARD] | | | [VARIANTS] | | [CONCRETE] | | [DC] | | [DUERER] | | [EGA2MF] | | [HANDS] | | [IPA] | | [JEFFREY] | | [LATEX] | | [LOCAL] | | [MISC] | | [OCR] | | [PANDORA] | | [PLANETS] | | [PUNK] | | [SLITEX] | | [STANDARD] | | [TENGWAR] | | [WALDI] | [MUSIC] | | [MTEX] | | [MUSICTEX] | | | [DEMOS] | | | [MF] | [PERIODICALS] | | [TEXHAX] | | [TEXLINE] | | | [NO10] | | | [NO5] | | | [NO6] | | | [NO7] | | | [NO8] | | | [NO9] | | | [NO9] | | | [NO9] | | [TEXMAG] | | [TUGBOAT] | | [TUGNEWS] | | [UKTEX] | [SITE-INFO] | | [IMPLEMENTORS-NOTICES] | [SORTTHROUGH] | | [PSLATEX] | | | [DVI2PS] | | | [GETMETRICS] | | [TREVORROW] | | | [PYRAMID] | | | | [DVITOVDU] | | | | [PSPRINT] | | [VMS] | | | [LSEDIT] | | | | [HELP] | | | | [LSE] | | | | | [KEYS] | [SOURCES] | | [BIBTEX0_99] | | [MF2_7] | | [MFWARE] | | [TEX3_1] | | [TEXWARE] | | [WEB] | [TEST] | | [TRAP] | | [TRIP] | [UTILITIES] | | [C2LATEX] | | [CPP2LATEX] | | [CWEB] | | | [EXAMPLES] | | [DOCSTY] | | [DVICOPY] | | [DVIDVI] | | [EMACS-MODES] | | [EXTEND-CM] | | [FIG2EPIC] | | [FWEB] | | | [MISC] | | | [PC] | | | [UNIX] | | | | [ANSI] | | | | [APOLLO] | | | | [DSU] | | | | [MAC] | | | | [SGI] | | | | [SUN] | | | | | [CC] | | | | | [GCC] | | | [VAX] | | [HEXIFY] | | [IDXTEX] | | [INDEXOR] | | [LA2MML] | | [LGRAPH] | | [MAKEINDEX] | | [MF2PS] | | [MISC] | | [RSCSENCODE] | | [SCHEMEWEB] | | [TEXINDEX] | | [TEXIX] | | [TEXTYL] | | [TIB] | | [TRANSFIG] | | [WEB-EMACS-MODE] | | [WINDEX] -dh From "Don Hosek--ymir archive " Thu May 30 18:44:41 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17690; Thu, 30 May 91 18:43:55 MDT Date: Thu, 30 May 1991 17:43 PDT From: Don Hosek--ymir archive Subject: UPLOAD: New version of headerfooter.sty--custom headers and footers To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2E3F202342000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS A new version of headerfooter.sty dated 13 April 1989 has been submitted to the archive by its author Stephen Gildea. It is available as ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib]headerfooter.sty The following is from the internal documentation: % \pageheader{LEFT}{CENTER}{RIGHT} % \pagefooter{LEFT}{CENTER}{RIGHT} % There is no reason why these commands should not be available % to the user. Of course, I did fancy up the interface a bit. % By mit-erl!gildea 11 October 1986 % minor changes 14 Oct 87 gildea % added \pageheaderlinetrue feature 9 Dec 88 gildea % added \pagefooterlinetrue feature 13 Apr 89 gildea % All of these commands take three arguments, which are printed at % the left, center, and right of each page. All three args must be % provided even if some of them are empty. The odd and even % variations are only useful if you are using the twoside option. % Example: \pagefooter{}{\thepage}{} % Say \pageheaderlinetrue if you want the header underlined. % Say \pagefooterlinetrue if you want a rule above the footer. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:45:14 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17693; Thu, 30 May 91 18:44:23 MDT Date: Thu, 30 May 1991 17:43 PDT From: Don Hosek--ymir archive Subject: UPLOAD: Graham Toal's CM fonts in PS format To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2E51E82EA2000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS The conversion of CM fonts to PS done by Graham Toal and Neil Raine is available as ymir.claremont.edu:[anonymous.tex.fonts.ps]cmrps.tar These are type 3 outlines generated from 3000dpi bitmaps. Please note that these outlines are to be considered experimental and many printers which can print a document using the bitmap fonts cannot print the same document as an outline. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:45:29 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17699; Thu, 30 May 91 18:44:48 MDT Date: Thu, 30 May 1991 17:44 PDT From: Don Hosek--ymir archive Subject: UPLOAD: GLUE.WEB -- Example of WEB from Donald Knuth To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2E62FBD342000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS Don Knuth's glue.web is now available as ymir.claremont.edu:[anonymous.tex.sources.web]glue.web This file is an early example of WEB programming and also supplies an alternate implementation of a portion of TeX's main loop. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:46:00 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17709; Thu, 30 May 91 18:45:25 MDT Date: Thu, 30 May 1991 17:44 PDT From: Don Hosek--ymir archive Subject: UPLOAD: voorbeeldom.sty--Environment for typesetting linguistics examples To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2E73786802000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just uploaded ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib]voorbeeldom.sty This is a set of macros for typesetting linguistics examples posted to comp.text.tex on 28 May 1991 by the author. The following is from the internal documentation: %I wrote the following for someone wanting the same sort of thing. %It is called `voorbeelden' (Dutch for examples), but the name %could be changed. Use it as %\begin{voorbeelden} %\item \begin{voorbeelden} \item Bla, bla, bla ... % \item Bla, bla, bla ... % \item Bla, bla, bla ... % \end{voorbeelden} %\item More bla bla %\end{voorbeelden} -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:46:29 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17714; Thu, 30 May 91 18:45:52 MDT Date: Thu, 30 May 1991 17:45 PDT From: Don Hosek--ymir archive Subject: UPLOAD: warn.sty--print line number in LaTeX warnings To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2E87AB9C22000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just uploaded ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib]warn.sty This is a little style option which causes LaTeX to print the line number in warning messages. It requires TeX 3.0 or above. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:47:05 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17725; Thu, 30 May 91 18:46:27 MDT Date: Thu, 30 May 1991 17:45 PDT From: Don Hosek--ymir archive Subject: UPLOAD: TeX & TUG news--new subarchive at ymir To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2E98791002000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS A new subarchive has been installed for archiving TeX & TUG news, a prototype new publication of the TeX Users Group. Complete issues and the LaTeX style file associated with them are stored in ymir.claremont.edu:[anonymous.tex.periodicals.tugnews] Files in this archive are received directly from Ron Whitney at the TeX Users Group. The following is from the first issue (v0n0): TeX & TUG News is a newsletter for TeX and LaTeX users alike: a forum for exchanging information, tips and suggestions; a regular means of communicating news items to one another; a place where information about TeX and TUG can be quickly disseminated. Throughout the newsletter "TeX" is understood to mean TeX, LaTeX, AmSTeX, and other related programs and macros. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:47:47 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17732; Thu, 30 May 91 18:47:06 MDT Date: Thu, 30 May 1991 17:46 PDT From: Don Hosek--ymir archive Subject: UPLOAD: label.tex--print 3up labels with plain TeX To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2EA961FB22000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just uploaded ymir.claremont.edu:[anonymous.tex.inputs.plain-contrib]label.tex which is a set of macros for printing labels on 3x11 label paper. It was posted to comp.text.tex on 23 May 91 by the author, Tom Rokicki. The following is from the internal documentation: % Either: % \address 3 % % then enter three addresses, blank lines between them, or % % \faddress foo.tex % % where foo.tex contains a bunch of labels, with blank lines between them. % % Make sure to use \done to exit, rather than \bye. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:48:15 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17735; Thu, 30 May 91 18:47:33 MDT Date: Thu, 30 May 1991 17:46 PDT From: Don Hosek--ymir archive Subject: UPLOAD: TeX/mathematica interface new version To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2EB96170A2000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS A new version of the TeX-mathematica interface has been uploaded in ymir.claremont.edu:[anonymous.tex.graphics.mathematica]. The files were obtained by anonymous FTP from chem.bu.edu on 30 May 1991. Users of previous versions can obtain changes.txt to determine what is new/different. The following is extracted from 00readme.txt: -TeX/Mathematica is a set of tools that provide facilities of -Mathematica Notebooks in a UNIX environment, under GNU Emacs. They -permit interaction between a text and a Mathematica buffer and, if -desired, the use of TeX/LaTeX to annotate Mathematica-based -explorations and programs. Inclusion of Mathematica-generated -graphics in TeX/LaTeX documents printed using PostScript is -supported. The tools also support the automatic generation of -Mathematica packages from Mathematica documents. -dh -- Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:48:43 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17739; Thu, 30 May 91 18:48:00 MDT Date: Thu, 30 May 1991 17:47 PDT From: Don Hosek--ymir archive Subject: UPLOAD: DVI--HP driver in C++ To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2ED45B9162000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've uploaded ymir.claremont.edu:[anonymous.tex.drivers.dvi]cppdvi.tar_z a DVI driver for HP LaserJets written in C++. It was received on 30 May 1991 from the author. The following is excerpted from the readme file (available in the same directory): This is the TeX DVI filter which I'd written it about 4 years ago when, at that time, the only LaserJet DVI filters available to me were in Pascal and ungodly slow. Anyway, it's been pointed out to me that "dvi" still one of the better DVIs around, so I figured it was time to get off my duff and make it available to the world at large. Or at small - I'm not picky. The man-page lists all the pertinent details, but here's some highlights: o fast o written in C++ o supports LaserJetII, LaserJetIID, LaserJet2000, and LaserJet+ o supports double-sided printing on LJs which can do double-sided o supports landscape printing for slides o handles big fonts, like, for instance, SliTeX dumps o supports JTeX - the Japanese version of TeX which heavily exercises the font capabilities of the LJs and of "dvi" o allows selecting particular pages and page ranges from the command line (OK - it ain't clean or friendly, but it works) o supports various \specials for dumping raw PCL files - it is also pretty easy to add new specials o completely demand driven - not even the font info much less the info for a particular character is downloaded unless that character is actually going to be printed on the paper o does NOT send a hard-reset escape-sequence, which allows one to wrap anything around this dvi's output that one wishes o has cool (well - entertaining anyway) -v verbose mode o actually has a man-page o the price is right -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:49:34 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17744; Thu, 30 May 91 18:48:52 MDT Date: Thu, 30 May 1991 17:47 PDT From: Don Hosek--ymir archive Subject: UPLOAD: WEB in C by Sylvio Levy and D.E. Knuth To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2EE6C688A2000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just downloaded version 2.0 of the CWEB system by Sylvio Levy and Donald Knuth. The files are stored in ymir.claremont.edu:[anonymous.tex.utilities.cweb] with examples in ymir.claremont.edu:[anonymous.tex.utilitiex.cweb.examples] The files were obtained by anonymous FTP from labrea.stanford.edu on 30-May-1991. CWEB is an implementation of WEB adapted to the C language. The changes for version 2.0 were implemented by Donald Knuth, the original author of the WEB system. Included in the package are a Unix manpage and EMACS lisp mode for editing CWEB code. Special changes necessary for VMS and Sunview are also included. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Thu May 30 18:51:10 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17748; Thu, 30 May 91 18:50:32 MDT Date: Thu, 30 May 1991 17:49 PDT From: Don Hosek--ymir archive Subject: UPLOAD: LaCheck--LaTeX consistency checker To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <2F25BC6482000AB0@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just uploaded ymir.claremont.edu:[anonymous.tex.utilities.lacheck]lacheck1_9.shar This file was obtained by anonymous FTP from iesd.auc.dk on 30-May-1991. The following is from the man page: lacheck is a general purpose consistency checker for LaTeX documents. It reads a LaTeX document and displays warning messages, if it finds bad sequences. It should be noted, that the badness is very subjective. The things checked are: Mismatched groups (braces), environments and math mode del- imiters. When a mismatch is found, line numbers for both start and end of the mismatch is given. The error messages comes in pairs, one for the end match and one for the begin- ning, marked with `<-' and `->' respectively. Bad spacing. This is: missing a `\ ' after an abbreviation, missing an `\@' before a punctuation mark in a paragraph that is ended by an capital letter, double spaces like ` ~', bad usage of ellipsis (like using ... instead of \ldots, or using \ldots where \cdots should be used) lacheck will read files that are input using \input or \include. Files with suffix `.sty' are omitted, as they probably will cause errors. -dh -- Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:29:48 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20018; Fri, 31 May 91 02:26:19 MDT Date: Fri, 31 May 1991 01:25 PDT From: Don Hosek--ymir archive Subject: UPLOAD: sober.sty--reduced space around heads in LaTeX To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6EDB965A62000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I have just uploaded ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib]sober.sty The file was obtained from listserv@hearn on 30-May-1991. This style option reduces the spacing around section headings in the default document styles. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:29:49 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20024; Fri, 31 May 91 02:26:44 MDT Date: Fri, 31 May 1991 01:26 PDT From: Don Hosek--ymir archive Subject: UPLOAD: Dutch hyphenation patterns To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6EEB913C02000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I have just uploaded ymir.claremont.edu:[anonymous.tex.babel.dutch]nehyph*.tex >From listserv@hearn These are three sets of Dutch hyphenation patterns, as listed below: * neHyph1 TeX : shortened Celex-list, all lines with a 5 in them removed, * in order to be able to load it when you can't stretch * the 'triesize' * neHyph2 TeX : long and powerful (author: Celex, Nijmegen) * Note that this requires stretching the 'triesize' * of both TeX and IniTeX! * neHyph3 TeX : The (very short) patterns for Dutch created by Peter Vanroose -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:29:58 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20030; Fri, 31 May 91 02:27:33 MDT Date: Fri, 31 May 1991 01:26 PDT From: Don Hosek--ymir archive Subject: UPLOAD: brief.sty--NEN-conformant letter style To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6F06B79CE2000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I have just uploaded brief.sty, brief.tex and briefdoc.tex to ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib] The files were obtained from listserv@hearn. These styles are a revised letter style according to Dutch NEN norms. -dh -- Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. I have just uploaded brief.sty, brief.tex and briefdoc.tex to ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib] The files were obtained from listserv@hearn From "Don Hosek--ymir archive " Fri May 31 02:29:59 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20015; Fri, 31 May 91 02:25:51 MDT Date: Fri, 31 May 1991 01:25 PDT From: Don Hosek--ymir archive Subject: UPLOAD: babel system of style options To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6ECC203922000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just uploaded the babel system of style options to ymir.claremont.edu:[anonymous.tex.babel.babel-system] The system came with support for several languages whose files have been moved to the appropriate subdirectories: ymir.claremont.edu:[anonymous.tex.babel.dutch]dutch.doc/sty ymir.claremont.edu:[anonymous.tex.babel.english]english.doc/sty ymir.claremont.edu:[anonymous.tex.babel.french]francais.doc/sty ymir.claremont.edu:[anonymous.tex.babel.german]germanb.doc/sty ymir.claremont.edu:[anonymous.tex.babel.italian]italian.doc/sty ymir.claremont.edu:[anonymous.tex.babel.spanish]spanish.doc/sty All of the above files were obtained from listserv@hearn on 30-May-1991. In addition, as they are created, styles for other languages will be placed in their subdirectories as necessary. This includes, at present ymir.claremont.edu:[anonymous.tex.babel.russian]russian.sty The below was excerpted from the readme file: I am pleased to announce the babel system of style options to be used with the standard LaTeX document styles. This system consists of any number of language-specific files and an underlying common file, babel.sty. The common file redefines various parts of the standard document styles, replacing english texts with macros. These macros are defined in the language-specific files that will be published in TUGboat. Currently I have language-specific files for dutch (ofcourse), german, english french, italian and spanish. (For the german and french parts I used Hubert Partl's german.sty) An extra feature of this system is that it offers a possibility to switch between languages. Anyone who likes to test this, please contact me. Please not that this is quite a different approach as the one discussed by Joachim Schrod in TUGboat Volume 11 No1. He describes a system where the actual LaTeX sources files are modified and a new .fmt file has to be built. All of that is not necessary to use my approach. -dh -- Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:30:08 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20027; Fri, 31 May 91 02:27:10 MDT Date: Fri, 31 May 1991 01:26 PDT From: Don Hosek--ymir archive Subject: UPLOAD: Extended US English hyphenation patterns To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6EF952F682000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I have just uploaded ymir.claremont.edu:[anonymous.tex.babel.english]ushyph2.tex >From listserv@hearn This file contains extended hyphenation patterns which can correctly hyphenate all words in the TUGboat hyphenation exception log. An extended trie size is necessary to use these patterns. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:30:09 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20009; Fri, 31 May 91 02:25:23 MDT Date: Fri, 31 May 1991 01:24 PDT From: Don Hosek--ymir archive Subject: UPLOAD: a4.sty--new version To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6EBB9F1082000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just uploaded a new version of a4.sty with a revison date of 30 November 1990 to ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib]a4.* a4.sty is the production file, a4.tex and a4.doc provide the documentation (using the doc style option from [anonymous.tex.inputs.latex-mainz]) The files were obtained from listserv@hearn on 30-May-1991. This style option is the preferred method for setting page dimensions for use with A4 paper. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:30:22 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20036; Fri, 31 May 91 02:28:13 MDT Date: Fri, 31 May 1991 01:27 PDT From: Don Hosek--ymir archive Subject: UPLOAD: eslides.sty--typeset transparancies with LaTeX not SliTeX To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6F22720062000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I have just uploaded the eslides package consisting of eslides-example.tex, eslides.sty, eslides.tex and logo-denk.tex to ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib] The files were obtained from fileserv@shsu on 23-May-1991. eslides.sty provides a mechanism for producing transparencies with LaTeX and was written up in TUGboat 11#2. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:30:23 1991 Flags: 000000000000 Return-Path: Received: from GAUSS.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20033; Fri, 31 May 91 02:27:57 MDT Date: Fri, 31 May 1991 01:27 PDT From: Don Hosek--ymir archive Subject: UPLOAD: program.sty--Typeset program fragments in LaTeX To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6F1446FCC2000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I have just uploaded program.sty and program-example.tex to ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib] The files were obtained from fileserv@shsu on 23-May-1991. The following was excerpted from the internal documentation: % This is the "program" style option which sets up the % program and programbox environments, % keywords for programs and a few goodies. % NOTE: Within the program environment: % (1) Newlines are significant. % (2) Each line is in math mode, so for example spaces in the input % file are not significant. % (3) \\ within a line causes a linebreak in the output. % % We also define a "programbox" environment which typesets a program in a box. % Useful for keeping a piece of code on one page or for typesetting small % programs in running text. % We also redefine \( and \) as \begin{programbox} and \end{programbox}. % The \tab and \untab commands are defined to have no effect while outside % a program environment, hence a single-line program can be typeset in % maths mode without the overhead associated with programbox. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:30:31 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20006; Fri, 31 May 91 02:24:54 MDT Date: Fri, 31 May 1991 01:24 PDT From: Don Hosek--ymir archive Subject: UPLOAD: supertab.sty--new version To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6EABED6CE2000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS The latest version of supertab.sty has been uploaded as ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib]supertab.* It was FTP'd from archive.cs.ruu.nl on 30-May-1991. supertab.sty defines a supertabular environment which works like tabular but can be split across pages with recurring table heads and feet. This version includes bug fixes and enhancements added by Johannes Braams. The following is excerpted from the change listing: % 15.02.91 - Because of the check for the use of tablefirsthead the % V 3.6a combination of an \hline in the head and an \hline as the first % thing in the data went wrong. The \futurelet in the definition % of \hline found \fi instead of \hline, so no \doublerulesep % was added. % Also had to modify the way the environments were defined. % The blank space (from the CR after the argument of \supertabular) % has to be gobbled. This can only be done using a construction % like \def\command#1 {...}. So removed the use of \newenvironment % 04.02.91 - Added the commands \topcaption, \bottomcaption and \tablecaption % V 3.6 to include a caption within the supertabular environment. The % default behaviour is to put the caption before the actual start % of the table. % - Also added \tablefirsthead and \tablelasttail to let the % user specify a different head for the first page of the table % and for consecutive pages as well as different tails for first % pages and the last one. If these commands are not used, the % default behaviour will be to use the value of \tablehead end % \tabletail % - Removed the need for the \noalign{\global\let\\=\@stabularcr} % commands by storing and resetting \@stabularcr % % 16.10.90 Added the supertabular* environment that was in an earlier % V 3.5 version (2.0) by the original author % Reintroduced the version numbering -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:30:45 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20050; Fri, 31 May 91 02:28:39 MDT Date: Fri, 31 May 1991 01:28 PDT From: Don Hosek--ymir archive Subject: UPLOAD: unixman.sty--Manpage-like formatting for LaTeX To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6F3093DC42000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I have just uploaded ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib]unixman.sty/tex The files were posted to comp.text.tex by the author on 12-April-1991. It provides output somewhat like that given by [a-z]roff manual pages. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:31:04 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20053; Fri, 31 May 91 02:29:05 MDT Date: Fri, 31 May 1991 01:28 PDT From: Don Hosek--ymir archive Subject: UPLOAD: inspec2bibtex.el--convert inspec files to BibTeX To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6F3E340502000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just uploaded ymir.claremont.edu:[anonymous.tex.bibtex.utilities]inspec2bibtex.el The file was received direct from the author. This emacs lisp file can be used to convert inspec format bibliographies to BibTeX format. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:31:42 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20056; Fri, 31 May 91 02:29:30 MDT Date: Fri, 31 May 1991 01:28 PDT From: Don Hosek--ymir archive Subject: UPLOAD: revtex--LaTeX styles for Physical Review To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6F4BB5A942000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS I've just uploaded the revtex 2.0 package to ymir.claremont.edu:[anonymous.tex.inputs.latex-contrib] The files were obtained by anonymous FTP from niord.shsu.edu on 31-May-1991 The following is excerpted from revtex.readme in that directory: % This file is part of a compuscript toolbox distributed by % the American Physical Society in conjunction with % the TeX author-prepared program. The complete toolbox % contains: % % README this file % APGUIDE.TEX The TeX Author Prepared Input Guide. % APS.STY THE APS style file. % APS10.STY The style file for galley output. % REVTEX.STY The REVTEX style file. % PREPRINT.STY A style file for preprint output. % EQSECNUM.STY A style file to number equations by section. % SMPLEA.TEX Brief sample of REVTEX use. % SMPLEB.TEX A complete Physical Review paper, galley format. % SMPLEC.TEX SMPLEB.TEX, in preprint format. -dh Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique. From "Don Hosek--ymir archive " Fri May 31 02:31:51 1991 Flags: 000000000000 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20061; Fri, 31 May 91 02:29:53 MDT Date: Fri, 31 May 1991 01:29 PDT From: Don Hosek--ymir archive Subject: UPDATE: Several .el files moved in ymir archive To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@science.utah.edu Message-Id: <6F59608062000AAA@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: @UPDATE.DIS In retrospect, I've decided that cnvtbib.el does not properly belong in [anonymous.tex.utilities.emacs-modes] (since it is not properly a "mode"). It has been returned to ymir.claremont.edu:[anonymous.tex.bibtex.utilities]cnvtbib.el Also, the files for the WEB Emacs mode have been moved from [anonymous.tex.utilities.web-emacs-mode] to ymir.claremont.edu:[anonymous.tex.utilities.emacs-modes] see the 00readme.txt file in that directory to see which files are which. From "Mail Delivery Subsystem " Fri May 31 08:44:49 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB20977; Fri, 31 May 91 08:43:53 MDT Date: Fri, 31 May 91 08:43:53 MDT From: Mail Delivery Subsystem Subject: Returned mail: Cannot send message for 3 days Message-Id: <9105311443.AB20977@math.utah.edu> To: beebe ----- Transcript of session follows ----- Connected to relay.cs.net: >>> MAIL From: <<< 451 Nameserver timeout during parsing Connected to ics.uci.edu: >>> MAIL From: <<< 451 Nameserver timeout during parsing ----- Unsent message follows ----- Return-Path: Received: from niord.shsu.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01712; Tue, 28 May 91 08:12:40 MDT Received: by Niord.SHSU.edu (MX V2.3) id 28439; Tue, 28 May 1991 09:11:14 CDT Date: Tue, 28 May 1991 09:11:14 CDT From: "George D. Greenwade" To: tex-archive@science.utah.edu Message-Id: <00949454.65B065C0.28439@Niord.SHSU.edu> Subject: RE: Getting archives to conform to each other On Mon, 27 May 1991 16:41 PDT, Don Hosek resumed a very good topic! Ranier's comments which followed are also helpful. I would like to add a few points, as well, if I may (recognizing, of course, that our site is the "baby" among archive sites). > We have in the past begun talking about trying to standardize archive > structures and let it slip off, I'd like to try and restart that > discussion, if we can. > It seems to me that we want the following out of a global structure to an > archive: > - It should be as system-independent as possible. We have four types of s > systems hosting archives at present: And, once again, I will argue that the filename syntax should also be as system-independent as possible (8.3) for files with general applicability. This, naturally, means that (for example) VMS-specific EXE files, etc., can avoid 8.3 filename structure, but for most files, we have to recognize that TeX and its variants are, for the most part, platform independent. > - It should be structured in a logical way so that someone browsing has > a good chance of locating the files that they want easily Hence, a few major (i.e., first-level) subdirectories with multiple branched trees (like YMIR and Aston) or many major subdirectories (like SHSU)? You cannot believe the amount of mail I receive weekly (usually around 15 totally non-requested responses) from users worldwide who compliment our simplistic approach (put on us by our software -- it was not an intentional design originally, but is now one I think needs consideration). While we now support ftp, I hope we will always be noted for FILESERV (I have nothing to really compare our performance against, but an average ot 200+ TeX-related transfers daily isn't real bad, I don't think)! I can see that many first-level subdirectories would be required to achieve a large archive (and we do hope to join the world of big repositories -- we've recently ordered a 1.5 gig device for TeX archive support alone and plan on getting the Aston tapes as soon as we have the space on-line). > - It should be structured in such a way so that sites can easily only > support the parts of the archive that they find appropriate. Which many major subdirectories allows for (at least accroding to my mail). Presently, I am also involved in the IETF list server device project (don't ask how an economist got on this one). Standards and an ultimate RFC will come from this group (yes, something like a LISTSERV, but for VMS and U*ix platforms -- maybe even DOS! -- and since Eric Thomas is tangentially involved, I expect he will have a revised revised LISTSERV sometime in the future to meet these standards for VM/CMS). We've even discussed peering in the context of file servers (like mail server peering for subscribe and signoff now on LISTSERV, but for file requests!). While I cannot say at this juncture precisely how or what this beast will evolve into, it appears that multiple-level directory trees will be supported. I expect that the fruits of this project (at least on the VMS side) will be a public domain application, so our discussion of standardization maybe should be put on hold until at least command and directory design in addressed by this committee (one of the earliest topics scheduled in designing the architecture -- hopefully to be basically outlined this summer). I am making the humble assumption that VMS sites would wish to follow along on the standard now in development (possibly a very bad assumption) since it is being designed with all existing mailers, NJE transport agents (file transport, where supportable), and major TCP/IP drivers in mind (lots and lots of documented hooks!). Anyway, as noted earlier, we are a very young site with great aspirations. Our present directory structure for FILESERV (which is imposed on ftp) is: AMSLATEX_DOC AMS-LaTeX distribution; the doc subdirectory AMSLATEX_FONTSEL AMS-LaTeX distribution; fontsel subdirectory AMSLATEX_INPUTS AMS-LaTeX distribution; inputs subdirectory DVI2TTY Files for DVI2TTY (for VMS) DVIDVI Files for DVIDVI (for VMS) DVIPS547 Files for version 5.47 of DVIPS (for VMS) DVITOLN03 Files for DVItoLN03 (for VMS) EEPIC Files for eepic (LaTeX Extensions to EPIC) EPIC Files for epic (LaTeX Enhanced Picture Environment) ESSENTIAL Files for John Warbrick's "Essential LaTeX" FAQ comp.text.tex's "Frequently Asked Questions" and "FAQ Supplement" GENTLE Files for Michael Doob's "A Gentle Introduction to TeX" INFO-TEX INFO-TeX archives (TeX-related discussion list) LZW Files for Lempel-Ziv-Welch file compression/decompression (for VMS; output is optionally Unix-compatible) LZW_SOURCES C source code for LZW (above) MFTU Files for Mail File Transfer Utility (encoding/decoding; VMS) MODES Files for Karl Berry's MODES.MF REVTEX Files for American Physical Society's REVTEX Version 2.0 STY LaTeX style file archives TEXHAX TeXhax Digest archives TEXMAG TeXMaG archives TEXSERVER HELP file from TeXServer@TeX.ac.uk TEX_PRIMER Files for Joe St Sauver's "Using TeX on the VAX to Typeset Documents: A Primer" TROFFTOTEX Files for TROFFtoTeX (LaTeX version) TUGABS Abstracts of TeX Users Group Proceedings for various years. UKTEX UKTeX Digest archives I left in LZW, LZW_SOURCES, and MFTU as we use these for non-ftp delivery (i.e., can send binaries and backup savesets via MAIL). These all represent first-level subdirectories. Virtually all of these have compressed files for ftp in a second-level subdirectory named [.ftp]. While this does use more space, users seem to really like it, especially on the ftp side since ftp stuff is in a true ftp area associated with the directory). Well, now it's time to flame this simplistic approach. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG P. O. Box 2118 Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341 Internet: bed_gdg@Niord.SHSU.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "bbeeton " Sun Jun 2 11:21:45 1991 Flags: 000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02482; Sun, 2 Jun 91 11:16:53 MDT Date: Sun 2 Jun 91 11:35:45-EST From: bbeeton Subject: re: getting archives to conform to each other To: tex-archive@csc-sun.math.utah.edu Message-Id: <675876945.0.BNB@MATH.AMS.COM> Mail-System-Version: i applaud the discussion on this topic and hope that something useful comes of it. i would like to throw in my own two cents' worth of opinions. first, let me give you a user's perspective on what is helpful and what is not. i periodically access various archives via ftp to retrieve recent information, including the current tree structure. since i have promised don knuth that i would try to keep tex implementors informed of updates, my primary target is labrea. i used to have a dec-20 available, and the stanford archive also used to be on a dec-20; both are now gone. one of the beauties of the dec20 ftp facility was that it could retrieve with one command the entire tree structure and file name content of the tex area. although it took a long time to do it, and more than once the net connection went south in the middle, it was possible to get everything i wanted with a single command and an occasional look at the terminal while i did something else; it was possible to start it up at 1 a.m. on sunday and not have to worry that my brain was too befogged to do the right thing. the stanford archive is now on a unix box, and i am stuck with vms. unless there is something i haven't yet discovered about the vms version of ftp (i really hope there is; it would make my life much simpler!), it is impossible to scan more than one level of a directory tree at a time (at least the unix directories at labrea); then, each lower level has to be explicitly accessed a node at a time, and so on and so on. what used to be a relatively painless operation is now about an hour and a half of obnoxious, error-prone typing. this does not necessarily make me favor a single-level structure such as the shsu software currently requires, but i can get rather violent about the unavailability of competent tools on these "advanced" operating systems. count me as favoring the simplest scheme available that is reliable, comprehensible, and (relatively) universal. i agree with the concept of breaking down the structures into minor archives, to simplify maintenance for all parties -- originators of archived material, archive maintainers, and end users. i cannot agree with don hosek's decision to ignore the directory substructure associated with the amsfonts (why did he bother to keep that for ams user guidelines, where it's much less of a problem to keep things straight?). granted, it may not be the most elegant structure, but it was created with an eye towards maintenance by the ams technical support staff. since the ams staff is not familiar with the structure used at ymir, and all our published documentation refers to the structure in which we released the package, we are in no position to answer questions from users who have not followed our instructions, and cannot recommend that anyone retrieve the files from ymir, where we cannot guarantee that they will be able to find everything they need in one place, not confused with other versions from other sources. (i was on the spot the other day when a call came in from a confused and unhappy user saying that the ams symbols macros for ams-latex didn't work. it turned out that he was using a file by the same name that was distributed with lamstex, that wasn't identical to the ams-latex version in important ways. that's not something we really knew about before, and believe that archive practices shouldn't exacerbate the problem.) the file name "readme" is a good example of guaranteed name overlap -- i'd like to see this problem addressed here. i see in several of the structure descriptions directory nodes (several from labrea, e.g. mf and mfware) that are marked "to go away". it's unclear to me what is to replace these; i'm fairly certain that the *contents* aren't just going to be tossed on the the trash heap. i would like to see some thought given to naming conventions that could be recommended for use by users transferring files to ms-dos (and some other) systems, where there is an 8+3 filename limit. i am not saying that the archives should use this scheme, only that one be devised and the principles for conversion of names should be well documented and advertised. (the editor of tugboat will be delighted to publish a description of such a common scheme when one is accepted.) on another matter, i would like to suggest that the compression scheme that has been under construction for some time (vvencode?) be adopted as soon as implementations of that software have been generated for a very large proportion of the platforms on which tex systems are used. a week or so ago, we at tugboat received a uuencoded/compressed file for a very important, and overdue, article. none of the decompression software we had available succeeded in making anything useful out of it (we tried this under vms, ultrix, and ms-dos, with all the varieties of tools that we could find), and finally the solution was to put the "cleartext" version somewhere we could retrieve it by ftp. this was very frustrating to all -- we really need a better mousetrap. finally, concerning documentation, perhaps this is an area where volunteers could be useful. there are probably people out there who would be willing to look at the contents of a subdirectory and write short descriptions for an index. this "only" needs to be organized and monitored, and the result could be posted to every archive and be useful for everyone. i suggest it might start with example descriptions of a dozen or so items, including a couple from each of the most important categories (say programs like texware, a major plain macro package like edmac, a major latex macro package like babel, a few "standalone" macro files, etc.). features to be included in a description might be name(s) of file(s), type of item (program source, macro usable with amstex, text font - non-cm, etc.), purpose, keywords, special needs (modula compiler, big tex, etc.), archives where it can be found, ... these could be given to volunteers as models, along with assignments to (say) cover all files in a particular archive directory that begin with a range of letters, say a-g. it really would be important to monitor this, and find someone willing to be an editor of the final product, as well as finding someone to keep it up after the initial phase. this would require cooperation among archive maintainers, so that nothing new gets either left out or duplicated. not an easy task, but well worth trying to do right. -- bb ------- From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Sun Jun 2 12:48:03 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02693; Sun, 2 Jun 91 12:45:03 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA05913; Sun, 2 Jun 91 19:50:52 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA16131; Sun, 2 Jun 91 19:50:50 +0200 Date: Sun, 2 Jun 91 19:50:50 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9106021750.AA16131@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: BNB@MATH.AMS.COM Cc: tex-archive@csc-sun.math.utah.edu In-Reply-To: bbeeton's message of Sun 2 Jun 91 11:35:45-EST <675876945.0.BNB@MATH.AMS.COM> Subject: re: getting archives to conform to each other Barbara writes: ... vms. unless there is something i haven't yet discovered about the vms version of ftp (i really hope there is; it would make my life much simpler!), it is impossible to scan more than one level of a directory tree at a time (at least the unix directories at labrea); No, it's not a problem of VMS ftp. Just append the -R flag to the ls command. This is usually passed on "as is" to Unix, where it means "list recursively". Voila! the file name "readme" is a good example of guaranteed name overlap -- i'd like to see this problem addressed here. Well, it should read "readme.amslatex" or "amslatex.readme" then. i see in several of the structure descriptions directory nodes (several from labrea, e.g. mf and mfware) that are marked "to go away". it's unclear to me what is to replace these; i'm fairly certain that the *contents* aren't just going to be tossed on the the trash heap. In the case of the Stuttgart archive I did this since I consider a directory name of "mf" or "mfware" as almost useless, since not specific enough. What do you expect to find there? Just Remove these directories and create others like "mf-sources", "mf-inputs", etc. LaBrea's directory tree is an example of how it should *not* be. Don't get me wrong: I'm not blaming anyone for this. But that's what makes a multi-level structure inferior to George's simple one: too many levels where some of them do not give information what they contain. i would like to see some thought given to naming conventions that could be recommended for use by users transferring files to ms-dos (and some other) systems, where there is an 8+3 filename limit. i am not saying that the archives should use this scheme, only that one be devised and the principles for conversion of names should be well documented and advertised. (the editor of tugboat will be delighted to publish a description of such a common scheme when one is accepted.) Agreed. on another matter, i would like to suggest that the compression scheme that has been under construction for some time (vvencode?) be adopted as soon as implementations of that software have been generated for a very large proportion of the platforms on which tex systems are used. a week or so ago, we at tugboat received a uuencoded/compressed file for a very important, and overdue, article. none of the decompression software we had available succeeded in making anything useful out of it (we tried this under vms, ultrix, and ms-dos, with all the varieties of tools that we could find), and finally the solution was to put the "cleartext" version somewhere we could retrieve it by ftp. this was very frustrating to all -- we really need a better mousetrap. Vvencode will be released soon; we have prototype implementations for (several flavors of) Unix, VMS, MS-DOS, VM/CMS. As for compression, I have now settled with zoo; it is not the most advanced program with respect to speed and compression factor, but it's the most reliable and available on more platforms than any other. Rainer From "bbeeton " Sun Jun 2 14:29:21 1991 Flags: 000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02969; Sun, 2 Jun 91 14:25:57 MDT Date: Sun 2 Jun 91 16:24:51-EST From: bbeeton Subject: re: getting archives to conform to each other To: schoepf@sc.ZIB-Berlin.DE Cc: tex-archive@csc-sun.math.utah.edu Message-Id: <675894291.0.BNB@MATH.AMS.COM> In-Reply-To: <9106021750.AA16131@sc.zib-berlin.dbp.de> Mail-System-Version: rainer's suggestion to use -R on the ftp command finally worked, although i have to use the "directory" command and not "ls" (which >From vms gets only the file names, no dates, hence is useless for seeing what's got new versions). thanks, rainer. regarding "readme" files, here's what's at labrea -- there are a bunch from ams, but we're not the only ones. i'd like to see a suggestion that will work well on an ms-dos diskette distribution; "readme.amslatex" or "amslatex.readme" won't. README Apr 29 1990 /tex root directory README Oct 23 1985 /tex/cm README Apr 8 19:06 /tex/contrib/aps (american physical society) README Aug 30 1990 /tex/contrib/karl_berry README Oct 10 1990 /tex/cweb README Mar 15 1989 /tex/unix README.TeX3.0 Sep 18 1990 /tex/unix3.0 READ.ME Aug 9 1990 /tex/ams/amsfonts READ.ME Aug 9 1990 /tex/ams/amsfonts/sources READ.ME Aug 9 1990 /tex/ams/amslatex READ.ME Aug 9 1990 /tex/ams/amslatex/doc READ.ME Aug 9 1990 /tex/ams/amslatex/fontsel READ.ME Aug 9 1990 /tex/ams/amslatex/inputs READ.ME Aug 9 1990 /tex/ams/amstex read.me Mar 21 1986 /tex/ln03 perhaps i don't have a problem with the names "mf" and "mfware" because i've been using the stanford directory structure since 1980. (i find the "-ware" name quite descriptive, actually -- it denotes utilities that work with files required by or created by the named "main" program.) but i certainly won't object to a change of names. {\em just as long as everybody agrees on them and uses them consistently for the same things}. {\em and i mean *all* archives, and preferably tape distributions too.} i don't believe we have a copy of the zoo programs that i can access. can you tell me where we can get a vms implementation? what language are they written in? what platforms *is* zoo implemented on? -- bb ------- From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Sun Jun 2 14:34:42 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03016; Sun, 2 Jun 91 14:34:01 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA06036; Sun, 2 Jun 91 22:34:33 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA16328; Sun, 2 Jun 91 22:34:30 +0200 Date: Sun, 2 Jun 91 22:34:30 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9106022034.AA16328@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: BNB@MATH.AMS.COM Cc: schoepf@sc.ZIB-Berlin.DE, tex-archive@csc-sun.math.utah.edu In-Reply-To: bbeeton's message of Sun 2 Jun 91 16:24:51-EST <675894291.0.BNB@MATH.AMS.COM> Subject: zoo Barbara, zoo is written in C. A while ago I sent the zoo sources to Michael Downes. I think he tried to compile them, but I don't know whether he got a running version. As far as i know zoo is available on Unix, VMS, VM/CMS, Atari ST, MS-DOS, Macintosh (the latter only from hearsay). There are still some problems with it when transfer of binary files between different platforms is involved, mostly coming from the different types of file systems (e.g., record structured vs. stream). But binary files tend to be non-portable anyway... Rainer From "Don Hosek " Mon Jun 3 05:43:03 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05055; Mon, 3 Jun 91 05:42:16 MDT Date: Mon, 3 Jun 1991 04:41 PDT From: Don Hosek Subject: Re: zoo To: tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: TEX_ARCHIVE I've heard back from our system wizard and we have the most recent zoo that he's aware of. The problem is that it doesn't always work (the instance that I encountered was with the file hptogf.zoo from whichamacallit.something.de. Some other zoo file I received had an identical problem. The same archives unpack fine on Unix and DOS. The problem seems to be with the author's lack of experience with RMS record access under VMS. tar almost works for me, but tar files seem to fall into two sets: some can't be unpacked with one of our VMS tar utilities and others can't be unpacked with the other. I haven't encountered any yet that can't be unpacked with either, but time will tell... my DOS tar utility has been reasonably reliable but large files leave it in the dust. Work is being done on zip for multiple platforms but... My reaction to the whole situation has been to simply avoid packaging files whenever possible. The cases where I've left files archived have almost always been when the files were of a system-dependent nature (e.g., most DOS files are in ZIP format, most Unix in tar, etc.) -dh From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Mon Jun 3 05:43:19 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05056; Mon, 3 Jun 91 05:42:21 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA09996; Mon, 3 Jun 91 12:32:43 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA17150; Mon, 3 Jun 91 12:32:41 +0200 Date: Mon, 3 Jun 91 12:32:41 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9106031032.AA17150@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: BNB@MATH.AMS.COM Cc: schoepf@sc.ZIB-Berlin.DE, tex-archive@csc-sun.math.utah.edu In-Reply-To: bbeeton's message of Sun 2 Jun 91 16:24:51-EST <675894291.0.BNB@MATH.AMS.COM> Subject: re: getting archives to conform to each other Barbara writes: rainer's suggestion to use -R on the ftp command finally worked, although i have to use the "directory" command and not "ls" (which from vms gets only the file names, no dates, hence is useless for seeing what's got new versions). thanks, rainer. You're welcome. Actually, for Unix systems the "dir" command is equivalent to the "-l" flag, so you can also write "ls -lR". There are a number of other useful flags: -r reverse sort order -s report size -t sort by time modified -u use time of last access instead of last modify Rainer From "Don Hosek " Mon Jun 3 06:06:06 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05094; Mon, 3 Jun 91 06:05:27 MDT Date: Mon, 3 Jun 1991 05:04 PDT From: Don Hosek Subject: FTP access modes To: tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: TEX_ARCHIVE please note that FTP interfaces differ from platform to platform and from implementation to implementation so not all the neat tricks that work on Unix/DEC-20/VMS FTP will translate properly. A couple prime examples include the fact that Unix FTP will gladly transfer directory trees, but Multinet FTP doesn't handle the responses from the remote FTP server very well. Of course VM/CMS FTP doesn't even acknowledge directory trees: its cd command really means change disk and its more luck than talent allowing one to use it as change dir and there is no cdup command as provided by other interfaces. -dh From "Don Hosek " Mon Jun 3 06:10:57 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05112; Mon, 3 Jun 91 06:10:27 MDT Date: Mon, 3 Jun 1991 05:09 PDT From: Don Hosek Subject: readme files To: tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: TEX_ARCHIVE There is no great sin in each directory having a common name for a directory-specific readme file. My personal preference is for 00readme.txt as it ends up at the beginning of the directory listing on all systems with directory trees. A package specific readme which must coexist with other package specific readmes should most-likely be named .README (e.g., verbatim.readme). On DOS, I let these names get truncated to *.REA although it wouldn't be a bad plan to manually change this to *.RME (I believe Jon Radel does this in his archive). One other note, speaking from the perspective of an archive-user. With packaged files (zoo/tar/zip/shar/etc), it is really very helpful if a copy of the readme appears outside the packaging. It's nice to be able to avoid transferrÿing a 360K file at 2400bd just to discover that the package is not quite what's desirable (master readme files like that at simtel20 don't always provide enough information to make an informed judgement). -dh From "karl@cs.umb.edu (Karl Berry)" Tue Jun 4 09:49:23 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11941; Tue, 4 Jun 91 09:46:08 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA24314; Tue, 4 Jun 91 11:44:49 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA03616; Tue, 4 Jun 91 11:44:36 EDT Date: Tue, 4 Jun 91 11:44:36 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9106041544.AA03616@ra.cs.umb.edu> To: WSULIVAN%irlearn.bitnet@relay.cs.net Cc: tex-archive@csc-sun.math.utah.edu In-Reply-To: "Wayne G. Sullivan"'s message of Tue, 04 Jun 91 10:50:51 GMT Subject: archives Reply-To: karl@cs.umb.edu Wayne S.> LZW algorithms considerably better than ZOO are publically available The LZW algorithm is patented by Unisys in the United States. It is only their ``good will'' which is allowing compress to be used. We cannot legally use it. (*) > Even for > transmitting tex files which use characters above 127 one needs special > tricks to beat the networks. vvencode should suffice, although I personally don't know where to get it. > A single TeX-specific compression/archive > system seems to offer the best solution. I see compression and archiving as distinct jobs. Perhaps we could start trying to use Dan Bernstein's yabba/unyabba for compression; that, at least, has a chance of remaining legal. > It is an insult to TeX to > subject its files to the likes of some of the compression/encoding schemes > currently in use. That's for sure. I'm not sure exactly what you're proposing for this new archiving program. At the moment, I'm not aware of any archiving program that lets one create an archive with a directory tree structure, and then extract that same directory tree under systems other than the one it was written on. (I'm pretty sure that tar, for example, just puts filenames into the archive, and so foo/bar gets extracted as a file bar in the directory foo only on Unix systems.) I don't see that any archiving program can or should be TeX-specific, though. But discussion of compression and archiving programs is somewhat premature, I think. Until we have (the outlines of) an agreed-on directory structure, we can't make any portable archives anyway. karl@cs.umb.edu (*) Personally, I find software patents abhorrent, and certain to destroy public domain and other free software, retroactively. Although European countries do not have software patents yet, I believe a recently-passed law had much the same effect: computer languages, for example, are now copyrightable. I joined the League for Programming Freedom, an organization devoted to allowing free software to continue to be written. If you would like more information about the LPF, please contact me. From "karl@cs.umb.edu (Karl Berry)" Tue Jun 4 10:08:55 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12021; Tue, 4 Jun 91 10:05:20 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA24549; Tue, 4 Jun 91 12:04:03 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA03916; Tue, 4 Jun 91 12:03:49 EDT Date: Tue, 4 Jun 91 12:03:49 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9106041603.AA03916@ra.cs.umb.edu> To: tex-fonts@math.utah.edu, tex-archive@math.utah.edu, texhax@cs.washington.edu, info-tex@shsu.BITNET Subject: version 1.0 of TeX font naming scheme released Reply-To: karl@cs.umb.edu I have released version 1.0 of my naming scheme for TeX fonts. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/fontname/fontname.texi I will also send it to you by email if you cannot ftp. It is about 25K in size. It is in Texinfo format, so you will need the TeX macros in the file texinfo.tex (distributed with most GNU programs) to be able to print it; that same directory also has a texinfo.tex. The rest of that directory contains the files showing the naming scheme applied to the Computer Modern, AMS, and Adobe fonts. This is an update of my article in TUGboat 11(4). The main changes are a much longer list of typeface families, a somewhat longer exposition of the problems with the naming scheme, and a proposal for another naming scheme for arbitrarily-long names (and a slight enhancement to TeX, approved by Professor Knuth, to allow this). I would very much appreciate any additions, criticisms, or other comments. karl@cs.umb.edu From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Tue Jun 4 10:22:44 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12064; Tue, 4 Jun 91 10:13:15 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA13866; Tue, 4 Jun 91 18:11:25 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA19958; Tue, 4 Jun 91 18:11:22 +0200 Date: Tue, 4 Jun 91 18:11:22 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9106041611.AA19958@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: karl@cs.umb.edu Cc: WSULIVAN%irlearn.bitnet@relay.cs.net, tex-archive@csc-sun.math.utah.edu In-Reply-To: Karl Berry's message of Tue, 4 Jun 91 11:44:36 EDT <9106041544.AA03616@ra.cs.umb.edu> Subject: archives Karl Berry writes: Wayne S.> LZW algorithms considerably better than ZOO are publically available The LZW algorithm is patented by Unisys in the United States. It is only their ``good will'' which is allowing compress to be used. We cannot legally use it. (*) That is not the case for European countries. As far as I understand, even in the U.S. there is still a lawsuit concerning this issue? > Even for > transmitting tex files which use characters above 127 one needs special > tricks to beat the networks. vvencode should suffice, although I personally don't know where to get it. It's not publicly available yet. I hesitate to give a release date...but it is already rather stable already: I successfully transferred a zoo archive from Unix to VM/CMS!! I'm not sure exactly what you're proposing for this new archiving program. At the moment, I'm not aware of any archiving program that lets one create an archive with a directory tree structure, and then extract that same directory tree under systems other than the one it was written on. (I'm pretty sure that tar, for example, just puts filenames into the archive, and so foo/bar gets extracted as a file bar in the directory foo only on Unix systems.) I don't see that any archiving program can or should be TeX-specific, though. zoo can unpack tree structures on other architectures that support a tree structure. The same is true for many tar implementations. The advantage of zoo is that there is only one source, not many different implementations of an algorithm. (I had the problem last week when I tried to use one of the newer LZW implementations, called lharc: files packed on Unix would not unpack on micros.) Rainer From "karl@cs.umb.edu (Karl Berry)" Tue Jun 4 10:28:11 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12144; Tue, 4 Jun 91 10:24:36 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA24806; Tue, 4 Jun 91 12:23:20 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA04168; Tue, 4 Jun 91 12:23:06 EDT Date: Tue, 4 Jun 91 12:23:06 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9106041623.AA04168@ra.cs.umb.edu> To: tex-archive@csc-sun.math.utah.edu In-Reply-To: Rainer Schoepf's message of Tue, 4 Jun 91 18:11:22 +0200 <9106041611.AA19958@sc.zib-berlin.dbp.de> Subject: archives Reply-To: karl@cs.umb.edu Rainer> even in the U.S. there is still a lawsuit concerning [LZW compression]. No doubt there are plenty of lawsuits. But Unisys holds a patent on it, and if you use compress, you are at risk of being sued. The best solution to this, in my opinion, is to abolish software patents. In the meantime, we should try to use some other compression scheme that we can legally use. It's true the patent is only valid in the United States. But the U.S. has a significant fraction of the computers that are running TeX and/or have TeX archives. So we certainly want any scheme to be able to be used in the United States, insofar as possible. If software patents and interface copyright are not abolished, non-commercial software development will no longer be possible in the U.S., and it will be a brave new world. karl@cs.umb.edu From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Tue Jun 4 10:39:46 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12198; Tue, 4 Jun 91 10:33:28 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA13879; Tue, 4 Jun 91 18:33:40 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA19977; Tue, 4 Jun 91 18:33:37 +0200 Date: Tue, 4 Jun 91 18:33:37 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9106041633.AA19977@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: karl@cs.umb.edu Cc: tex-archive@csc-sun.math.utah.edu In-Reply-To: Karl Berry's message of Tue, 4 Jun 91 12:23:06 EDT <9106041623.AA04168@ra.cs.umb.edu> Subject: archives From: karl@cs.umb.edu (Karl Berry) Reply-To: karl@cs.umb.edu Rainer> even in the U.S. there is still a lawsuit concerning [LZW compression]. No doubt there are plenty of lawsuits. But Unisys holds a patent on it, and if you use compress, you are at risk of being sued. The best solution to this, in my opinion, is to abolish software patents. In the meantime, we should try to use some other compression scheme that we can legally use. It's true the patent is only valid in the United States. But the U.S. has a significant fraction of the computers that are running TeX and/or have TeX archives. So we certainly want any scheme to be able to be used in the United States, insofar as possible. If software patents and interface copyright are not abolished, non-commercial software development will no longer be possible in the U.S., and it will be a brave new world. Agreed, on both points. Rainer From "George D. Greenwade " Wed Jun 5 10:34:14 1991 Flags: 000000000001 Return-Path: Received: from niord.shsu.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18413; Wed, 5 Jun 91 10:30:28 MDT Received: by Niord.SHSU.edu (MX V2.3) id 7821; Wed, 05 Jun 1991 11:15:23 CDT Date: Wed, 05 Jun 1991 11:15:23 CDT From: "George D. Greenwade" To: karl@cs.umb.edu Cc: tex-archive@csc-sun.math.utah.edu Message-Id: <00949AAF.10A9E0E0.7821@Niord.SHSU.edu> Subject: RE: archives On Tue, 4 Jun 91 11:44:36 EDT, Karl Berry posted: > The LZW algorithm is patented by Unisys in the United States. It is > only their ``good will'' which is allowing compress to be used. We > cannot legally use it. (*) >... > (*) Personally, I find software patents abhorrent, and certain to destroy > public domain and other free software, retroactively. Although European > countries do not have software patents yet, I believe a recently-passed > law had much the same effect: computer languages, for example, are now > copyrightable. I joined the League for Programming Freedom, an > organization devoted to allowing free software to continue to be > written. If you would like more information about the LPF, please > contact me. Agreed on the entire \footnote. Now on the more pressing matter regarding the Unisys patent. After discussing the general nature of U.S. patent laws with a very good patent/copyright/tradename attorney I know, it is very likely that, should Unisys pursue a defense of LZW, they would have a lot of trouble. Reason: Of the various (apparent) pd applications of LZW (and there are more than a few versions out there), (1) none I have seen states anything about the existence of the patent, and (2) Unisys, who is obviously aware that LZW is in use without this patent notice, has not pursued a clarification to include such a notice. These are the two critical elements in patent law (although software patenting may be such a new area of law that generally agreed principles of traditional law do not hold -- if so, that would have to be documented in the legislation controlling it, something else I have not seen, to date). The U.S. Supreme Court has ruled that "(i)t is incumbent on the holder of a patent to vigorously defend the assigned patent and its mercantability from outside unauthorized use during the lifespan of the assigned patent." To do less generally renders a patent impotent (the aspirin case is a good one to point to here -- Aspirin was an assigned patent and trademark of a firm; when others began using it with the knowledge of the trademark/patent holding firm who did nothing to "vigorously defend" these assignments, the term "aspirin" as well as its generic formula were placed in the pd). Why do I enter here (besides playing with law)? Brian {Hamilton Kelly} has re-written some of the code for the U*ix-compatible LZW code for VMS we distribute here via FILESERV (and will use with MFTU or VV*CODE to distribute backup savesets and other binaries via mail). While it still has a few other items I hope BHK will look to simplify the user interface command qualifier syntax, this appears to be a good system-independent COMPRESS<->LZW<->DECOMPRESS which has been tested across a few platforms. I trust it (or some variant thereof) will be used along with VV*CODE on the new TeXServer software. Once we get all of the interface issues out of the way, I will make it available here. No, I do not fear Unisys on this one; I'll personally pay to defend its public domain nature, if necessary, as the LZW algorithms have been published and discussed in a number of forums wherein far too many of its attributes have been disclosed -- my claim will be that we use a genericization based on these published attributes! (maybe it's really LZW-BHK we are going to distribute). Note, though, that I am also in favor of the LPF and its tenets -- LZW is, in my opinion, an exceptional case of non-defense on the part of the patent holder. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@Niord.SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "Nelson H.F. Beebe " Wed Jun 5 11:38:06 1991 Flags: 000000000001 Return-Path: Received: from solitude.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18721; Wed, 5 Jun 91 11:34:38 MDT Date: Wed, 5 Jun 91 11:34:38 MDT From: Nelson H.F. Beebe To: tex-archive@math.utah.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Subject: Identifying contents of file archives Message-Id: I've tried to make a habit in the tuglib archives on math.utah.edu of keeping a listing file for each .tar(.z), .arc, .zoo, et al file. That way, users can fetch a small file first to see whether they want the actual contents of the archive file. I've not however pulled README files out for separate retrieval; perhaps I should. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== From "karl@cs.umb.edu (Karl Berry)" Wed Jun 5 11:55:32 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18848; Wed, 5 Jun 91 11:49:08 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA11460; Wed, 5 Jun 91 13:48:34 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA14932; Wed, 5 Jun 91 13:48:27 EDT Date: Wed, 5 Jun 91 13:48:27 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9106051748.AA14932@ra.cs.umb.edu> To: bed_gdg@niord.shsu.edu, karl@cs.umb.edu Subject: RE: archives Cc: tex-archive@csc-sun.math.utah.edu I wouldn't want to depend on the good judgement of the courts for whether Unisys's patent is invalid. It would be better to use a compression scheme whose status is not in doubt. Probably you are right, and the patent is invalid. But if not, we would be in trouble. karl@cs.umb.edu From "George D. Greenwade " Wed Jun 5 18:57:07 1991 Flags: 000000000001 Return-Path: Received: from niord.shsu.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00391; Wed, 5 Jun 91 18:56:02 MDT Received: by Niord.SHSU.edu (MX V2.3) id 8201; Wed, 05 Jun 1991 16:01:02 CDT Date: Wed, 05 Jun 1991 16:01:02 CDT From: "George D. Greenwade" To: RFW@VAX01.AMS.COM Cc: info-tex@Niord.SHSU.edu, tex-archive@math.utah.edu Message-Id: <00949AD6.F870D4C0.8201@Niord.SHSU.edu> Subject: TeX and TUG News available from FILESERV Ron Whitney kindly passed along the files for the "TeX and TUG News" prototype issue and the TUGNEWS.STY file for installation on FILESERV. His provision (and a few of your requests that we make it available) enables us to offer it for your access. Don Hosek announced this availability at YMIR last week (and I thank him for that post). As usual, since this is a large transfer, our files are split for mailing purposes. The filename syntax we have installed was provided by TUG. George TeXTUGN ------- The TeXTUGN package includes the input files for the "TeX and TUG News" produced by the TeX Users Group (TUG). TeXTUGN is produced with the standard LaTeX distribution, and is to be as portable a document as possible. This is done on purpose, in order to facilitate electronic distribution of the source file. Presently, only the prototype issue (Vol. 0, No. 0, TeXTUGN.000) resides in this package. The prototype issue is distributed in four parts which need to be concatenated upon receipt. A special style file is used in producing the final output. To retrieve the 4 part distribution of the prototype TeXTUGN and the style file used, please include the commands: SENDME TeXTUGN.000* SENDME STY.TUGNEWS in the body of a mail message to FILESERV@SHSU.BITNET. Files in TeXTUGN package: (1 Block = 512 bytes) File Blocks ------------------------------------------------------------------------------- TeXTUGN.000_1OF4 56 TeXTUGN.000_2OF4 54 TeXTUGN.000_3OF4 44 TeXTUGN.000_4OF4 44 Approximate total blocks in full TeXTUGN.000 package = 198 From "George D. Greenwade " Thu Jun 6 09:00:58 1991 Flags: 000000000001 Return-Path: Received: from niord.shsu.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02979; Thu, 6 Jun 91 08:59:30 MDT Received: by Niord.SHSU.edu (MX V2.3) id 9197; Thu, 06 Jun 1991 09:58:36 CDT Date: Thu, 06 Jun 1991 09:58:36 CDT From: "George D. Greenwade" To: tex-archive@math.utah.edu Message-Id: <00949B6D.81681680.9197@Niord.SHSU.edu> Subject: LZW, zoo, other techniques Sorry to keep bludgeoning this horse, but I find this fascinating.... In (Wed, 5 Jun 91 13:04:33 MDT) "Nelson H.F. Beebe" states: > Also, there is a problem with the Lempel-Ziv compression algorithm used in > UNIX compress, as well as in arc, pkxxx (xxx = arc, pak, zip) and zoo. > UNISYS claims to hold a patent on the algorithm. Some archive sites have > already stopped using these programs for that reason. While UNISYS' claim > has not been upheld by a court as far as I know, their claim was > acknowledged by Adobe who licensed the technology from UNISYS for Adobe's > Level 2 PostScript implementation of the algorithm (see the 2nd edition of > the PostScript Reference Manual). As a for-profit user, Adobe probably paid a fee simply to preclude litigation if the questionable patent were pursued by Unisys. Since potential profits are involved with Adobe's use, this was probably a very smart move (and relatively small insurance premium). > Here is a summary of properties of existing utilities: > arc and pkxxx: no directory structure, restricted to PC DOS 8+3 file > name length limit, only upper-case letters in file names, > only file attribute supported are one time stamp per > file, several compression methods included > tar: directory structure, mixed letter case in file names, > file name path length limited to 100 chars, file > attributes include UNIX protection (user, group, > other), modification time stamp, and owner UIC, no > compression (that is left to separate utilities, in > the UNIX model of small is beautiful) > VAX VMS BACKUP: 8-level directory structure, one letter case in file > names, supports VAX VMS record attributes including > owner, protection, and time stamps, complex format > (although I know of one UNIX implementation of a > BACKUP file reader, available on math.utah.edu in > ~ftp/pub/misc/vmsbackup.tar.*), no compression > zoo: supports directory structure and file generations, > long file names (I cannot find a documented length > limit), mixed letter case in file names, uses ^^^^ > Lempel-Ziv compression, has utility (fiz) for ^^^^^^^^^^ > recovering data from damaged archive files > Public-domain or shareware implementations of all of these are available, > but zoo, tar, and arc are probably most easily accessible. zoo seems to > address more operating systems than the others, which were all designed for > single O/S environments. The lack of support for a directory structure in > arc and pkxxx is a very serious problem, which is a great nuisance for net > archive sites and for the distribution of complex systems that require a > directory tree. Then isn't zoo just as liable as any other use of the LZW algorithms? Even as shareware, if the author hadn't paid for the licensed use from Unisys, wouldn't everyone's copy of zoo be illegal (and hence removable from a site)? One other packing which is not mentioned (maybe this is totally platform dependent) is MFTU. MFTU is a translator of binaries to 80 column text for mail transfer (the sources are in Macro32 for VMS -- they are available with the author's permission from our FILESERV; the essentials of the copyright notice are appended following my signature). While that attribute of MFTU is a mail issue, MFTU also supports Huffman packing of files for archival purposes (and I have no idea what the source of "Huffman packing" is). The compression does not appear to be quite as efficient as LZW (appears to be about a 2% increase in size when MFTU PACKed as compared to LZCOMPed) and is relatively primitive (i.e., does not support time stamps, directory trees, owner, etc.), but does support multiple files in a PACKing and filenames can be of any length (a .PCK file is a fixed record 512 bytes/block file). Since I have only seen it on VMS, I assume it only supports VMS-consistent filenames. I have also found that a MFTU PACKed, MFTU ENCODEd file is nearly always smaller than the original executable from which it was built (and am experimenting with MFTUARCH as a VMS_SHARE-like distribution scheme -- supporting what is primarily a mail server presents a slightly different twist, unfortunately). Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@Niord.SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From: MFTU.MAR ; Copyright (C) 1987 Carlo Mekenkamp ; President Krugerstraat 42 ; 1975 EH IJmuiden ; Nederland ; MEKENKAM@HLERUL5.BITNET ; Rijks Universiteit Leiden ; Niels Bohrweg 1 ; Nederland ; With thanks to: ; Peter Laman ; for learning me how to use RMS I/O, and suggestions ; Todd Aven ; for suggestions which lead to the Huffman Scheme ; Tom Allebrandi ; for removing bug with FOP field ; This program comes without any warranty. ; The author does not accept any responsibility for any damage ; caused by use or mis-use of this program. ; This program is NOT in public domain. ; This program may be reproduced freely, but including ; this copyright notion. ; Purpose of this program: To encode VMS-files to ; text files of 80 characters a line, so they can be handled ; by mailers. And decoding it to the VMS-file again. ; It is immune for wrapped lines. ; Or to pack a program for archive purposes. ; Modifications of MFTU which alter the encoding scheme ; is not allowed for compatibility reasons. The encoding scheme ; has to be compatible for all versions. ; Modifications which speed up the program and don't alter the ; encoding scheme are allowed. ; For documentation on the encoding schemes used: ; See MFTU.DOC ; Any suggestions/improvements, please mail to ; mekenkam@hlerul5.bitnet. ; End of copyright note. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Known bugs: One ; When using UNPACK file.pck/LIST ; or /CONFIRM ; And there is a block in the packed file which start ; With the sequence 26,26,0,0 it is impossible to get a ; /LIST from what is in it. The chance this happens is ; 2^-32 <2.4E-10 per block. The reason is because when asking ; a /LIST, MFTU searches for blocks starting with that mark. ; When unpacking huffman decoding is used, so it won't fail. ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From "Don Hosek " Fri Jun 7 00:18:46 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10314; Fri, 7 Jun 91 00:18:43 MDT Date: Thu, 6 Jun 1991 23:18 PDT From: Don Hosek Subject: Re: archives To: beebe@math.utah.edu, tex-archive@science.utah.edu Message-Id: X-Envelope-To: beebe@math.utah.edu X-Vms-To: IN%"beebe@math.utah.edu" X-Vms-Cc: TEX_ARCHIVE -Wayne Sullivan suggests that we consider a TeX-specific -compression/archive system. -I believe that this would be unwise; there are already several -mostly-usable systems out there that are already in wide use. The -world doesn't need any more of them. Generally agreed by me. I might add that I have my reservations about vvencode since there is work being made to a net-standard ASCII encoding for binary files in the works already. (I can check with my contact for more information on this.) -Here is a summary of properties of existing utilities: -arc and pkxxx: no directory structure, restricted to PC DOS 8+3 file - name length limit, only upper-case letters in file names, - only file attribute supported are one time stamp per - file, several compression methods included The zip utilities that I've used support a /d qualifier for keeping directory structures. In fact, I seem to remember that the zip files distributed for emTeX use this feature. arc seems to be a dead/dying format which is only present in archives now because of the tremendous effort involved in converting to zip. Just thought I'd mention that. Incidentally, this discussion of archiving formats is all well and good, but I think that before we get too involved in the microscopic structure of the archive, we should think a bit about the overall organization. Furthermore, my experience is that the most commonly requested files fall into two categories: machine-specific programs (Drivers/TeX versions) and TeX input files. In the former case, who needs a system-independent archive format? In the latter case, these files are generally best left unarchived. -dh From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Fri Jun 7 01:19:36 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10429; Fri, 7 Jun 91 01:18:45 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA19448; Fri, 7 Jun 91 09:18:28 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA24047; Fri, 7 Jun 91 09:18:25 +0200 Date: Fri, 7 Jun 91 09:18:25 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9106070718.AA24047@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: beebe@math.utah.edu, tex-archive@science.utah.edu In-Reply-To: Don Hosek's message of Thu, 6 Jun 1991 23:18 PDT Subject: archives Don Hosek writes Generally agreed by me. I might add that I have my reservations about vvencode since there is work being made to a net-standard ASCII encoding for binary files in the works already. (I can check with my contact for more information on this.) But, Don, this is the general problem we've been facing several times already: either we do it now by ourselves or we wait for another few years. Being on a site in Europe where the character set confusion is much worse than in the U.S. (I might say there isn't any there) I favour the former. The zip utilities that I've used support a /d qualifier for keeping directory structures. In fact, I seem to remember that the zip files distributed for emTeX use this feature. arc seems to be a dead/dying format which is only present in archives now because of the tremendous effort involved in converting to zip. Just thought I'd mention that. I don't object to that. Only that zip is not yet spread widely enough outside the PC world. For example, I have an unzip on Unix, but not zip! Incidentally, this discussion of archiving formats is all well and good, but I think that before we get too involved in the microscopic structure of the archive, we should think a bit about the overall organization. Yes. Let's postpone this discussion until we've got the directory structure right. I'll post a proposal shortly. Rainer From "Don Hosek " Fri Jun 7 02:34:32 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10511; Fri, 7 Jun 91 02:33:52 MDT Date: Fri, 7 Jun 1991 01:33 PDT From: Don Hosek Subject: Re: archives To: schoepf@sc.ZIB-Berlin.DE, tex-archive@science.utah.edu Message-Id: X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: IN%"schoepf@sc.ZIB-Berlin.DE" X-Vms-Cc: TEX_ARCHIVE - Generally agreed by me. I might add that I have my reservations - about vvencode since there is work being made to a net-standard - ASCII encoding for binary files in the works already. (I can - check with my contact for more information on this.) -But, Don, this is the general problem we've been facing several times -already: either we do it now by ourselves or we wait for another few -years. Being on a site in Europe where the character set confusion is -much worse than in the U.S. (I might say there isn't any there) I -favour the former. Well, let me just say now that vvwhatever should be viewed as a temporary measure whilst we wait for the official coding scheme. Incidentally, as regards the character set confusion, I really hope that vvwhatever isn't being viewed as a way of handling issues like country A calls x'ac a-acute but country B calls it o-umlaut. Outside of that, the only character set confusion _I've_ encountered is of two types: - random mashings by gateways (the only major case of this that I see anymore is the Rutherford Janet-EARN gate which can be avoided by using nsfnet-relay to enter/leave Janet) There are occasional problems in ASCII-EBCDIC but these are generally the result of buggy hardware/software (e.g., the Yale terminal software treating \ as the EBCDIC cent sign) or user mischoice (e.g., using the wrong EBCDIC vertical bar or APL square brackets). - deletion of trailing spaces in uuencoded text. More a matter of choosing a proper uuencoder than anything else. This, I am certain was the problem with the uuencoded file Barbara mentioned a while back. I've seen it in other circumstances as well. -dh From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Fri Jun 7 02:45:59 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10538; Fri, 7 Jun 91 02:44:50 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA19581; Fri, 7 Jun 91 10:45:19 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA24227; Fri, 7 Jun 91 10:45:16 +0200 Date: Fri, 7 Jun 91 10:45:16 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9106070845.AA24227@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: schoepf@sc.ZIB-Berlin.DE, tex-archive@science.utah.edu In-Reply-To: Don Hosek's message of Fri, 7 Jun 1991 01:33 PDT Subject: archives Don Hosek writes: Incidentally, as regards the character set confusion, I really hope that vvwhatever isn't being viewed as a way of handling issues like country A calls x'ac a-acute but country B calls it o-umlaut. Outside of that, the only character set confusion _I've_ encountered is of two types: - random mashings by gateways (the only major case of this that I see anymore is the Rutherford Janet-EARN gate which can be avoided by using nsfnet-relay to enter/leave Janet) There are occasional problems in ASCII-EBCDIC but these are generally the result of buggy hardware/software (e.g., the Yale terminal software treating \ as the EBCDIC cent sign) or user mischoice (e.g., using the wrong EBCDIC vertical bar or APL square brackets). O sweet innocence! Obviously you're not living in Europe, are you? - deletion of trailing spaces in uuencoded text. More a matter of choosing a proper uuencoder than anything else. This, I am certain was the problem with the uuencoded file Barbara mentioned a while back. I've seen it in other circumstances as well. What is a proper uuencoder? Everyone claims his is!!! VV*code has (at least) two advantages: 1) Splitting/concatenating. I know that there are version of uu*code that do that, but every uses another scheme. Concatenating does not rely on the different parts being contained of files with specific names, or formats, or whatever. YOu copy just all mail messages to one filen in random order, with any amount of garbage in between, vvdecode will decode it properly. I spent already too much time with that particular problem. 2) File structure. Have you ever tried to uuencode a VMS .EXE file, mail it to somewhere, and reconstruct it there? Even more, vv*code allows you to do this across architectures, provided that both share the view of file structure. Even if not, you can force a certain file structure for the output file. That means that you *can* transfer a .tfm file from Unix to VMS using vv*code! Rainer From "Wayne G. Sullivan " Fri Jun 7 05:08:23 1991 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10885; Fri, 7 Jun 91 05:07:44 MDT Received: from IRLEARN.UCD.IE (MAILER@IRLEARN) by CC.UTAH.EDU with PMDF#10043; Fri, 7 Jun 1991 05:07 MST Received: by IRLEARN (Mailer R2.07) id 4542; Fri, 07 Jun 91 11:36:03 GMT Date: Fri, 07 Jun 91 10:24:46 GMT From: "Wayne G. Sullivan" Subject: archiving To: tex-archive@science.utah.edu Message-Id: <0E05A71BD000801C@CC.UTAH.EDU> X-Envelope-To: tex-archive@science.utah.edu There are three separate areas which have been rather confused in the discussion. (1) The repositories of TeX material. (2) 'Archive files' (3) File splitting and encoding for transmission. For (3): If VV coding does this properly, I hope it will become the single standard -- other existing techinques cause too many problems. If it were not for EBCDIC, perhaps this would not be so, but there are lots of people whose mailers work in EBCDIC. (Is the source WEB or C-WEB or just garble?) For (1): I greatly appreciate DH's ymir. It is my first choice when I need a file, but I have not tried them all. However, I believe the use of 'archive' files would benefit ymir and other repositories. Quite often MF source, TeX Macros or compiler source consist of a package of files. It would be a lot simpler to collect a single 'archive' file for the Levy Greek than all the separate sources. Last year I made virtual fonts containing exlpicit accent characters based on the cm fonts. This was placed in the Aston repository as a BOO encoded ZIP file -- it just did not make sense to have the numerous VF and TFM files kept separately. Of course this meant a lot of bother for anyone who wished to use these files on a different system. But we have no standard way of 'archiving' TeX related files, so each OS does its own thing which makes it difficult for everybody else (remember BNB's comment about the file she could not decode). For (2): I suggested an LZW type of algorithm for the sake of efficiency. I was unaware of copyright/patent problems. If in the near future one of the 'biggies' patents integer arithmetic, we are in real trouble. The logic of patenting 'trees' or cyclic buffers, which is about all that is needed for the algorithm, is beyond me. However, there is very good sense in avoiding lawsuits. There are a number of excellent OS specific archiving programs currently available, many using LZW type compression. If one of these is acceptable, then lets go for it. However, for general use with TeX it needs (1) to be public with published source, preferrably in WEB. (2) to be implementable on most systems. (3) to have facilities for converting file names and directory structures between systems. Though there are candidates for (1) and (2), I know of none which addresss (3). This is a real problem: the Sauter font sizing scheme is a great contribution, but the VAX version is useless for MSDOS without a lot of editing to satisfy system requirements concerning file names. WS From "Don Hosek " Fri Jun 7 09:20:53 1991 Flags: 000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11500; Fri, 7 Jun 91 09:19:06 MDT Date: Fri, 7 Jun 1991 08:18 PDT From: Don Hosek Subject: Re: archives To: schoepf@sc.ZIB-Berlin.DE, tex-archive@science.utah.edu Message-Id: <28AEAA04C66039CB@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: IN%"schoepf@sc.ZIB-Berlin.DE" X-Vms-Cc: TEX_ARCHIVE - Incidentally, as regards the character set confusion, I really - hope that vvwhatever isn't being viewed as a way of handling - issues like country A calls x'ac a-acute but country B calls it - o-umlaut. Outside of that, the only character set confusion - _I've_ encountered is of two types: - - random mashings by gateways (the only major case of this that - I see anymore is the Rutherford Janet-EARN gate which can be - avoided by using nsfnet-relay to enter/leave Janet) There are - occasional problems in ASCII-EBCDIC but these are generally - the result of buggy hardware/software (e.g., the Yale - terminal software treating \ as the EBCDIC cent sign) or user - mischoice (e.g., using the wrong EBCDIC vertical bar or APL - square brackets). -O sweet innocence! Obviously you're not living in Europe, are you? No, I'm not a European (but I play one on TV). I _do_ send and receive a great deal of mail between here and there and the only munger that I've encountered is the Janet-EARN gateway. Perhaps you could give some specifics of where Europeans run into these dastardly problems? - - deletion of trailing spaces in uuencoded text. More a matter - of choosing a proper uuencoder than anything else. This, I am - certain was the problem with the uuencoded file Barbara - mentioned a while back. I've seen it in other circumstances - as well. -What is a proper uuencoder? Everyone claims his is!!! Well if it ends a line with spaces, they're wrong. -VV*code has (at least) two advantages: -1) Splitting/concatenating. - I know that there are version of uu*code that do that, but every - uses another scheme. Concatenating does not rely on the different - parts being contained of files with specific names, or formats, or - whatever. YOu copy just all mail messages to one filen in random - order, with any amount of garbage in between, vvdecode will decode it - properly. I spent already too much time with that particular problem. A nice feature, true enough, but there is at least an uu/xxdecode which handles decoding files concatenated in order with mail headers etc. left intact. Every uuencoder I've seen will automatically split large archives. -2) File structure. - Have you ever tried to uuencode a VMS .EXE file, mail it to - somewhere, and reconstruct it there? Even more, vv*code allows you - to do this across architectures, provided that both share the view - of file structure. Even if not, you can force a certain file - structure for the output file. That means that you *can* transfer a - .tfm file from Unix to VMS using vv*code! Use a version of uudecode which is written in portable C and get garbage. Use a version of uudecode which understands RMS and you get F512 records (maybe). It is a deficiency. There is a need for these facilities right now. There is also a need for these facilities to be standardized across the net. The file structure issue is being taken up by the net standards group. Of course we've had xx*Code for quite some time now and the only time I see it is in occasional mail from colleagues in the UK. atob has been slightly more common and uu*code is still dominant. It would take a net-wide standard to dethrone uu*code so vv*code, nice as it is should be viewed as provisionary (so who's going to modify listserv to create vv*coded files?). -dh From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Fri Jun 7 09:30:36 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11538; Fri, 7 Jun 91 09:28:53 MDT Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA20332; Fri, 7 Jun 91 17:28:55 +0200 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA24985; Fri, 7 Jun 91 17:28:52 +0200 Date: Fri, 7 Jun 91 17:28:52 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9106071528.AA24985@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: schoepf@sc.ZIB-Berlin.DE, tex-archive@science.utah.edu In-Reply-To: Don Hosek's message of Fri, 7 Jun 1991 08:18 PDT <28AEAA04C66039CB@HMCVAX.CLAREMONT.EDU> Subject: archives Don writes: No, I'm not a European (but I play one on TV). I _do_ send and receive a great deal of mail between here and there and the only munger that I've encountered is the Janet-EARN gateway. Perhaps you could give some specifics of where Europeans run into these dastardly problems? Simple. In every European country there is another flavor of EBCDIC. Send a TeX file from an IBM in Germany to an IBM in France --- Surprise! That's IBM's view of national character sets; I suspect the only thing they did is to change the key caps and character display in their terminals. Not bad, but disastrous when you connect these machines. Actually that is also the reason for the problems at EARN-RELAY: it is using a british character set. Rainer From "bbeeton " Fri Jun 7 16:03:59 1991 Flags: 000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14031; Fri, 7 Jun 91 16:02:38 MDT Date: Fri 7 Jun 91 18:02:41-EST From: bbeeton Subject: archives and character set pollution To: tex-archive@csc-sun.math.utah.edu Message-Id: <676332161.0.BNB@MATH.AMS.COM> Mail-System-Version: i'm not european, but i'm subscribed to a number of mailing lists with heavy european participation. because i really try to understand what i'm reading (i'm not really fluent in all those languages), and besides, the most susceptible areas are the special characters (like backslash and braces, which are rather essential to tex), i find it helps to keep track of what i've encountered in case it happens again. which it usually does. so, boys and girls, i attach for your edification my file of common and uncommon pollutants. i do detect ebcdic intervention in most of them, but the trash is neither consistent nor (by me) predictable. as rainer suggests, i too suspect keycap variations. and if we start using 8-bit input for tex, things are only going to get much worse before they get better. i vote for a coding technique that is known to be reliable for files to be used with the tex system, whether ascii or binary. we're not trying to solve the problem for the whole net, just for the tex users on it. -- bb -------------------- 0CHARS.NOTES The file 0CHARS.FIL contains a list of all the printing ASCII characters in a form intended to be included in a network mail message to test the reliability of file transmission through network gateways. Below are annotated extracts from 0CHARS.FIL showing actual results of network file transfers in which particular characters were lost or trashed. Note that the selection of lost characters is unpredictable; >From the same sender, two transmissions may have different results. Control characters, which sometimes replace printing characters in net transmissions, are shown here using the ^x or other scrutable notation. >From Klaus Guntermann, Bitnet, summer 86: %| exclamation point ! %%%%%%%%%% % left square bracket [ %%%%%%%%%% %! right square bracket ] %%%%%%%%%% % vertical bar | %%%%%%%%%% >From Klaus Guntermann, Bitnet, Sep 87 %c tilde ~ %%%%%%%%%% >From Adrian Clark, Bitnet, Jun 87 occasional occurrences in transmissions from the U.K. %^H caret (circumflex) ^ %%%%%%%%%% %$ left curly brace { %%%%%%%%%% %^G right curly brace } %%%%%%%%%% %^ tilde ~ %%%%%%%%%% >From Piet van Oostrum via TEX-NL, Bitnet (HEARN), Mar 90 fairly common in transmissions from UKTeX and GUT %$ left curly brace { %%%%%%%%%% %^G right curly brace } %%%%%%%%%% >From Hohti & Kanerva, article on APL font, Summer 87 %^N left square bracket [ %%%%%%%%%% %^Y left slash (backslash) \ %%%%%%%%%% %^O right square bracket ] %%%%%%%%%% %^D left curly brace { %%%%%%%%%% %^T vertical bar | %%%%%%%%%% %^F right curly brace } %%%%%%%%%% >From Hubert Partl, in GERMAN.STY, Jan 88 %~ caret (circumflex) ^ %%%%%%%%%% %c tilde ~ %%%%%%%%%% %^_ vertical bar | %%%%%%%%%% >From an MR reviewer at McGill, Bitnet, Apr 88 also from a Taiwan address via Bitnet to TeXhax, Aug 89 fairly common in transmissions from UKTeX and GUT % backslash \ %%%%%%%%%% >From TeXMag sent via Peter Abbot at Aston, Bitnet, Jun 88 %~ caret (circumflex) ^ %%%%%%%%%% %% tilde ~ %%%%%%%%%% >From P. Wackers via TeX-NL, Jul 90 %: left square bracket [ %%%%%%%%%% % right square bracket ] %%%%%%%%%% >From TEX-D-L transmissions, Apr 90 -- note, 8-bit code > 128 >From Alan Hoenig at CUNYVM, Jun 90 %\233 backslash \ %%%%%%%%%% >From Erich Neuwirth, Aug 89 -- note, 8-bit code > 128 %\233 backslash \ %%%%%%%%%% %\272 vertical bar | %%%%%%%%%% >From Chris Rowley via LATEX-L, May 90 -- note, 8-bit codes > 128 %\207 right curly brace } %%%%%%%%%% %\210 caret (circumflex) ^ %%%%%%%%%% %\244 left curly brace { %%%%%%%%%% >From Sebastian Rahtz via LATEX-L, July 90 -- note, 8-bit codes > 128 %% caret (circumflex) ^ %%%%%%%%%% %^ tilde ~ %%%%%%%%%% %\207 right curly brace } %%%%%%%%%% %\244 left curly brace { %%%%%%%%%% >From Frank Mittelbach via LATEX-L, May 90 -- note, 8-bit codes > 128 %\233 left square bracket [ %%%%%%%%%% %\272 right square bracket ] %%%%%%%%%% >From Helge Steenweg via TEX-EURO mailing, Sep 90 -- note 8-bit codes > 128 %| right square bracket ] %%%%%%%%%% %\233 left square bracket [ %%%%%%%%%% >From Jas Radomski via PLEARN-L mailing, Oct 90 -- note 8-bit codes > 128 %! right square bracket ] %%%%%%%%%% %\233 left square bracket [ %%%%%%%%%% >From Matthias Pfuetzner via INFO-TeX mailing, Mar 91 -- note 8-bit codes > 128 %\374 vertical bar | %%%%%%%%%% >From SUEARN-L posting, originally from CompuServe, Mar 91 -- note 8-bit codes > 128 %\272 colon : %%%%%%%%%% >From Orhan Gokcol via YUNUS posting, May 91 -- note 8-bit codes > 128 %\253 left curly brace { %%%%%%%%%% %\267 right curly brace } %%%%%%%%%% %\365 backslash \ %%%%%%%%%% %\371 at-sign @ %%%%%%%%%% [11 Jun 88, bb; last update 28 May 91] ------- From CGL@RUG.NL Sat Jun 8 10:36:46 1991 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19712; Sat, 8 Jun 91 10:36:11 MDT Received: from HEARN.BITNET (MAILER@HEARN) by CC.UTAH.EDU with PMDF#10043; Sat, 8 Jun 1991 10:36 MST Received: from RUG.NL (CGL) by HEARN.BITNET (Mailer R2.07) with BSMTP id 0829; Sat, 08 Jun 91 18:34:50 MET Date: Sat, 8 Jun 1991 18:04 MET From: CGL@RUG.NL Subject: Request for survey on the issue To: tex-archive@science.utah.edu Message-Id: <43B98A5F0020035A@RUG.NL> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: IN%"tex-archive@science.utah.edu" X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender. From: RUGR86::CGL 8-JUN-1991 17:52:58.01 To: IN%"schoepf@sc.ZIB-Berlin.DE" CC: CGL Subj: RE: archives Dear Rainer, Don, and other speakers I find it quite interesting this discussion but can't understand it completely because of lack of experience. What I would like to see is some compilation of the discussion, and I would be happy to include that in NTG's MAPS because I consider your experience worthy for our members. Is somebody willing to do this? ---Kees--- From "karl@cs.umb.edu (Karl Berry)" Mon Jun 10 07:34:58 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28067; Mon, 10 Jun 91 07:34:05 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA23825; Mon, 10 Jun 91 09:33:54 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA15760; Mon, 10 Jun 91 09:33:21 EDT Date: Mon, 10 Jun 91 09:33:21 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9106101333.AA15760@ra.cs.umb.edu> To: tex-archive@math.utah.edu, info-tex@shsu.BITNET, texhax@cs.washington.edu Subject: updated version of MLTeX Reply-To: karl@cs.umb.edu I've received a minor fix for one of the TeX files in the MLTeX distribution from Michael Ferguson. (MLTeX adds the \charsubdef primitive to TeX, for use in non-English languages.) You can get the complete distribution from ftp.cs.umb.edu [192.12.26.23]:pub/tex/charsubdef.tar.Z karl@cs.umb.edu From "JANET TEX@UK.AC.CRANFIELD.RMCS " Mon Jun 10 12:51:07 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29643; Mon, 10 Jun 91 12:50:12 MDT Received: from rmcs.cranfield.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <9446-0@sun2.nsfnet-relay.ac.uk>; Mon, 10 Jun 1991 17:54:16 +0100 Date: Mon, 10 JUN 91 17:57:26 BST From: TEX@rmcs.cranfield.ac.uk To: TEX-ARCHIVE <@nsfnet-relay.ac.uk:TEX-ARCHIVE@SCIENCE.UTAH.edu> Subject: RE: (1073) Re: archives Actually-To: Sender: JANET "TEX@UK.AC.CRANFIELD.RMCS" Message-Id: <000000A7_0051B810.00949ED50C9E4A20$12_4@UK.AC.CRANFIELD.RMCS> Reply-To: Brian {Hamilton Kelly} Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.CLAREMONT.HMCVAX::DHOSEK,CBS%UK.AC.TEX::ARCHIVE-GROUP Originally-From: TEX "Brian {Hamilton Kelly} " Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) In message of Thu, 6 Jun 1991 23:18 PDT, Don Hosek wrote (I'm not sure whom he is quoting here: I can't recall seeing these words before on the Uath tex-archive list): > -Wayne Sullivan suggests that we consider a TeX-specific > -compression/archive system. > > -I believe that this would be unwise; there are already several > -mostly-usable systems out there that are already in wide use. The > -world doesn't need any more of them. > > Generally agreed by me. I might add that I have my reservations > about vvencode since there is work being made to a net-standard > ASCII encoding for binary files in the works already. (I can > check with my contact for more information on this.) Yes please, Niel and I would very much like to hear what is being done in the net-standardization world. Perhaps we should submit VVcode as an RFC? Just one teaser for you; at Aston, due to various circumstances, binary files (apart from VMS specific F512 ones) _have_ to be archived as variable length records, for NIFTP. (This includes tfm, vf and pk files.) Which _platform-independent_ uu/xx schemes support the encoding of such files such that the structure can be recovered on the receiving node (when that requires structure)? Moreover, the archive contains a few VMS Backup save sets: which uu/xx scheme records and reconstructs the 32256-byte fixed blocks of these? > Incidentally, this discussion of archiving formats is all well > and good, but I think that before we get too involved in the > microscopic structure of the archive, we should think a bit about > the overall organization. Furthermore, my experience is that the > most commonly requested files fall into two categories: > machine-specific programs (Drivers/TeX versions) and TeX input > files. In the former case, who needs a system-independent archive > format? In the latter case, these files are generally best left > unarchived. I tend to agree; however, it's a great service to users of an archive to provide facilities that permit them to have a selection of files packed up into one, encoded, file for transmission to them, such that it may be decomposed by them into a suitable directory structure. I believe the only one that works across more than a couple of platforms is ZOO, which moreover has the advantage over ZIP of being in the PD, with published sources. Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: {mcsun,ukc,uunet}!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From "George D. Greenwade " Sat Jun 15 17:28:43 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03990; Sat, 15 Jun 91 17:27:54 MDT Received: by SHSU.BITNET (MX V2.3-1) id 20515; Sat, 15 Jun 1991 18:03:07 CDT Date: Sat, 15 Jun 1991 18:03:07 CDT From: "George D. Greenwade" To: info-tex@SHSU.BITNET, TeX-archive@math.utah.edu Cc: UKTeX@TeX.ac.uk, TeXhax@cs.washington.edu Message-Id: <0094A2C3.AE2108A0.20515@SHSU.BITNET> Subject: SFPtoPK, PKtoSFP, and MergeSFP available on FILESERV I am pleased to announce that Norm Walsh has made his SFPtoPK, PKtoSFP, and MergeSFP programs for Hewlett-Packard softfonts available to the public on FILESERV. Below is the resulting description file from a DIRECTORY SPFONTWARE message mailed to FILESERV@SHSU.BITNET (or @Niord.SHSU.edu). These files are also available for anonymous ftp from Niord.SHSU.edu [192.92.115.8] in the directory [.SPFONTWARE]. I extend my personal thanks to Norm for selecting us as the first site to host these files and hope to see them on other archive sites as they are retrieved and used. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@Niord.SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% SPFONTWARE ---------- The SPFONTWARE package includes three UUENCODEd ZIP files for Norm Walsh's utilities to convert Hewlett-Packard softfonts to *and* from TeX PK/TFM format (as of June 12, 1991). All of these files are for MS-DOS platforms. The file SPFONTWARE.SPFtoPK_ZIP converts HP LaserJet softfont files into TeX fonts. Features of SPFtoPK in brief: - Converts softfonts directly into PK files (allowing up to 256 chars/font) - Option to move characters from anywhere in the softfont to standard TeX positions (this is especially useful for ligatures and accents). - Option to automatically build ligatures into the TeX font - Supports a flexible kerning algorithm - Options for ``stealing'' accents off of accented characters -- even baseline accents like the cydil. - Similar option for stripping accents *off* of characters -- useful to produce the undotted i's and j's if nothing else. - Can dynamically adjust the size of an interword space - Can dynamically adjust the x-height - Can calculate the appropriate slant value for most fonts - Handles compressed (PCL4/5) softfont files - Complete documentation provided in a DVI file The file SPFONTWARE.PKtoSFP_ZIP converts TeX fonts into LaserJet softfont files. Features of PKtoSFP in brief: - Converts directly from PK files (allowing up to 256 characters/font) - Automatically handles the \L slash character at position '040 in the TeX font (so your softfont doesn't have a non-blank space) - Complete documentation provided in a DVI file The file SPFONTWARE.MergeSFP_ZIP combines multiple HP softfont files into a single softfont. Features of MergeSFP in brief: - Many options for defining the output softfont - Handles compressed (PCL4/5) softfonts - Complete documentation provided in a DVI file To retrieve the entire set of three files, please include the command SENDME SPFONTWARE in the body of a mail message to FILESERV@SHSU.BITNET. To retrieve a specific file from this distribution, such as SPFONTWARE.MergeSFP, include the command: SENDME SPFONTWARE.MergeSFP in the body of the mail message to FILESERV. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- SPFONTWARE.MergeSFP_ZIP 104 MergeSFP.ZIP SPFONTWARE.PKtoSFP_ZIP 117 PKtoSFP.ZIP SPFONTWARE.SFPtoPK_ZIP 210 SFPtoPK.ZIP Approximate total blocks in full SPFONTWARE package = 431 Archive maintainers have Norm's permission (and encouragement) to make these programs available on ftp file servers and other file distribution networks (mail-server archives, BBS systems, etc). The only limitations that he wishes to impose are that you may not profit from their distribution and you may not re-organize the archives that he has constructed (don't add or remove any files from the archives)--let your conscience be your guide. From "George D. Greenwade " Tue Jun 18 14:26:13 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11578; Tue, 18 Jun 91 14:22:24 MDT Received: by SHSU.BITNET (MX V2.3-1) id 23365; Tue, 18 Jun 1991 14:04:26 CDT Date: Tue, 18 Jun 1991 14:04:26 CDT From: "George D. Greenwade" To: info-tex@SHSU.BITNET, tex-archive@math.utah.edu Cc: bed_gdg@SHSU.BITNET Message-Id: <0094A4FD.D9AC3580.23365@SHSU.BITNET> Subject: PKtoSFP update Just received a note from Norman Walsh about PKtoSFP which needs to be passed along: ------------------------------update message----------------------------- Hello World, I'm afraid that a bug has been found in PKtoSFP. By the time that you read this, a new version will be available from FILESERV@SHSU. Please get the new version! The new version is version 1.2. The old version (ver 1.1) will chop the descenders off of some fonts. I appologize for not catching this one before it went out the door. If anyone would like more info about the exact nature of the problem, just drop me a note and I'll be happy to explain. Regards, norm P.S. This update effects PKtoSFP *only*. The versions of SFPtoPK and MergeSFP have not been updated. -------------------------------------------------------------------------- If you have already retrieved the PKtoSFP file from FILESERV and would like the new version, please include the command: SENDME SPFONTWARE.PKtoSFP_ZIP in the body of a mail message to FILESERV@SHSU.BITNET and only that file will be sent. If you want the entire set of three files, the FILESERV command SENDME SPFONTWARE will get the new version of PKtoSFP, as well as the existing versions of MergeSFP and SFPtoPK. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@Niord.SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "karl@cs.umb.edu (Karl Berry)" Tue Jun 18 15:40:07 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11894; Tue, 18 Jun 91 15:36:59 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA24275; Tue, 18 Jun 91 17:35:39 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA29537; Tue, 18 Jun 91 17:35:26 EDT Date: Tue, 18 Jun 91 17:35:26 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9106182135.AA29537@ra.cs.umb.edu> To: tex-archive@math.utah.edu, info-tex@shsu.BITNET Subject: ushyphen.max Reply-To: karl@cs.umb.edu I've put G. Kuiken's English hyphenation patterns (a superset of hyphen.tex, as I understand it) on ftp.cs.umb.edu [192.12.26.23]:pub/tex/ushyphen.*. You will need an extended hyphenation trie to use ushyphen.max, which finds ``all admissible hyphens in TUGboat's ``Exception Log''. You can use the standard hyphenation trie with the file ushyphen.add, which doesn't find all admissible hyphens, but it finds more than hyphen.tex does. karl@cs.umb.edu From "George D. Greenwade " Mon Jun 24 14:39:04 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06759; Mon, 24 Jun 91 14:36:51 MDT Received: by SHSU.edu (MX V2.3-1) id 30804; Mon, 24 Jun 1991 15:15:11 CDT Date: Mon, 24 Jun 1991 15:15:11 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094A9BE.B6D26820.30804@SHSU.edu> Subject: LONGTABLE.STY, LONGTABLE.TEX updates available at FILESERV David Carlisle posted a note to me regarding his longtable.sty and longtable.tex files which we have placed on FILESERV. There were some problems with this LaTeX style under the Mittelbach & Shoepf New Font Selection Scheme, which David has addressed, along with a few other problems, as well. From longtable.sty: % Improvements in Version 2 17/6/91 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % * Works with the New Font Selection Scheme. % * Works with Mittelbach's array.sty. % * Improved the \caption command. % Now accepts multi-line captions, like article.sty's table enviromnent. % Also has a \caption* form which does not print the table counter. % * Added the \endfoot command, so that row(s), (or just an \hline) may be % added to the bottom of each page of the table. % * Lots more comments in the code! And, I would add, a marvelous set of examples and covered areas in the manual! To retrieve both of these files, please include the command: SENDME STY.LONGTABLE* in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). Individually, the files are: STY.LONGTABLE and STY.LONGTABLE_TEX (include either in the SENDME command if you really only want one, but not the other; can't imagine why, but...). For anonymous ftp from Niord.SHSU.edu, these are in the directory [FILESERV.STY]. Regards and thanks are extended to David, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "mackay@manta.cs.washington.edu (Pierre MacKay)" Wed Jun 26 18:02:24 1991 Flags: 000000000001 Received: from manta.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21276; Wed, 26 Jun 91 17:59:09 MDT Received: by manta.cs.washington.edu (5.64/7.0a) id AA05262; Wed, 26 Jun 91 17:00:16 -0700 Date: Wed, 26 Jun 91 17:00:16 -0700 From: mackay@manta.cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9106270000.AA05262@manta.cs.washington.edu> To: BNB@MATH.AMS.COM Cc: karl@cs.umb.edu, schoepf@sc.ZIB-Berlin.DE, tex-archive@csc-sun.math.utah.edu In-Reply-To: bbeeton's message of Sun 2 Jun 91 16:24:51-EST <675894291.0.BNB@MATH.AMS.COM> Subject: getting archives to conform to each other >>>README files: Elizabeth and I will get to work on making the UnixTeX README files clearly identifiable and distinguishable. >>>Archive directory names such as mf, mfware, etc. This had better be thought through, as Barbara suggests. We, for instance use them very specifically in the makefile hierarchy, and there will be a lot of blood and sweat if they have to be changed. I think the problem may be in these names being used for purposes for which they were not intended. In our usage, mfware is exclusively for source for mfware utility programs in the official archive set. No other contributions, however valuable, belong there. The name mf is less defensible, perhaps, because it is regularly used as a root directory above ./lib/ from which the branches ./lib/mf/inputs etc., develop. On the other hand, in the base level of the UnixTeX file system it is exclusively for compilation source, change files etc. Rick Furuta and I developed the directory hierarchy rather ad-hoc, and after Rick left, I did things like separating out DVIware, which used to be in TeX-contrib. The present divisions are a compromise to make labrea and UnixTeX and Web2C look as much alike as possible. There are some quite deliberate Unixisms, in UnixTeX directories and I would prefer to keep them. For example---the case of the first letter in both directory and filenames is not arbitrary. All the lowercase directories are for compilation only, and the uppercase are for auxiliary files. I guess the general point I must make is that the trees developed in the Unix environment were not developed consciously, and certainly not principally for archival convenience. Changing them will either break down the relationship between UnixTeX and Unix based archives, a relationship which we have been trying to make closer, or will unhinge a lot of the work that has been done to smooth the compilation tasks in reliable Unix systems. I really have been able, in a familiar Sun or DEC environment, to type make at 6:30 P.M and go home, with the confidence that all the 20+ programs in the official package will be complete and waiting for me next morning. Maybe we have to give up the relation between the compilation directory structures (for which Unix directory trees seem entirely natural) and the archive directory structures, which need to make life easier for the non-Unix environment. But let's not rush into it, and if the two patterns diverge, they had probably better diverge very sharply, so as to eliminate the residual belief that the archive and the distribution reflect one another. From "George D. Greenwade " Thu Jun 27 13:42:45 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26287; Thu, 27 Jun 91 13:38:37 MDT Received: by SHSU.edu (MX V2.3-1) id 6780; Thu, 27 Jun 1991 14:12:07 CDT Date: Thu, 27 Jun 1991 14:12:07 CDT From: "George D. Greenwade" To: TeX@rmcs.cranfield.ac.uk Cc: tex-archive@math.utah.edu Message-Id: <0094AC11.6D9FFC80.6780@SHSU.edu> Subject: Internet draft on multi-part encoding of files On Mon, 10 JUN 91 17:57:26 BST, Brian {Hamilton Kelly} posted: > In message of Thu, 6 Jun 1991 > 23:18 PDT, Don Hosek wrote > (I'm not sure whom he is quoting here: I can't recall seeing these words > before on the Uath tex-archive list): >> -Wayne Sullivan suggests that we consider a TeX-specific >> -compression/archive system. >> >> -I believe that this would be unwise; there are already several >> -mostly-usable systems out there that are already in wide use. The >> -world doesn't need any more of them. >> >> Generally agreed by me. I might add that I have my reservations >> about vvencode since there is work being made to a net-standard >> ASCII encoding for binary files in the works already. (I can >> check with my contact for more information on this.) > Yes please, Niel and I would very much like to hear what is being done in > the net-standardization world. Perhaps we should submit VVcode as an RFC? I have a copy of the Internet draft "Mechanisms for Specifying and Describing the Format of Internet Message Bodies" by Nathaniel Borenstein, Bellcore and Ned Freed, Innosoft available on D-VLSERV@SHSU.BITNET (D-VLSERV@SHSU.edu) if anyone is interested. It has been submitted to the RFC editor as a protocol specification for multi-part textual and non-textual messages. This is associated with the development of a VMS-based implementation of Eric Thomas' LISTSERV (D-VMSLSV; a project which we are sort of involved with). If you want a copy, include the command SENDME DRAFT.BODY* in the body of a mail message to D-VLSERV. This is *not* ftp'able from SHSU. >From reading it and looking at the beta version of VVCODE, the two are not far apart (apart, yes; far apart, no). Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "Eberhard Mattes " Wed Jul 3 05:11:08 1991 Flags: 000000000001 Return-Path: Received: from ifi.informatik.uni-stuttgart.de by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14201; Wed, 3 Jul 91 05:07:24 MDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Wed, 3 Jul 91 13:06:03 +0200 From: Eberhard Mattes Date: Wed, 3 Jul 91 13:07:17 +0200 Message-Id: <9107031107.AA06463@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Wed, 3 Jul 91 13:07:17 +0200 To: tex-archive@science.utah.edu Subject: emTeX: English dvidrv manual now available Thanks to Chris Martin an English translation of the dvidrv 1.4d manual is now available. The DVIDRVMA package now contains both the German and the English manual. Changed files of the emTeX distribution: disk1/readme.eng disk1/readme.ger disk1/changes.eng disk1/changes.ger disk5/dvidrvma.zip Moved files: disk3/dvidrvma.zip --> disk6/dvidrvma.zip disk6/texcad.zip --> disk3/texcad.zip (contents unchanged) The files are available for anonymous ftp from rusmv1.rus.uni-stuttgart.de [129.69.1.12] in the directory soft/tex/machines/pc/emtex Let's hope the other ftp sites holding emTeX will get updated soon. Eberhard Mattes From "Eberhard Mattes " Wed Jul 3 05:11:08 1991 Flags: 000000000001 Return-Path: Received: from ifi.informatik.uni-stuttgart.de by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14201; Wed, 3 Jul 91 05:07:24 MDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Wed, 3 Jul 91 13:06:03 +0200 From: Eberhard Mattes Date: Wed, 3 Jul 91 13:07:17 +0200 Message-Id: <9107031107.AA06463@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Wed, 3 Jul 91 13:07:17 +0200 To: tex-archive@science.utah.edu Subject: emTeX: English dvidrv manual now available Thanks to Chris Martin an English translation of the dvidrv 1.4d manual is now available. The DVIDRVMA package now contains both the German and the English manual. Changed files of the emTeX distribution: disk1/readme.eng disk1/readme.ger disk1/changes.eng disk1/changes.ger disk5/dvidrvma.zip Moved files: disk3/dvidrvma.zip --> disk6/dvidrvma.zip disk6/texcad.zip --> disk3/texcad.zip (contents unchanged) The files are available for anonymous ftp from rusmv1.rus.uni-stuttgart.de [129.69.1.12] in the directory soft/tex/machines/pc/emtex Let's hope the other ftp sites holding emTeX will get updated soon. Eberhard Mattes From "Ralph Youngen " Wed Jul 3 07:49:25 1991 Flags: 000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14458; Wed, 3 Jul 91 07:46:12 MDT Date: Wed 3 Jul 91 09:46:35-EST From: Ralph Youngen Subject: new versions of AMS-TeX, AMS-LaTeX, and AMSFonts To: tex-archive@math.utah.edu, info-tex@shsu.bitnet, texhax@cs.washington.edu, UKTeX%uk.ac.tex@nsfnet-relay.ac.uk, tex-euro@dhdurz1.bitnet Cc: REY@MATH.AMS.COM Message-Id: <678548795.0.REY@MATH.AMS.COM> Mail-System-Version: I am pleased to announce the release of new versions of the three major AMS-supported TeX products. AMS-TeX 2.1, AMSFonts 2.1, and AMS-LaTeX 1.1 have all been posted to our TeX archive on the Internet node e-MATH.ams.com (130.44.1.100), and are now available for immediate retrieval by anonymous FTP. Also available is information (both guidelines and documentstyle files) for authors who may wish to submit something to the AMS in electronic form for publication. This is the first major upgrade to the files on the AMS's e-MATH archive since its inception over a year ago. Announcements of future incremental or major upgrades to any of these products will be posted to the normal TeX discussion lists. The files in this release have also been changed to incorporate a file identification block in the form of a BibTeX-like entry at the start of each TeX or Metafont file. This was a suggestion Nelson Beebe posted to the tex-archive list about a year ago. The AMS staff worked with Nelson over the past several months and settled on the scheme found in these files. We do not necessarily feel that the structure we've chosen is final, and would like to hear comments and/or suggestions for improvements. As in the past, we are suggesting that those of you responsible for maintaining a TeX archive copy the entire /ams tree from e-MATH and set up a corresponding /ams tree on your own archive. Some of the READ.ME files refer to files in other directories using the notation "/ams/...". (We realize that you may not want to copy all of the resolutions of the AMSFonts PK files to your area because of space considerations.) We wish for these files to replace all previous releases of AMS-TeX, AMS-LaTeX, and AMSFonts for as many users as possible. We are especially concerned about the dissemination of AMSFonts 2.1, but strongly encourage users to upgrade AMS-TeX and AMS-LaTeX as well. Details follow. AMSFonts 2.1 (/ams/amsfonts/... and /ams/tfm-files): ==================================================== Sometime after AMSFonts 2.0 was released, it was brought to our attention that there was a bug in the Metafont code for the AMS extra symbol fonts (MSAM and MSBM) that caused different TFM files to be produced when these fonts were run at different resolutions. This has been fixed in 2.1. Another significant enhancement in the MSBM font is much improved character rendering for the Blackboard Bold characters at low resolutions. (Thanks to Stefan Lindner for the Metafont help with the Blackboard Bold characters.) Additionally, through several communications with Knuth we are pleased to release improved versions of the Euler and extra CM fonts. All of the Euler bold fonts have been made more bold and extended. In previous versions of Euler, it was very difficult to distinguish the bold from the non-bold versions of these fonts. Knuth also reviewed the parameter listings for the additional point sizes of the CM fonts that we created and we have incorporated his suggestions into this release. Another change with AMSFonts 2.1 is that we are now distributing more resolutions of PK files. Previously, e-MATH contained only 118 and 300 dpi fonts. We have now posted 118, 180, 240, 300, and 400 dpi fonts to the /ams/amsfonts/pk-files/... area of e-MATH. As before, Metafont sources for all of the AMSFonts are also available. AMS-TeX 2.1 (/ams/amstex): ========================== This is mainly a bug-fix version, with some minor enhancements. A new file, amsppt1.tex, has been added to provide backward compatibility with documents written under amsppt.sty version 1 but run with AMS-TeX 2.0 or later. AMS-LaTeX 1.1 (/ams/amslatex): ============================== Again, this is mainly a bug-fix version with some enhancements. In an effort to keep this area current we are now distributing the complete Mittelbach/Schoepf font selection scheme in the /ams/amslatex/fontsel area. When new versions of these files become available, we will attempt to quickly verify their compatibility with AMS-LaTeX and post them to e-MATH. Please direct any problems or questions concerning the TeX archive on e-MATH to: Technical Support Group American Mathematical Society 201 Charles Street P.O. Box 6248 Providence, RI 02940 USA (800) 321-4AMS (321-4267) ext. 4080 (401) 455-4080 Internet: tech-support@math.ams.com Thank you. Ralph Youngen Supervisor, Technical Support American Mathematical Society Internet: REY@MATH.AMS.COM ------- From "Ralph Youngen " Wed Jul 3 07:49:25 1991 Flags: 000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14458; Wed, 3 Jul 91 07:46:12 MDT Date: Wed 3 Jul 91 09:46:35-EST From: Ralph Youngen Subject: new versions of AMS-TeX, AMS-LaTeX, and AMSFonts To: tex-archive@math.utah.edu, info-tex@shsu.bitnet, texhax@cs.washington.edu, UKTeX%uk.ac.tex@nsfnet-relay.ac.uk, tex-euro@dhdurz1.bitnet Cc: REY@MATH.AMS.COM Message-Id: <678548795.0.REY@MATH.AMS.COM> Mail-System-Version: I am pleased to announce the release of new versions of the three major AMS-supported TeX products. AMS-TeX 2.1, AMSFonts 2.1, and AMS-LaTeX 1.1 have all been posted to our TeX archive on the Internet node e-MATH.ams.com (130.44.1.100), and are now available for immediate retrieval by anonymous FTP. Also available is information (both guidelines and documentstyle files) for authors who may wish to submit something to the AMS in electronic form for publication. This is the first major upgrade to the files on the AMS's e-MATH archive since its inception over a year ago. Announcements of future incremental or major upgrades to any of these products will be posted to the normal TeX discussion lists. The files in this release have also been changed to incorporate a file identification block in the form of a BibTeX-like entry at the start of each TeX or Metafont file. This was a suggestion Nelson Beebe posted to the tex-archive list about a year ago. The AMS staff worked with Nelson over the past several months and settled on the scheme found in these files. We do not necessarily feel that the structure we've chosen is final, and would like to hear comments and/or suggestions for improvements. As in the past, we are suggesting that those of you responsible for maintaining a TeX archive copy the entire /ams tree from e-MATH and set up a corresponding /ams tree on your own archive. Some of the READ.ME files refer to files in other directories using the notation "/ams/...". (We realize that you may not want to copy all of the resolutions of the AMSFonts PK files to your area because of space considerations.) We wish for these files to replace all previous releases of AMS-TeX, AMS-LaTeX, and AMSFonts for as many users as possible. We are especially concerned about the dissemination of AMSFonts 2.1, but strongly encourage users to upgrade AMS-TeX and AMS-LaTeX as well. Details follow. AMSFonts 2.1 (/ams/amsfonts/... and /ams/tfm-files): ==================================================== Sometime after AMSFonts 2.0 was released, it was brought to our attention that there was a bug in the Metafont code for the AMS extra symbol fonts (MSAM and MSBM) that caused different TFM files to be produced when these fonts were run at different resolutions. This has been fixed in 2.1. Another significant enhancement in the MSBM font is much improved character rendering for the Blackboard Bold characters at low resolutions. (Thanks to Stefan Lindner for the Metafont help with the Blackboard Bold characters.) Additionally, through several communications with Knuth we are pleased to release improved versions of the Euler and extra CM fonts. All of the Euler bold fonts have been made more bold and extended. In previous versions of Euler, it was very difficult to distinguish the bold from the non-bold versions of these fonts. Knuth also reviewed the parameter listings for the additional point sizes of the CM fonts that we created and we have incorporated his suggestions into this release. Another change with AMSFonts 2.1 is that we are now distributing more resolutions of PK files. Previously, e-MATH contained only 118 and 300 dpi fonts. We have now posted 118, 180, 240, 300, and 400 dpi fonts to the /ams/amsfonts/pk-files/... area of e-MATH. As before, Metafont sources for all of the AMSFonts are also available. AMS-TeX 2.1 (/ams/amstex): ========================== This is mainly a bug-fix version, with some minor enhancements. A new file, amsppt1.tex, has been added to provide backward compatibility with documents written under amsppt.sty version 1 but run with AMS-TeX 2.0 or later. AMS-LaTeX 1.1 (/ams/amslatex): ============================== Again, this is mainly a bug-fix version with some enhancements. In an effort to keep this area current we are now distributing the complete Mittelbach/Schoepf font selection scheme in the /ams/amslatex/fontsel area. When new versions of these files become available, we will attempt to quickly verify their compatibility with AMS-LaTeX and post them to e-MATH. Please direct any problems or questions concerning the TeX archive on e-MATH to: Technical Support Group American Mathematical Society 201 Charles Street P.O. Box 6248 Providence, RI 02940 USA (800) 321-4AMS (321-4267) ext. 4080 (401) 455-4080 Internet: tech-support@math.ams.com Thank you. Ralph Youngen Supervisor, Technical Support American Mathematical Society Internet: REY@MATH.AMS.COM ------- From "Eberhard Mattes " Fri Jul 5 05:18:02 1991 Flags: 000000000001 Return-Path: Received: from ifi.informatik.uni-stuttgart.de by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01931; Fri, 5 Jul 91 05:17:05 MDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Fri, 5 Jul 91 13:15:33 +0200 From: Eberhard Mattes Date: Fri, 5 Jul 91 13:16:52 +0200 Message-Id: <9107051116.AA10075@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Fri, 5 Jul 91 13:16:52 +0200 To: tex-archive@science.utah.edu Subject: Re: emTeX: English dvidrv manual now available Sorry, the was a typo in my previous announcement, the correct path is: disk6/dvidrvma.zip Good news: emTeX on monu1.cc.monash.edu.au has been updated. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) From "Eberhard Mattes " Fri Jul 5 05:18:02 1991 Flags: 000000000001 Return-Path: Received: from ifi.informatik.uni-stuttgart.de by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01931; Fri, 5 Jul 91 05:17:05 MDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Fri, 5 Jul 91 13:15:33 +0200 From: Eberhard Mattes Date: Fri, 5 Jul 91 13:16:52 +0200 Message-Id: <9107051116.AA10075@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Fri, 5 Jul 91 13:16:52 +0200 To: tex-archive@science.utah.edu Subject: Re: emTeX: English dvidrv manual now available Sorry, the was a typo in my previous announcement, the correct path is: disk6/dvidrvma.zip Good news: emTeX on monu1.cc.monash.edu.au has been updated. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) From "Mail Delivery Subsystem " Mon Jul 8 05:25:05 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB16801; Mon, 8 Jul 91 05:25:03 MDT Date: Mon, 8 Jul 91 05:25:03 MDT From: Mail Delivery Subsystem Subject: Returned mail: Cannot send message for 3 days Message-Id: <9107081125.AB16801@math.utah.edu> To: beebe ----- Transcript of session follows ----- 421 cine88.cineca.it: Connection refused by cine88.cineca.it ----- Unsent message follows ----- Return-Path: Received: from ifi.informatik.uni-stuttgart.de by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01931; Fri, 5 Jul 91 05:17:05 MDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Fri, 5 Jul 91 13:15:33 +0200 From: Eberhard Mattes Date: Fri, 5 Jul 91 13:16:52 +0200 Message-Id: <9107051116.AA10075@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Fri, 5 Jul 91 13:16:52 +0200 To: tex-archive@science.utah.edu Subject: Re: emTeX: English dvidrv manual now available Sorry, the was a typo in my previous announcement, the correct path is: disk6/dvidrvma.zip Good news: emTeX on monu1.cc.monash.edu.au has been updated. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) From "Mail Delivery Subsystem " Mon Jul 8 05:25:05 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB16801; Mon, 8 Jul 91 05:25:03 MDT Date: Mon, 8 Jul 91 05:25:03 MDT From: Mail Delivery Subsystem Subject: Returned mail: Cannot send message for 3 days Message-Id: <9107081125.AB16801@math.utah.edu> To: beebe ----- Transcript of session follows ----- 421 cine88.cineca.it: Connection refused by cine88.cineca.it ----- Unsent message follows ----- Return-Path: Received: from ifi.informatik.uni-stuttgart.de by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01931; Fri, 5 Jul 91 05:17:05 MDT Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Fri, 5 Jul 91 13:15:33 +0200 From: Eberhard Mattes Date: Fri, 5 Jul 91 13:16:52 +0200 Message-Id: <9107051116.AA10075@azu.informatik.uni-stuttgart.de> Received: by azu.informatik.uni-stuttgart.de; Fri, 5 Jul 91 13:16:52 +0200 To: tex-archive@science.utah.edu Subject: Re: emTeX: English dvidrv manual now available Sorry, the was a typo in my previous announcement, the correct path is: disk6/dvidrvma.zip Good news: emTeX on monu1.cc.monash.edu.au has been updated. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) From "karl@cs.umb.edu (Karl Berry)" Wed Jul 17 12:32:13 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22551; Wed, 17 Jul 91 12:32:06 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA15729; Wed, 17 Jul 91 14:31:50 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA12608; Wed, 17 Jul 91 14:31:37 EDT Date: Wed, 17 Jul 91 14:31:37 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107171831.AA12608@ra.cs.umb.edu> To: tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, info-tex@shsu.BITNET, uktex@tex.ac.uk Subject: modes.mf version 0.5 released Reply-To: karl@cs.umb.edu I have released version 0.5 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/modes.mf I will also send it to you by email if you cannot ftp. It is about 38K. This version handles write-white devices in a better way than 0.4. It also allows selective overriding of any of the mode_def parameters. This file is a collection of Metafont mode_def's (probably close to all of them in existence). It also makes common definitions for write-white printers and `special' information. If you have mode_def's which are not listed below, please send them to me. I would also appreciate getting definitive information on the Linotronic and/or Epson printers. (Notes in the file reflect the current state of confusion.) karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga. mode_def AtariSLMEightZeroFour = % Atari ST SLM 804 printer mode_def AtariSMOneTwoFour = % Atari ST SM 124 screen mode_def aps = % Autologic APS-Micro5 mode_def ApsSixHi = % Autologic APS-Micro6 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def boise = % HP 2680A mode_def CanonCX = % e.g., Apple LaserWriter [NTX] mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def CanonSX = % Canon SX mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def dover = % Xerox Dover mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def epsonlo = % Epson at 120dpi mode_def GThreefax = % 200 x 100dpi G3fax mode_def HPDeskJet = % HP DeskJet 500 mode_def IBMD = % IBM 38xx mode_def IBMFourTwoFiveZero = % IBM 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMSixSixSevenZero = % IBM 6670 (Sherpa) mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetlo = % HP LaserJet at 150dpi mode_def LASevenFive = % DEC LA75 mode_def LinotypeOneZeroZeroLo = % Linotype Linotronic [13]00 at 635dpi mode_def LinotypeOneZeroZero = % Linotype Linotronic [13]00 at 1270dpi mode_def LinotypeThreeZeroZeroHi = % Linotype Linotronic 300 at 2540dpi mode_def LNZeroOne = % DEC LN01 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NEC = % NEC mode_def NEChi = % NEC at 360dpi mode_def Newgen = % Newgen 400dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def OCESixSevenFiveZeroPS = % OCE 6750PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def qms = % QMS (Xerox engine) mode_def RicohFourZeroEightZero = % e.g., the TI Omnilaser mode_def RicohLP = % e.g., the DEC LN03 mode_def SparcPrinter = % Sun SPARCprinter mode_def StarNLOneZero = % Star NL-10 mode_def sun = % Sun and BBN Bitgraph at 85dpi mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX, EpsonLQ mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxEightSevenNineZero = % Xerox 8790 or 4045 mode_def XeroxFourZeroFiveZero = % Xerox 4050 mode_def XeroxNineSevenZeroZero = % Xerox 9700 mode_def XeroxThreeSevenZeroZero = % Xerox 3700 From "karl@cs.umb.edu (Karl Berry)" Wed Jul 17 12:32:13 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22551; Wed, 17 Jul 91 12:32:06 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA15729; Wed, 17 Jul 91 14:31:50 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA12608; Wed, 17 Jul 91 14:31:37 EDT Date: Wed, 17 Jul 91 14:31:37 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107171831.AA12608@ra.cs.umb.edu> To: tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, info-tex@shsu.BITNET, uktex@tex.ac.uk Subject: modes.mf version 0.5 released Reply-To: karl@cs.umb.edu I have released version 0.5 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/modes.mf I will also send it to you by email if you cannot ftp. It is about 38K. This version handles write-white devices in a better way than 0.4. It also allows selective overriding of any of the mode_def parameters. This file is a collection of Metafont mode_def's (probably close to all of them in existence). It also makes common definitions for write-white printers and `special' information. If you have mode_def's which are not listed below, please send them to me. I would also appreciate getting definitive information on the Linotronic and/or Epson printers. (Notes in the file reflect the current state of confusion.) karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga. mode_def AtariSLMEightZeroFour = % Atari ST SLM 804 printer mode_def AtariSMOneTwoFour = % Atari ST SM 124 screen mode_def aps = % Autologic APS-Micro5 mode_def ApsSixHi = % Autologic APS-Micro6 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def boise = % HP 2680A mode_def CanonCX = % e.g., Apple LaserWriter [NTX] mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def CanonSX = % Canon SX mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def dover = % Xerox Dover mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def epsonlo = % Epson at 120dpi mode_def GThreefax = % 200 x 100dpi G3fax mode_def HPDeskJet = % HP DeskJet 500 mode_def IBMD = % IBM 38xx mode_def IBMFourTwoFiveZero = % IBM 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMSixSixSevenZero = % IBM 6670 (Sherpa) mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetlo = % HP LaserJet at 150dpi mode_def LASevenFive = % DEC LA75 mode_def LinotypeOneZeroZeroLo = % Linotype Linotronic [13]00 at 635dpi mode_def LinotypeOneZeroZero = % Linotype Linotronic [13]00 at 1270dpi mode_def LinotypeThreeZeroZeroHi = % Linotype Linotronic 300 at 2540dpi mode_def LNZeroOne = % DEC LN01 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NEC = % NEC mode_def NEChi = % NEC at 360dpi mode_def Newgen = % Newgen 400dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def OCESixSevenFiveZeroPS = % OCE 6750PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def qms = % QMS (Xerox engine) mode_def RicohFourZeroEightZero = % e.g., the TI Omnilaser mode_def RicohLP = % e.g., the DEC LN03 mode_def SparcPrinter = % Sun SPARCprinter mode_def StarNLOneZero = % Star NL-10 mode_def sun = % Sun and BBN Bitgraph at 85dpi mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX, EpsonLQ mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxEightSevenNineZero = % Xerox 8790 or 4045 mode_def XeroxFourZeroFiveZero = % Xerox 4050 mode_def XeroxNineSevenZeroZero = % Xerox 9700 mode_def XeroxThreeSevenZeroZero = % Xerox 3700 From "karl@cs.umb.edu (Karl Berry)" Thu Jul 18 11:05:01 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01149; Thu, 18 Jul 91 11:03:33 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA27417; Thu, 18 Jul 91 13:01:08 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA24573; Thu, 18 Jul 91 13:00:54 EDT Date: Thu, 18 Jul 91 13:00:54 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107181700.AA24573@ra.cs.umb.edu> To: info-tex@shsu.BITNET, tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Subject: modes.mf 0.6 released I have released version 0.6 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/modes.mf I will also send it to you by email if you cannot ftp. It is about 38K. This version fixes a thinko in mode_common_setup_ that I made in 0.5. Sigh. It also adds one new mode_def (for the Varityper 5060W). This file is a collection of Metafont mode_def's (probably close to all of them in existence). It also makes common definitions for write-white printers and `special' information. If you have mode_def's which are not listed below, please send them to me. I would also appreciate getting definitive information on the Linotronic and/or Epson printers. (Notes in the file reflect the current state of confusion.) karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga. mode_def AtariSLMEightZeroFour = % Atari ST SLM 804 printer mode_def AtariSMOneTwoFour = % Atari ST SM 124 screen mode_def aps = % Autologic APS-Micro5 mode_def ApsSixHi = % Autologic APS-Micro6 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def boise = % HP 2680A mode_def CanonCX = % e.g., Apple LaserWriter [NTX] mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def CanonSX = % Canon SX mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def dover = % Xerox Dover mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def epsonlo = % Epson at 120dpi mode_def GThreefax = % 200 x 100dpi G3fax mode_def HPDeskJet = % HP DeskJet 500 mode_def IBMD = % IBM 38xx mode_def IBMFourTwoFiveZero = % IBM 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMSixSixSevenZero = % IBM 6670 (Sherpa) mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetlo = % HP LaserJet at 150dpi mode_def LASevenFive = % DEC LA75 mode_def LinotypeOneZeroZeroLo = % Linotype Linotronic [13]00 at 635dpi mode_def LinotypeOneZeroZero = % Linotype Linotronic [13]00 at 1270dpi mode_def LinotypeThreeZeroZeroHi = % Linotype Linotronic 300 at 2540dpi mode_def LNZeroOne = % DEC LN01 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NEC = % NEC mode_def NEChi = % NEC at 360dpi mode_def Newgen = % Newgen 400dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def OCESixSevenFiveZeroPS = % OCE 6750PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def qms = % QMS (Xerox engine) mode_def RicohFourZeroEightZero = % e.g., the TI Omnilaser mode_def RicohLP = % e.g., the DEC LN03 mode_def SparcPrinter = % Sun SPARCprinter mode_def StarNLOneZero = % Star NL-10 mode_def sun = % Sun and BBN Bitgraph at 85dpi mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX, EpsonLQ mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperFiveZeroSixZeroW = mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxEightSevenNineZero = % Xerox 8790 or 4045 mode_def XeroxFourZeroFiveZero = % Xerox 4050 mode_def XeroxNineSevenZeroZero = % Xerox 9700 mode_def XeroxThreeSevenZeroZero = % Xerox 3700 From "karl@cs.umb.edu (Karl Berry)" Thu Jul 18 11:05:01 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01149; Thu, 18 Jul 91 11:03:33 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA27417; Thu, 18 Jul 91 13:01:08 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA24573; Thu, 18 Jul 91 13:00:54 EDT Date: Thu, 18 Jul 91 13:00:54 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107181700.AA24573@ra.cs.umb.edu> To: info-tex@shsu.BITNET, tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Subject: modes.mf 0.6 released I have released version 0.6 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/modes.mf I will also send it to you by email if you cannot ftp. It is about 38K. This version fixes a thinko in mode_common_setup_ that I made in 0.5. Sigh. It also adds one new mode_def (for the Varityper 5060W). This file is a collection of Metafont mode_def's (probably close to all of them in existence). It also makes common definitions for write-white printers and `special' information. If you have mode_def's which are not listed below, please send them to me. I would also appreciate getting definitive information on the Linotronic and/or Epson printers. (Notes in the file reflect the current state of confusion.) karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga. mode_def AtariSLMEightZeroFour = % Atari ST SLM 804 printer mode_def AtariSMOneTwoFour = % Atari ST SM 124 screen mode_def aps = % Autologic APS-Micro5 mode_def ApsSixHi = % Autologic APS-Micro6 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def boise = % HP 2680A mode_def CanonCX = % e.g., Apple LaserWriter [NTX] mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def CanonSX = % Canon SX mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def dover = % Xerox Dover mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def epsonlo = % Epson at 120dpi mode_def GThreefax = % 200 x 100dpi G3fax mode_def HPDeskJet = % HP DeskJet 500 mode_def IBMD = % IBM 38xx mode_def IBMFourTwoFiveZero = % IBM 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMSixSixSevenZero = % IBM 6670 (Sherpa) mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetlo = % HP LaserJet at 150dpi mode_def LASevenFive = % DEC LA75 mode_def LinotypeOneZeroZeroLo = % Linotype Linotronic [13]00 at 635dpi mode_def LinotypeOneZeroZero = % Linotype Linotronic [13]00 at 1270dpi mode_def LinotypeThreeZeroZeroHi = % Linotype Linotronic 300 at 2540dpi mode_def LNZeroOne = % DEC LN01 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NEC = % NEC mode_def NEChi = % NEC at 360dpi mode_def Newgen = % Newgen 400dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def OCESixSevenFiveZeroPS = % OCE 6750PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def qms = % QMS (Xerox engine) mode_def RicohFourZeroEightZero = % e.g., the TI Omnilaser mode_def RicohLP = % e.g., the DEC LN03 mode_def SparcPrinter = % Sun SPARCprinter mode_def StarNLOneZero = % Star NL-10 mode_def sun = % Sun and BBN Bitgraph at 85dpi mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX, EpsonLQ mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperFiveZeroSixZeroW = mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxEightSevenNineZero = % Xerox 8790 or 4045 mode_def XeroxFourZeroFiveZero = % Xerox 4050 mode_def XeroxNineSevenZeroZero = % Xerox 9700 mode_def XeroxThreeSevenZeroZero = % Xerox 3700 From "Mail Delivery Subsystem " Thu Jul 18 11:16:28 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB01151; Thu, 18 Jul 91 11:03:33 MDT Date: Thu, 18 Jul 91 11:03:33 MDT From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <9107181703.AB01151@math.utah.edu> To: owner-tex-fonts To: owner-tex-archive ----- Transcript of session follows ----- Connected to MCC.COM: >>> RCPT To: <<< 550 No such local mailbox as "beihl", recipient rejected 550 beihl@mcc.com... User unknown ----- Unsent message follows ----- Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01149; Thu, 18 Jul 91 11:03:33 MDT Errors-To: beebe Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA27417; Thu, 18 Jul 91 13:01:08 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA24573; Thu, 18 Jul 91 13:00:54 EDT Date: Thu, 18 Jul 91 13:00:54 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107181700.AA24573@ra.cs.umb.edu> To: info-tex@shsu.BITNET, tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Subject: modes.mf 0.6 released I have released version 0.6 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/modes.mf I will also send it to you by email if you cannot ftp. It is about 38K. This version fixes a thinko in mode_common_setup_ that I made in 0.5. Sigh. It also adds one new mode_def (for the Varityper 5060W). This file is a collection of Metafont mode_def's (probably close to all of them in existence). It also makes common definitions for write-white printers and `special' information. If you have mode_def's which are not listed below, please send them to me. I would also appreciate getting definitive information on the Linotronic and/or Epson printers. (Notes in the file reflect the current state of confusion.) karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga. mode_def AtariSLMEightZeroFour = % Atari ST SLM 804 printer mode_def AtariSMOneTwoFour = % Atari ST SM 124 screen mode_def aps = % Autologic APS-Micro5 mode_def ApsSixHi = % Autologic APS-Micro6 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def boise = % HP 2680A mode_def CanonCX = % e.g., Apple LaserWriter [NTX] mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def CanonSX = % Canon SX mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def dover = % Xerox Dover mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def epsonlo = % Epson at 120dpi mode_def GThreefax = % 200 x 100dpi G3fax mode_def HPDeskJet = % HP DeskJet 500 mode_def IBMD = % IBM 38xx mode_def IBMFourTwoFiveZero = % IBM 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMSixSixSevenZero = % IBM 6670 (Sherpa) mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetlo = % HP LaserJet at 150dpi mode_def LASevenFive = % DEC LA75 mode_def LinotypeOneZeroZeroLo = % Linotype Linotronic [13]00 at 635dpi mode_def LinotypeOneZeroZero = % Linotype Linotronic [13]00 at 1270dpi mode_def LinotypeThreeZeroZeroHi = % Linotype Linotronic 300 at 2540dpi mode_def LNZeroOne = % DEC LN01 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NEC = % NEC mode_def NEChi = % NEC at 360dpi mode_def Newgen = % Newgen 400dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def OCESixSevenFiveZeroPS = % OCE 6750PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def qms = % QMS (Xerox engine) mode_def RicohFourZeroEightZero = % e.g., the TI Omnilaser mode_def RicohLP = % e.g., the DEC LN03 mode_def SparcPrinter = % Sun SPARCprinter mode_def StarNLOneZero = % Star NL-10 mode_def sun = % Sun and BBN Bitgraph at 85dpi mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX, EpsonLQ mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperFiveZeroSixZeroW = mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxEightSevenNineZero = % Xerox 8790 or 4045 mode_def XeroxFourZeroFiveZero = % Xerox 4050 mode_def XeroxNineSevenZeroZero = % Xerox 9700 mode_def XeroxThreeSevenZeroZero = % Xerox 3700 From "Mail Delivery Subsystem " Thu Jul 18 11:16:28 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB01151; Thu, 18 Jul 91 11:03:33 MDT Date: Thu, 18 Jul 91 11:03:33 MDT From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <9107181703.AB01151@math.utah.edu> To: owner-tex-fonts To: owner-tex-archive ----- Transcript of session follows ----- Connected to MCC.COM: >>> RCPT To: <<< 550 No such local mailbox as "beihl", recipient rejected 550 beihl@mcc.com... User unknown ----- Unsent message follows ----- Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01149; Thu, 18 Jul 91 11:03:33 MDT Errors-To: beebe Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA27417; Thu, 18 Jul 91 13:01:08 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA24573; Thu, 18 Jul 91 13:00:54 EDT Date: Thu, 18 Jul 91 13:00:54 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107181700.AA24573@ra.cs.umb.edu> To: info-tex@shsu.BITNET, tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Subject: modes.mf 0.6 released I have released version 0.6 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/modes.mf I will also send it to you by email if you cannot ftp. It is about 38K. This version fixes a thinko in mode_common_setup_ that I made in 0.5. Sigh. It also adds one new mode_def (for the Varityper 5060W). This file is a collection of Metafont mode_def's (probably close to all of them in existence). It also makes common definitions for write-white printers and `special' information. If you have mode_def's which are not listed below, please send them to me. I would also appreciate getting definitive information on the Linotronic and/or Epson printers. (Notes in the file reflect the current state of confusion.) karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga. mode_def AtariSLMEightZeroFour = % Atari ST SLM 804 printer mode_def AtariSMOneTwoFour = % Atari ST SM 124 screen mode_def aps = % Autologic APS-Micro5 mode_def ApsSixHi = % Autologic APS-Micro6 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def boise = % HP 2680A mode_def CanonCX = % e.g., Apple LaserWriter [NTX] mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def CanonSX = % Canon SX mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def dover = % Xerox Dover mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def epsonlo = % Epson at 120dpi mode_def GThreefax = % 200 x 100dpi G3fax mode_def HPDeskJet = % HP DeskJet 500 mode_def IBMD = % IBM 38xx mode_def IBMFourTwoFiveZero = % IBM 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMSixSixSevenZero = % IBM 6670 (Sherpa) mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetlo = % HP LaserJet at 150dpi mode_def LASevenFive = % DEC LA75 mode_def LinotypeOneZeroZeroLo = % Linotype Linotronic [13]00 at 635dpi mode_def LinotypeOneZeroZero = % Linotype Linotronic [13]00 at 1270dpi mode_def LinotypeThreeZeroZeroHi = % Linotype Linotronic 300 at 2540dpi mode_def LNZeroOne = % DEC LN01 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NEC = % NEC mode_def NEChi = % NEC at 360dpi mode_def Newgen = % Newgen 400dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def OCESixSevenFiveZeroPS = % OCE 6750PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def qms = % QMS (Xerox engine) mode_def RicohFourZeroEightZero = % e.g., the TI Omnilaser mode_def RicohLP = % e.g., the DEC LN03 mode_def SparcPrinter = % Sun SPARCprinter mode_def StarNLOneZero = % Star NL-10 mode_def sun = % Sun and BBN Bitgraph at 85dpi mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX, EpsonLQ mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperFiveZeroSixZeroW = mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxEightSevenNineZero = % Xerox 8790 or 4045 mode_def XeroxFourZeroFiveZero = % Xerox 4050 mode_def XeroxNineSevenZeroZero = % Xerox 9700 mode_def XeroxThreeSevenZeroZero = % Xerox 3700 From "George D. Greenwade " Tue Jul 23 10:23:14 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00499; Tue, 23 Jul 91 10:15:23 MDT Received: by SHSU.edu (MX V2.3-1) id 13454; Tue, 23 Jul 1991 11:15:57 CDT Date: Tue, 23 Jul 1991 11:15:57 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094C067.189A31A0.13454@SHSU.edu> Subject: New versions of PKtoSFP and SFPtoPK on FILESERV On Tue, 23 Jul 1991 10:30 EDT, Norm Walsh forwarded me new versions of his SFPtoPK and PKtoSFP utilities which convert Hewlett-Packard softfonts to and from TeX PK/TFM format. These new versions handle scaled PK files (i.e., cmr10 scaled \magstep5). I have put them in place on FILESERV for your access. ------------------------------'RELEASE NOTES'----------------------------- Greetings Net, I've made a few changes to SFPtoPK and PKtoSFP to provide better handling of scaled PK files. PKtoSFP will now notice the resolution of the PK file and create an SFP file with the appropriate spacing. The SFPtoPK package includes a new utility called PKscale that will modify the PK files created by SFPtoPK to work as scaled PK files. norm The files are retained as UUENCODED ZIP files as SPFONTWARE.PKtoSFP_ZIP, SPFONTWARE.SFPtoPK_ZIP_1OF3, SPFONTWARE.SFPtoPK_ZIP_2OF3, and SPFONTWARE.SFPtoPK_ZIP_3OF3 (the SFPtoPK set has to be concatenated due to file size and mailers). To retrieve these files, include the commands: SENDME SPFONTWARE.PKtoSFP_ZIP SENDME SPFONTWARE.SFPtoPK* in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). For anonymous ftp users, these are on Niord.SHSU.edu (192.92.115.8) in the directory [.SPFONTWARE] and the UUDECODED SFPtoPK.ZIP file in one part is available there. For those unfamiliar with Norm's SPFONTWARE package and its features, please include the command DIRECTORY SPFONTWARE in the body of a mail message to FILESERV. Thanks are extended to Norm for keeping us posted on this handy utility. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "George D. Greenwade " Tue Jul 23 10:23:14 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00499; Tue, 23 Jul 91 10:15:23 MDT Received: by SHSU.edu (MX V2.3-1) id 13454; Tue, 23 Jul 1991 11:15:57 CDT Date: Tue, 23 Jul 1991 11:15:57 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094C067.189A31A0.13454@SHSU.edu> Subject: New versions of PKtoSFP and SFPtoPK on FILESERV On Tue, 23 Jul 1991 10:30 EDT, Norm Walsh forwarded me new versions of his SFPtoPK and PKtoSFP utilities which convert Hewlett-Packard softfonts to and from TeX PK/TFM format. These new versions handle scaled PK files (i.e., cmr10 scaled \magstep5). I have put them in place on FILESERV for your access. ------------------------------'RELEASE NOTES'----------------------------- Greetings Net, I've made a few changes to SFPtoPK and PKtoSFP to provide better handling of scaled PK files. PKtoSFP will now notice the resolution of the PK file and create an SFP file with the appropriate spacing. The SFPtoPK package includes a new utility called PKscale that will modify the PK files created by SFPtoPK to work as scaled PK files. norm The files are retained as UUENCODED ZIP files as SPFONTWARE.PKtoSFP_ZIP, SPFONTWARE.SFPtoPK_ZIP_1OF3, SPFONTWARE.SFPtoPK_ZIP_2OF3, and SPFONTWARE.SFPtoPK_ZIP_3OF3 (the SFPtoPK set has to be concatenated due to file size and mailers). To retrieve these files, include the commands: SENDME SPFONTWARE.PKtoSFP_ZIP SENDME SPFONTWARE.SFPtoPK* in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). For anonymous ftp users, these are on Niord.SHSU.edu (192.92.115.8) in the directory [.SPFONTWARE] and the UUDECODED SFPtoPK.ZIP file in one part is available there. For those unfamiliar with Norm's SPFONTWARE package and its features, please include the command DIRECTORY SPFONTWARE in the body of a mail message to FILESERV. Thanks are extended to Norm for keeping us posted on this handy utility. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "Mail Delivery Subsystem " Tue Jul 23 10:34:31 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB00501; Tue, 23 Jul 91 10:15:23 MDT Date: Tue, 23 Jul 91 10:15:23 MDT From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <9107231615.AB00501@math.utah.edu> To: owner-tex-archive ----- Transcript of session follows ----- Connected to MCC.COM: >>> RCPT To: <<< 550 No such local mailbox as "beihl", recipient rejected 550 beihl@mcc.com... User unknown ----- Unsent message follows ----- Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00499; Tue, 23 Jul 91 10:15:23 MDT Errors-To: beebe Received: by SHSU.edu (MX V2.3-1) id 13454; Tue, 23 Jul 1991 11:15:57 CDT Date: Tue, 23 Jul 1991 11:15:57 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094C067.189A31A0.13454@SHSU.edu> Subject: New versions of PKtoSFP and SFPtoPK on FILESERV On Tue, 23 Jul 1991 10:30 EDT, Norm Walsh forwarded me new versions of his SFPtoPK and PKtoSFP utilities which convert Hewlett-Packard softfonts to and from TeX PK/TFM format. These new versions handle scaled PK files (i.e., cmr10 scaled \magstep5). I have put them in place on FILESERV for your access. ------------------------------'RELEASE NOTES'----------------------------- Greetings Net, I've made a few changes to SFPtoPK and PKtoSFP to provide better handling of scaled PK files. PKtoSFP will now notice the resolution of the PK file and create an SFP file with the appropriate spacing. The SFPtoPK package includes a new utility called PKscale that will modify the PK files created by SFPtoPK to work as scaled PK files. norm The files are retained as UUENCODED ZIP files as SPFONTWARE.PKtoSFP_ZIP, SPFONTWARE.SFPtoPK_ZIP_1OF3, SPFONTWARE.SFPtoPK_ZIP_2OF3, and SPFONTWARE.SFPtoPK_ZIP_3OF3 (the SFPtoPK set has to be concatenated due to file size and mailers). To retrieve these files, include the commands: SENDME SPFONTWARE.PKtoSFP_ZIP SENDME SPFONTWARE.SFPtoPK* in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). For anonymous ftp users, these are on Niord.SHSU.edu (192.92.115.8) in the directory [.SPFONTWARE] and the UUDECODED SFPtoPK.ZIP file in one part is available there. For those unfamiliar with Norm's SPFONTWARE package and its features, please include the command DIRECTORY SPFONTWARE in the body of a mail message to FILESERV. Thanks are extended to Norm for keeping us posted on this handy utility. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "Mail Delivery Subsystem " Tue Jul 23 10:34:31 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB00501; Tue, 23 Jul 91 10:15:23 MDT Date: Tue, 23 Jul 91 10:15:23 MDT From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <9107231615.AB00501@math.utah.edu> To: owner-tex-archive ----- Transcript of session follows ----- Connected to MCC.COM: >>> RCPT To: <<< 550 No such local mailbox as "beihl", recipient rejected 550 beihl@mcc.com... User unknown ----- Unsent message follows ----- Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00499; Tue, 23 Jul 91 10:15:23 MDT Errors-To: beebe Received: by SHSU.edu (MX V2.3-1) id 13454; Tue, 23 Jul 1991 11:15:57 CDT Date: Tue, 23 Jul 1991 11:15:57 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094C067.189A31A0.13454@SHSU.edu> Subject: New versions of PKtoSFP and SFPtoPK on FILESERV On Tue, 23 Jul 1991 10:30 EDT, Norm Walsh forwarded me new versions of his SFPtoPK and PKtoSFP utilities which convert Hewlett-Packard softfonts to and from TeX PK/TFM format. These new versions handle scaled PK files (i.e., cmr10 scaled \magstep5). I have put them in place on FILESERV for your access. ------------------------------'RELEASE NOTES'----------------------------- Greetings Net, I've made a few changes to SFPtoPK and PKtoSFP to provide better handling of scaled PK files. PKtoSFP will now notice the resolution of the PK file and create an SFP file with the appropriate spacing. The SFPtoPK package includes a new utility called PKscale that will modify the PK files created by SFPtoPK to work as scaled PK files. norm The files are retained as UUENCODED ZIP files as SPFONTWARE.PKtoSFP_ZIP, SPFONTWARE.SFPtoPK_ZIP_1OF3, SPFONTWARE.SFPtoPK_ZIP_2OF3, and SPFONTWARE.SFPtoPK_ZIP_3OF3 (the SFPtoPK set has to be concatenated due to file size and mailers). To retrieve these files, include the commands: SENDME SPFONTWARE.PKtoSFP_ZIP SENDME SPFONTWARE.SFPtoPK* in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). For anonymous ftp users, these are on Niord.SHSU.edu (192.92.115.8) in the directory [.SPFONTWARE] and the UUDECODED SFPtoPK.ZIP file in one part is available there. For those unfamiliar with Norm's SPFONTWARE package and its features, please include the command DIRECTORY SPFONTWARE in the body of a mail message to FILESERV. Thanks are extended to Norm for keeping us posted on this handy utility. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "tex-arc@radel.com (tex-archive list)" Wed Jul 24 21:56:19 1991 Flags: 000000000011 Return-Path: Received: from uu.psi.com by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11417; Wed, 24 Jul 91 21:56:17 MDT Received: from radel.UUCP by uu.psi.com (5.65b/4.0.071791-Performance Systems International) id AA19282; Wed, 24 Jul 91 23:53:48 -0400 Date: Wed, 24 Jul 91 22:11:29 EDT From: tex-arc@radel.com (tex-archive list) Subject: please add to list Message-Id: <9107242211.0.UUL1.3#20406@radel.com> To: tex-archive-request@math.utah.edu Cc: jon@radel.com Please add this account, tex-arc@radel.com, to the mailing list. Thank you. --Jon Radel From "tex-arc@radel.com (tex-archive list)" Wed Jul 24 21:56:19 1991 Flags: 000000000011 Return-Path: Received: from uu.psi.com by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11417; Wed, 24 Jul 91 21:56:17 MDT Received: from radel.UUCP by uu.psi.com (5.65b/4.0.071791-Performance Systems International) id AA19282; Wed, 24 Jul 91 23:53:48 -0400 Date: Wed, 24 Jul 91 22:11:29 EDT From: tex-arc@radel.com (tex-archive list) Subject: please add to list Message-Id: <9107242211.0.UUL1.3#20406@radel.com> To: tex-archive-request@math.utah.edu Cc: jon@radel.com Please add this account, tex-arc@radel.com, to the mailing list. Thank you. --Jon Radel From "karl@cs.umb.edu (Karl Berry)" Tue Jul 30 11:01:58 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06270; Tue, 30 Jul 91 11:01:13 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA08900; Tue, 30 Jul 91 13:01:12 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA03533; Tue, 30 Jul 91 12:59:55 EDT Date: Tue, 30 Jul 91 12:59:55 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107301659.AA03533@ra.cs.umb.edu> To: tex-archive@math.utah.edu, info-tex@shsu.BITNET Subject: minor update to MLTeX Reply-To: karl@cs.umb.edu Michael Ferguson added a change to make MLTeX's banner be different. Revised files on ftp.cs.umb.edu [192.12.26.23]:pub/tex/charsubdef.tar.Z. karl@cs.umb.edu From "karl@cs.umb.edu (Karl Berry)" Tue Jul 30 11:01:58 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06270; Tue, 30 Jul 91 11:01:13 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA08900; Tue, 30 Jul 91 13:01:12 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA03533; Tue, 30 Jul 91 12:59:55 EDT Date: Tue, 30 Jul 91 12:59:55 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9107301659.AA03533@ra.cs.umb.edu> To: tex-archive@math.utah.edu, info-tex@shsu.BITNET Subject: minor update to MLTeX Reply-To: karl@cs.umb.edu Michael Ferguson added a change to make MLTeX's banner be different. Revised files on ftp.cs.umb.edu [192.12.26.23]:pub/tex/charsubdef.tar.Z. karl@cs.umb.edu From "George D. Greenwade " Tue Jul 30 13:04:30 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07144; Tue, 30 Jul 91 13:03:29 MDT Received: by SHSU.edu (MX V2.3-1) id 26041; Tue, 30 Jul 1991 14:03:57 CDT Date: Tue, 30 Jul 1991 14:03:57 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094C5FE.BA93F1C0.26041@SHSU.edu> Subject: STYle archive update on FILESERV Just a quick update on recent updates and additions to the LaTeX STYle archive on FILESERV. First, David Carlisle (author of the longtable.sty/longtable.tex file, also available on FILESERV as STY.LONGTABLE*) forwarded me four files today; two are updates, two are new to our collection. He informs me that all have been contributed to Aston; possibly they reside elsewhere. From his letter to me (with parenthetical notation as to FILESERV name and comments): > These styles are all self-documenting if you have Mittelbach's doc.sty. So > you for example you can typeset examples (and, if you wish the macro > listings) of hhline.sty by typing `latex hhline.sty'. The style files do > not need doc.sty to be *used* (newarray.sty requires Mitelbach's array.sty) > > David Carlisle > > enumerate.sty (STY.ENUMERATE on FILESERV; version 2.0 dated 25 July 1991, > an update to the prior version) > ============= > This style gives the enumerate environment an optional argument > which controls how the counter is printed. > \begin{enumerate}[EX a)] > produces items labeled EX a), EX b) etc. > > indentfirst.sty (STY.INDENTFIRST on FILESERV; 2 January 1991, actually the > doc.sty-able file used as the base for the prior version) > =============== > Causes the first paragraph after a heading to be indented as > usual. > > hhline.sty (STY.HHLINE on FILESERV; 4 June 1991, new file) > ========== > Defines the command \hhline which produces lines rather like > \hline, but the interaction with vertical lines is controlled by an > argument. > \hhline{#==#==#} A double hline `crossed' by three double vlines. > \hhline{|t:==::==:t|) Top left corner , a crossing in which both > the horizontal and the verical lines break, a top right corner. > etc etc. > > newarray.sty (STY.NEWARRAY on FILESERV; 19 July 1991, new file) > ============ > An extension of Mittelbach's array.sty > > \begin{array}({cc}) an array surrounded by ( ... ) > \begin{tabular}\{{ll}. A tabular with a large { on the left. > > \newcolumn{B}{>{\large\bf}c} B can now be used in a tabular > preamble to specify a large bold column. > > \extracolsep works with this style (it does not work with > array.sty) Also, someone asked me privately about printing calendars with LaTeX. I found a file, held here as STY.CALENDAR, to do such a thing. The author is J"urgen Stuber (no net address provided) and the apparent date of issue is 10 May 1991. I believe I retrieved this from the Stuttgart archives, but really don't recall. This is a neat and well-documented file! (well, if that's what you want to do) To retrieve any of these files, include the command: SENDME STY.whichever_one_you_want_from_those_above in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). You can include multiple requests in a single mail request, so long as each SENDME command resides on a unique line of the message. For a complete listing of all STYle files available, include the command DIRECTORY STY on another line of your message to FILESERV. Alternately, anonymous ftp users can retrieve these from Niord.SHSU.edu (192.92.115.8) in the directory [FILESERV.STY]. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "George D. Greenwade " Tue Jul 30 13:04:30 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07144; Tue, 30 Jul 91 13:03:29 MDT Received: by SHSU.edu (MX V2.3-1) id 26041; Tue, 30 Jul 1991 14:03:57 CDT Date: Tue, 30 Jul 1991 14:03:57 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094C5FE.BA93F1C0.26041@SHSU.edu> Subject: STYle archive update on FILESERV Just a quick update on recent updates and additions to the LaTeX STYle archive on FILESERV. First, David Carlisle (author of the longtable.sty/longtable.tex file, also available on FILESERV as STY.LONGTABLE*) forwarded me four files today; two are updates, two are new to our collection. He informs me that all have been contributed to Aston; possibly they reside elsewhere. From his letter to me (with parenthetical notation as to FILESERV name and comments): > These styles are all self-documenting if you have Mittelbach's doc.sty. So > you for example you can typeset examples (and, if you wish the macro > listings) of hhline.sty by typing `latex hhline.sty'. The style files do > not need doc.sty to be *used* (newarray.sty requires Mitelbach's array.sty) > > David Carlisle > > enumerate.sty (STY.ENUMERATE on FILESERV; version 2.0 dated 25 July 1991, > an update to the prior version) > ============= > This style gives the enumerate environment an optional argument > which controls how the counter is printed. > \begin{enumerate}[EX a)] > produces items labeled EX a), EX b) etc. > > indentfirst.sty (STY.INDENTFIRST on FILESERV; 2 January 1991, actually the > doc.sty-able file used as the base for the prior version) > =============== > Causes the first paragraph after a heading to be indented as > usual. > > hhline.sty (STY.HHLINE on FILESERV; 4 June 1991, new file) > ========== > Defines the command \hhline which produces lines rather like > \hline, but the interaction with vertical lines is controlled by an > argument. > \hhline{#==#==#} A double hline `crossed' by three double vlines. > \hhline{|t:==::==:t|) Top left corner , a crossing in which both > the horizontal and the verical lines break, a top right corner. > etc etc. > > newarray.sty (STY.NEWARRAY on FILESERV; 19 July 1991, new file) > ============ > An extension of Mittelbach's array.sty > > \begin{array}({cc}) an array surrounded by ( ... ) > \begin{tabular}\{{ll}. A tabular with a large { on the left. > > \newcolumn{B}{>{\large\bf}c} B can now be used in a tabular > preamble to specify a large bold column. > > \extracolsep works with this style (it does not work with > array.sty) Also, someone asked me privately about printing calendars with LaTeX. I found a file, held here as STY.CALENDAR, to do such a thing. The author is J"urgen Stuber (no net address provided) and the apparent date of issue is 10 May 1991. I believe I retrieved this from the Stuttgart archives, but really don't recall. This is a neat and well-documented file! (well, if that's what you want to do) To retrieve any of these files, include the command: SENDME STY.whichever_one_you_want_from_those_above in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). You can include multiple requests in a single mail request, so long as each SENDME command resides on a unique line of the message. For a complete listing of all STYle files available, include the command DIRECTORY STY on another line of your message to FILESERV. Alternately, anonymous ftp users can retrieve these from Niord.SHSU.edu (192.92.115.8) in the directory [FILESERV.STY]. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "Wayne G. Sullivan " Mon Aug 12 03:36:58 1991 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24993; Mon, 12 Aug 91 03:36:25 MDT Received: from IRLEARN.UCD.IE (MAILER@IRLEARN) by CC.UTAH.EDU with PMDF#10043; Mon, 12 Aug 1991 03:36 MST Received: from IRLEARN.UCD.IE (WSULIVAN) by IRLEARN.UCD.IE (Mailer R2.08) with BSMTP id 9063; Mon, 12 Aug 91 10:36:10 GMT Date: Mon, 12 Aug 91 10:28:17 GMT From: "Wayne G. Sullivan" Subject: preloaded fonts in Plain.tex To: tex-archive@math.utah.edu Message-Id: X-Envelope-To: tex-archive@math.utah.edu I see there is a promised revision of Plain due this autumn. I hope DEK will make it easier for the user to remove unwanted "preloaded" fonts. I think it would be better if these were in a separate file to simplify the adaptation to local conditions. If the new Plain does not do this, perhaps the archives can keep a second copy of Plain with all the preloaded fonts commented out. From "Wayne G. Sullivan " Mon Aug 12 03:36:58 1991 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24993; Mon, 12 Aug 91 03:36:25 MDT Received: from IRLEARN.UCD.IE (MAILER@IRLEARN) by CC.UTAH.EDU with PMDF#10043; Mon, 12 Aug 1991 03:36 MST Received: from IRLEARN.UCD.IE (WSULIVAN) by IRLEARN.UCD.IE (Mailer R2.08) with BSMTP id 9063; Mon, 12 Aug 91 10:36:10 GMT Date: Mon, 12 Aug 91 10:28:17 GMT From: "Wayne G. Sullivan" Subject: preloaded fonts in Plain.tex To: tex-archive@math.utah.edu Message-Id: X-Envelope-To: tex-archive@math.utah.edu I see there is a promised revision of Plain due this autumn. I hope DEK will make it easier for the user to remove unwanted "preloaded" fonts. I think it would be better if these were in a separate file to simplify the adaptation to local conditions. If the new Plain does not do this, perhaps the archives can keep a second copy of Plain with all the preloaded fonts commented out. From "JANET CA_ROWLEY@UK.AC.OPEN.ACS.VAX " Mon Aug 12 16:51:53 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22697; Mon, 12 Aug 91 16:50:55 MDT Message-Id: <9108122250.AA22697@math.utah.edu> Received: from vax.acs.open.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <18748-0@sun2.nsfnet-relay.ac.uk>; Mon, 12 Aug 1991 23:47:01 +0100 Date: Mon, 12 AUG 91 23:46:08 +0100 From: CA_ROWLEY@vax.acs.open.ac.uk To: TEX-ARCHIVE <@nsfnet-relay.ac.uk:TEX-ARCHIVE@MATH.UTAH.edu> Subject: RE: (19) preloaded fonts in Plain.tex Sender: JANET "CA_ROWLEY@UK.AC.OPEN.ACS.VAX" > > I see there is a promised revision of Plain due this autumn. Whence cometh this information? chris From "JANET CA_ROWLEY@UK.AC.OPEN.ACS.VAX " Mon Aug 12 16:51:53 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22697; Mon, 12 Aug 91 16:50:55 MDT Message-Id: <9108122250.AA22697@math.utah.edu> Received: from vax.acs.open.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <18748-0@sun2.nsfnet-relay.ac.uk>; Mon, 12 Aug 1991 23:47:01 +0100 Date: Mon, 12 AUG 91 23:46:08 +0100 From: CA_ROWLEY@vax.acs.open.ac.uk To: TEX-ARCHIVE <@nsfnet-relay.ac.uk:TEX-ARCHIVE@MATH.UTAH.edu> Subject: RE: (19) preloaded fonts in Plain.tex Sender: JANET "CA_ROWLEY@UK.AC.OPEN.ACS.VAX" > > I see there is a promised revision of Plain due this autumn. Whence cometh this information? chris From "malcolm " Tue Aug 13 05:50:15 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26740; Tue, 13 Aug 91 05:49:16 MDT Message-Id: <9108131149.AA26740@math.utah.edu> Received: from mole.pcl.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <9822-0@sun2.nsfnet-relay.ac.uk>; Tue, 13 Aug 1991 12:35:50 +0100 Date: Tue, 13 Aug 91 12:37 GMT From: malcolm To: TEX-ARCHIVE <@nsfnet-relay.ac.uk:TEX-ARCHIVE@MATH.UTAH.edu> Subject: RE: (19) preloaded fonts in Plain.tex barbara mentioned it. presumably to fix the bug that phil found. m From "malcolm " Tue Aug 13 05:50:15 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26740; Tue, 13 Aug 91 05:49:16 MDT Message-Id: <9108131149.AA26740@math.utah.edu> Received: from mole.pcl.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <9822-0@sun2.nsfnet-relay.ac.uk>; Tue, 13 Aug 1991 12:35:50 +0100 Date: Tue, 13 Aug 91 12:37 GMT From: malcolm To: TEX-ARCHIVE <@nsfnet-relay.ac.uk:TEX-ARCHIVE@MATH.UTAH.edu> Subject: RE: (19) preloaded fonts in Plain.tex barbara mentioned it. presumably to fix the bug that phil found. m From "George D. Greenwade " Thu Aug 22 07:14:09 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00545; Thu, 22 Aug 91 07:13:18 MDT Received: by SHSU.edu (MX V2.3-1) id 26014; Wed, 21 Aug 1991 17:45:04 CDT Date: Wed, 21 Aug 1991 17:45:04 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094D767.43DAE780.26014@SHSU.edu> Subject: Another dimension of NEWSLETTER -- QUOTE.STY and ITALIC.STY Ought ot pass this along, as well. The auxilliary files of the NEWSLETTER package (QUOTE.TEX and ITALIC.STY) which convert "text to be quoted" into ``text to be quoted'' and automatically make the italic correction (\/) on changing fonts can be used as LaTeX style files for this purpose. The files are also included in the STYle directory. To retrieve these, include the commands: SENDME STY.QUOTE SENDME STY.ITALIC in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu) and you will be able to get them. Also, as is commonly known but worth repeating, everything available on FILESERV is available for anonymous ftp retrieval from Niord.SHSU.edu (192.92.115.8). NEWSLETTER is in the directory [.NEWSLETTER] and the two style files are in the directory [.STY]. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "George D. Greenwade " Thu Aug 22 07:14:09 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00545; Thu, 22 Aug 91 07:13:18 MDT Received: by SHSU.edu (MX V2.3-1) id 26014; Wed, 21 Aug 1991 17:45:04 CDT Date: Wed, 21 Aug 1991 17:45:04 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094D767.43DAE780.26014@SHSU.edu> Subject: Another dimension of NEWSLETTER -- QUOTE.STY and ITALIC.STY Ought ot pass this along, as well. The auxilliary files of the NEWSLETTER package (QUOTE.TEX and ITALIC.STY) which convert "text to be quoted" into ``text to be quoted'' and automatically make the italic correction (\/) on changing fonts can be used as LaTeX style files for this purpose. The files are also included in the STYle directory. To retrieve these, include the commands: SENDME STY.QUOTE SENDME STY.ITALIC in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu) and you will be able to get them. Also, as is commonly known but worth repeating, everything available on FILESERV is available for anonymous ftp retrieval from Niord.SHSU.edu (192.92.115.8). NEWSLETTER is in the directory [.NEWSLETTER] and the two style files are in the directory [.STY]. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "George D. Greenwade " Thu Aug 22 07:18:50 1991 Flags: 000000000401 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00552; Thu, 22 Aug 91 07:16:24 MDT Received: by SHSU.edu (MX V2.3-1) id 26008; Wed, 21 Aug 1991 17:38:25 CDT Date: Wed, 21 Aug 1991 17:38:25 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094D766.55343D20.26008@SHSU.edu> Subject: NEWSLETTER in TeX files available at FILESERV Hunter Goatley sent me his macros, samples, and auxilliary files for producing a newsletter in TeX. Below is the result of a DIRECTORY NEWSLETTER command sent to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). Thanks are extended to Hunter for contributing these files. George ============================================================================== NEWSLETTER ---------- The NEWSLETTER package includes Hunter Goatley's macros to produce newsletters in plain TeX. Most of the macros are original, but some came from _The TeXbook_ and other sources; most of these have been either rewritten or modified. The format is for plain TeX, and supports usual newsletter designs, such as multiple columns (1--6 columns), switching columns on the same page, and including figures. Additionally, the package includes a file which converts "text to be quoted" into ``text to be quoted'' (QUOTE.TEX) and a file which automatically makes the italic correction (\/) when switching among fonts (ITALIC.TEX). Hunter has also established a discussion list for for support and exchange by users of this package, NEWSLETR@WKUVX1.BITNET. Instructions for subscribing to this list are included in the file AAAREAD.ME. You may retrieve the entire package of 9 files by including the command: SENDME NEWSLETTER in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). A complete distribution of this version of NEWSLETTER requires all 9 files in this package, so this command is suggested. If, for some reason, you should only need one of these files, say NEWSLETTER.QUOTE_TEX, include the command: SENDME NEWSLETTER.QUOTE_TEX in your MAIL message to FILESERV. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- NEWSLETTER.AAAREAD_ME 8 AAAREAD.ME NEWSLETTER.ITALIC_TEX 3 ITALIC.TEX NEWSLETTER.LODRIVER_TEX 3 LODRIVER.TEX NEWSLETTER.LOSAMPLE_TEX 29 LOSAMPLE.TEX NEWSLETTER.NEWSLETR_TEX 115 NEWSLETR.TEX NEWSLETTER.NEWSLETR_TXT 14 NEWSLETR.TXT NEWSLETTER.NEWSSAMP_TEX 23 NEWSSAMP.TEX NEWSLETTER.NEWSSAMP_UUE 35 NEWSSAMP.UUE NEWSLETTER.QUOTE_TEX 10 QUOTE.TEX Approximate total blocks in full NEWSLETTER package = 240 From "George D. Greenwade " Thu Aug 22 07:18:50 1991 Flags: 000000000401 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00552; Thu, 22 Aug 91 07:16:24 MDT Received: by SHSU.edu (MX V2.3-1) id 26008; Wed, 21 Aug 1991 17:38:25 CDT Date: Wed, 21 Aug 1991 17:38:25 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu Message-Id: <0094D766.55343D20.26008@SHSU.edu> Subject: NEWSLETTER in TeX files available at FILESERV Hunter Goatley sent me his macros, samples, and auxilliary files for producing a newsletter in TeX. Below is the result of a DIRECTORY NEWSLETTER command sent to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). Thanks are extended to Hunter for contributing these files. George ============================================================================== NEWSLETTER ---------- The NEWSLETTER package includes Hunter Goatley's macros to produce newsletters in plain TeX. Most of the macros are original, but some came from _The TeXbook_ and other sources; most of these have been either rewritten or modified. The format is for plain TeX, and supports usual newsletter designs, such as multiple columns (1--6 columns), switching columns on the same page, and including figures. Additionally, the package includes a file which converts "text to be quoted" into ``text to be quoted'' (QUOTE.TEX) and a file which automatically makes the italic correction (\/) when switching among fonts (ITALIC.TEX). Hunter has also established a discussion list for for support and exchange by users of this package, NEWSLETR@WKUVX1.BITNET. Instructions for subscribing to this list are included in the file AAAREAD.ME. You may retrieve the entire package of 9 files by including the command: SENDME NEWSLETTER in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). A complete distribution of this version of NEWSLETTER requires all 9 files in this package, so this command is suggested. If, for some reason, you should only need one of these files, say NEWSLETTER.QUOTE_TEX, include the command: SENDME NEWSLETTER.QUOTE_TEX in your MAIL message to FILESERV. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- NEWSLETTER.AAAREAD_ME 8 AAAREAD.ME NEWSLETTER.ITALIC_TEX 3 ITALIC.TEX NEWSLETTER.LODRIVER_TEX 3 LODRIVER.TEX NEWSLETTER.LOSAMPLE_TEX 29 LOSAMPLE.TEX NEWSLETTER.NEWSLETR_TEX 115 NEWSLETR.TEX NEWSLETTER.NEWSLETR_TXT 14 NEWSLETR.TXT NEWSLETTER.NEWSSAMP_TEX 23 NEWSSAMP.TEX NEWSLETTER.NEWSSAMP_UUE 35 NEWSSAMP.UUE NEWSLETTER.QUOTE_TEX 10 QUOTE.TEX Approximate total blocks in full NEWSLETTER package = 240 From "George D. Greenwade " Thu Aug 29 14:36:16 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23845; Thu, 29 Aug 91 14:35:04 MDT Received: by SHSU.edu (MX V2.3-1) id 6481; Thu, 29 Aug 1991 15:33:53 CDT Date: Thu, 29 Aug 1991 15:33:53 CDT From: "George D. Greenwade" To: SASGHG@vm.sas.com Cc: info-tex@SHSU.edu, tex-archive@math.utah.edu, texhax@cs.washington.edu, uktex@TeX.ac.uk Message-Id: <0094DD9E.434454E0.6481@SHSU.edu> Subject: ArabTeX files available at FILESERV Yesterday, I forwarded along a post to INFO-TeX about ArabTeX. I have had a few private inquiries about getting these files (some who had no ftp access, others who had trouble getting ftp access). I have installed the basic files for access on FILESERV, and they are available for anonymous ftp retrieval from Niord.SHSU.edu [192.92.115.8]. I am attaching the main ArabTeX description file which has retrieval instructions, as well as the file lists for the related METAFONT sources required and the style files. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ArabTeX ------- The ArabTeX package includes the preliminary distribution of files for Prof. Klaus Lagally's ArabTeX, a LaTeX extension for high-quality arabic writing. They are designed to work in concert with two other packages available on FILESERV, ArabTeX_STYLE (the style files used by ArabTeX), and ArabTeX_MF (the METAFONT sources to produce the NASH10 fonts used by ArabTeX). For sites with ftp access, the pre-built NASH10 fonts (pk and tfm files) are available from Niord.SHSU.edu [192.92.115.8] in the directory [.ARABTEX.NASH10]. The home ftp site for this package is ifi.informatik.uni-stuttgart.de [129.69.211.1]. You may retrieve the entire package of 5 files by including the command: SENDME ArabTeX in the body of a mail message to to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). A complete distribution of this version of ArabTeX requires all of the files in the ArabTeX and ArabTeX_STYLE packages, as well as either the ArabTeX_MF files or the prebuilt fonts. If, for some reason, you should only need one of these files, say ArabTeX.TEX, use the command: SENDME ArabTeX.TEX in your MAIL message to FILESERV. To retrieve ArabTeX_MF and ArabTeX_STYLE, include the commands: SENDME ArabTeX_MF SENDME ArabTeX_STYLE Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- ARABTEX.MAN 9 ARABTEX.MAN ARABTEX.READ_ME 4 READ.ME ARABTEX.SULTAN_PS 125 SULTAN.PS ARABTEX.SULTAN_TEX 8 SULTAN.TEX ARABTEX.TEX 15 ARABTEX.TEX Approximate total blocks in full ArabTeX package = 161 =============================================================================== Files in ArabTeX_MF (retrieve with SENDME ArabTeX_MF): Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- ARABTEX_MF.NASH10_MF 1 NASH10.MF ARABTEX_MF.NASH12_MF 1 NASH12.MF ARABTEX_MF.NASH14_MF 1 NASH14.MF ARABTEX_MF.NASH17_MF 1 NASH17.MF ARABTEX_MF.NASH20_MF 1 NASH20.MF ARABTEX_MF.NASH25_MF 1 NASH25.MF ARABTEX_MF.NASH72_MF 1 NASH72.MF ARABTEX_MF.NASHBASE_MF 17 NASHBASE.MF ARABTEX_MF.NASHCHAR_MF 31 NASHCHAR.MF ARABTEX_MF.NASHCODE_MF 3 NASHCODE.MF ARABTEX_MF.NASHDIA_MF 4 NASHDIA.MF ARABTEX_MF.NASHDIG_MF 4 NASHDIG.MF ARABTEX_MF.NASHFONT_MF 2 NASHFONT.MF ARABTEX_MF.NASHLIG_MF 9 NASHLIG.MF ARABTEX_MF.NASHSPEC_MF 9 NASHSPEC.MF ARABTEX_MF.NASH_MF 3 NASH.MF ARABTEX_MF.READ_ME 3 READ.ME Approximate total blocks in full ArabTeX_MF package = 92 =============================================================================== Files in ArabTeX_STYLE (retrieve with SENDME ArabTeX_STYLE): Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- ARABTEX_STYLE.AFONTS_STY 3 AFONTS.STY ARABTEX_STYLE.APARSE_STY 23 APARSE.STY ARABTEX_STYLE.ARABTEX_STY 16 ARABTEX.STY ARABTEX_STYLE.ASCAN_STY 6 ASCAN.STY ARABTEX_STYLE.ATRANS_STY 7 ATRANS.STY ARABTEX_STYLE.AWRITE_STY 19 AWRITE.STY ARABTEX_STYLE.READ_ME 2 READ.ME Approximate total blocks in full ArabTeX_STYLE package = 76 From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Thu Sep 12 02:33:33 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12360; Thu, 12 Sep 91 02:32:10 MDT Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/5.9.91 ) id AA01680; Thu, 12 Sep 91 10:30:22 +0200 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA01076; Thu, 12 Sep 91 10:30:21 +0200 Date: Thu, 12 Sep 91 10:30:21 +0200 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9109120830.AA01076@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA08157; Thu, 12 Sep 91 10:29:35 +0200 Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: DHOSEK@HMCVAX.CLAREMONT.EDU Cc: svb@cs.purdue.edu, tex-archive@science.utah.edu In-Reply-To: Don Hosek's message of Mon, 9 Sep 1991 22:14 PDT <01GAE6R2BFXG9JD3MQ@HMCVAX.CLAREMONT.EDU> Subject: FWD from Stephan v. Bechtolsheim regarding TeX in Practice files From: svb@cs.purdue.edu (Stephan Bechtolsheim) Don Hosek argues against using zoo or a similar packing program. All this is fine as long as text files are transferred via ftp. In all other cases, i.e. binary files and/or mail transfer you need something to organize things. Fact: a considerable amount of mail transfers of plain text/TeX files suffers from character code mistranslation. This may not be true for the U.S., but for the rest of the world. Fact: binary file transfer between machines with different concepts of file structure is next to impossible. I proposed zoo since it is the only program that can record directory structures AND is running on every widely used platform. If there are problems with this, then let's tackle them. I'm sure the author of zoo is willing to include support for record structure. Rainer From amgreene@ATHENA.MIT.EDU Thu Sep 12 09:06:20 1991 Flags: 000000000001 Return-Path: Received: from pit-manager.MIT.EDU ([18.72.1.58]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14544; Thu, 12 Sep 91 08:13:46 MDT From: amgreene@ATHENA.MIT.EDU Received: by pit-manager.MIT.EDU (5.61/2.1JIK) id ; Thu, 12 Sep 91 10:11:20 -0400 Date: Thu, 12 Sep 91 10:11:20 -0400 Message-Id: <9109121411.AA26447@pit-manager.MIT.EDU> To: schoepf@sc.ZIB-Berlin.DE Cc: DHOSEK@HMCVAX.CLAREMONT.EDU, svb@cs.purdue.edu, tex-archive@csc-sun.math.utah.edu In-Reply-To: Rainer Schoepf's message of Thu, 12 Sep 91 10:30:21 +0200 <9109120830.AA01076@sc.zib-berlin.dbp.de> Subject: FWD from Stephan v. Bechtolsheim regarding TeX in Practice files From: svb@cs.purdue.edu (Stephan Bechtolsheim) Another consideration against mailing straight-text TeX files is the case of lines that begin with a dot. I have had TeX code munged in this way, by mailers that treat any line beginning with a dot by either doubling that dot or simply terminating the transmission at that point. (Pun intended.) - Andrew From "Wayne G. Sullivan " Thu Sep 12 11:46:24 1991 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15827; Thu, 12 Sep 91 11:45:16 MDT Received: from IRLEARN.UCD.IE (MAILER@IRLEARN) by CC.UTAH.EDU with PMDF#10043; Thu, 12 Sep 1991 03:58 MST Received: from IRLEARN.UCD.IE (WSULIVAN) by IRLEARN.UCD.IE (Mailer R2.08) with BSMTP id 2580; Thu, 12 Sep 91 10:17:34 GMT Date: Thu, 12 Sep 91 09:49:41 GMT From: "Wayne G. Sullivan" Subject: file-archives To: tex-archive@science.utah.edu Message-Id: <3D68F99926021A15@CC.UTAH.EDU> X-Envelope-To: tex-archive@science.utah.edu Don Hosek recommends against using a file-archiving program for text files because of the different ways in which systems handle test files. None the less, it would be extremely convenient to be able to request a collection of files, e.g., the Sauter parameterization files, as a single file-archive. It seems that ZOO is the best candidate for a file-archiving program which can work under many of the current operating systems. I have seen reports on an upgrade of ZOO whose compression is comparable with the best currently available -- I do not yet have this version though. Why not use this version of ZOO as the basis for a standard file-archive program for use with TeX? Files like TFM, DVI and VF could be archived "as-is", except that minimal "padding" should be used: upon decoding each operating system could add padding bytes as necessary. Text files need to be standardized. First, if there are any noxious end-of-file bytes, these should be extirpated. Next one needs an end-of-line marker. Though it is not my preference, in deference to UNIX, why not agree upon ASCII 10? Finally, it would be worthwhile to remove all trailing blanks preceding end-of-line, so that equivalent TeX text files will have exactly the same number of bytes. The above requires quite minor manipulations plus ZOO file-archiving. There are other problems: file names, directory structure and encoding for transmission by mail. File names and directory structures are beyond simple solutions. For text encoding, please forget UUENCODE. XXENCODE is far better and someday the promises of VVENCODE may be fulfilled perhaps by yet a different program. From amgreene@ATHENA.MIT.EDU Thu Sep 12 15:26:28 1991 Flags: 000000000001 Return-Path: Received: from pit-manager.MIT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA17594; Thu, 12 Sep 91 15:25:20 MDT From: amgreene@ATHENA.MIT.EDU Received: by pit-manager.MIT.EDU (5.61/2.1JIK) id ; Thu, 12 Sep 91 17:25:02 -0400 Date: Thu, 12 Sep 91 17:25:02 -0400 Message-Id: <9109122125.AA29049@pit-manager.MIT.EDU> To: WSULIVAN@IRLEARN.UCD.IE Cc: tex-archive@csc-sun.math.utah.edu In-Reply-To: "Wayne G. Sullivan"'s message of Thu, 12 Sep 91 09:49:41 GMT <3D68F99926021A15@CC.UTAH.EDU> Subject: file-archives Date: Thu, 12 Sep 91 09:49:41 GMT From: "Wayne G. Sullivan" Next one needs an end-of-line marker. Though it is not my preference, in deference to UNIX, why not agree upon ASCII 10? Although both of the OSs that I use (Unix and AmigaDOS) use LF to terminate lines, I wonder if we should go with CR (13), since that's what TeX is "used to." A LF is converted automagically to a CR on being read in through the mouth of Unix TeX, so perhaps there is an argument in favor of using CR. In any event, there are enough conversion tools that either one should be no difficulty. Finally, it would be worthwhile to remove all trailing blanks preceding end-of-line, so that equivalent TeX text files will have exactly the same number of bytes. Um, not all trailing blanks preceding end-of-line are insignificant, although cases where the aren't are rare. I don't see the advantage of doing this (while you're at it, are you going to expand HT (8)?) The above requires quite minor manipulations plus ZOO file-archiving. There are other problems: file names, directory structure and encoding for transmission by mail. File names and directory structures are beyond simple solutions. If we use ZOO, then these issues have been addressed, have they not? If we develop our own standard, then we can require three names for any file (6+3, 8+3, 127-case-sensitive), and assume a non-flat file system and a regexp to convert from one to another. - Andrew From "bbeeton " Fri Sep 13 08:36:03 1991 Flags: 000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24045; Fri, 13 Sep 91 08:35:25 MDT Date: Fri 13 Sep 91 10:15:33-EST From: bbeeton Subject: Re: file-archives To: amgreene@ATHENA.MIT.EDU Cc: WSULIVAN@IRLEARN.UCD.IE, tex-archive@csc-sun.math.utah.edu Message-Id: <684771333.0.BNB@MATH.AMS.COM> In-Reply-To: <9109122125.AA29049@pit-manager.MIT.EDU> Mail-System-Version: andrew greene suggests using a (13) to indicate an end-of-line. please -- no! unless on a vms system it is converted in unpacking to (13 10), tex will treat the bare (^^M) the same as a % and ignore everything that follows until it *really* detects end-of-line (i.e. ). this has been documented in warnings in tugboat and discussed by tex-implementors some time ago. since our first recognition of this problem at ams was the result of someone calling to our attention missing text in a published journal, you will please excuse my paranoia. -- bb ------- From amgreene@ATHENA.MIT.EDU Fri Sep 13 08:58:07 1991 Flags: 000000000001 Return-Path: Received: from pit-manager.MIT.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24125; Fri, 13 Sep 91 08:57:25 MDT From: amgreene@ATHENA.MIT.EDU Received: by pit-manager.MIT.EDU (5.61/2.1JIK) id ; Fri, 13 Sep 91 10:57:08 -0400 Date: Fri, 13 Sep 91 10:57:08 -0400 Message-Id: <9109131457.AA16593@pit-manager.MIT.EDU> To: BNB@MATH.AMS.COM Cc: WSULIVAN@IRLEARN.UCD.IE, tex-archive@csc-sun.math.utah.edu In-Reply-To: bbeeton's message of Fri 13 Sep 91 10:15:33-EST <684771333.0.BNB@MATH.AMS.COM> Subject: file-archives Having been properly chastened, I withdraw my earlier suggestions. :-) Although I never meant to suggest that we leave stuff as CRs, but rather have the unpacker treat the CR as a "gee, what is this system's EOL indicator," I recognize Barbara's paranoia as well-founded and withdraw the suggestion. (Besides, using LF makes less work for me :-) - Andrew From "Peter Flynn UCC " Fri Sep 13 09:14:45 1991 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24314; Fri, 13 Sep 91 09:13:36 MDT Received: from IRUCCIBM.BITNET (MAILER@IRUCCIBM) by CC.UTAH.EDU with PMDF#10043; Fri, 13 Sep 1991 09:13 MST Received: from IRUCCVAX.UCC.IE (CBTS8001) by IRUCCIBM.BITNET (Mailer R2.08) with BSMTP id 9763; Fri, 13 Sep 91 16:11:51 IST Received: from IRUCCVAX.UCC.IE by IRUCCVAX.UCC.IE (PMDF #12095) id <01GAJF9OQ3OK000IGY@IRUCCVAX.UCC.IE>; Fri, 13 Sep 1991 16:12 GMT Date: Fri, 13 Sep 1991 16:12 GMT From: Peter Flynn UCC Subject: Re: file-archives To: BNB@MATH.AMS.COM Cc: tex-archive@csc-sun.math.utah.edu Message-Id: <01GAJF9OQ3OK000IGY@IRUCCVAX.UCC.IE> X-Envelope-To: tex-archive@csc-sun.math.utah.EDU X-Vms-To: IN%"BNB@MATH.AMS.COM" X-Vms-Cc: IN%"tex-archive@csc-sun.math.utah.edu" I agree completely with barb on the crlf issue. I know one or other of them is redundant on some systems (un*x, mac), but the canonical sequence has been for more years than I care to remember. BTW, we hacked for several hours once to find why a user's .tex file was gagging TeX. Turned out he was preparing the text in MultiMate (blecch) whcih claims to 'export ASCII files', but in reality terminated every line with instead of . I leave it as an exercise to the reader to determine the events when it hit two or more blank lines (hehe, this one should go to TUGboat, I guess...barb?) ///Peter From "George D. Greenwade " Fri Sep 13 12:01:03 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25392; Fri, 13 Sep 91 12:00:16 MDT Received: by SHSU.edu (MX V2.3-1) id 30088; Fri, 13 Sep 1991 13:00:07 CDT Date: Fri, 13 Sep 1991 13:00:07 CDT From: "George D. Greenwade" To: tex-archive@math.utah.edu Message-Id: <0094E952.43B802E0.30088@SHSU.edu> Subject: Mittelbach ftnright.bbl file available Rainer's distribution of Mittelbach's ftnright package was inadvertantly missing the file "ftnright.bbl" (as pointed out by one of the FILESERV users). Ron Whitney at the AMS found a copy of the file, which I forwarded to Rainer, which he forwarded to Frank, which was corrected slightly,...... The file is now available for those of you wanting to retrieve it. Rainer was to put this up at rusmv1.rus.uni-stuttgart.de in its package (I haven't verified this, but trust it has been done). Also, it is available from FILESERV@SHSU.BITNET (FILESERV@SHSU.edu) by including the command: SENDME FTNRIGHT.BBL in the body of a mail message. It is available for anonymous ftp retrieval >From Niord.SHSU.edu (192.92.115.8) in the directory [.FTNRIGHT]. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "Arthur Ogawa " Sat Sep 14 14:53:59 1991 Flags: 000000000001 Return-Path: Received: from orion.arc.nasa.gov by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03711; Sat, 14 Sep 91 14:52:53 MDT Received: Sat, 14 Sep 91 13:53:49 -0700 by orion.arc.nasa.gov (5.64/1.2) Date: Sat, 14 Sep 91 13:53:49 -0700 From: "Arthur Ogawa" Message-Id: <9109142053.AA08154@orion.arc.nasa.gov> To: BNB@MATH.AMS.COM Cc: tex-archive@csc-sun.math.utah.edu In-Reply-To: bbeeton's message of Fri 13 Sep 91 10:15:33-EST <684771333.0.BNB@MATH.AMS.COM> Subject: file-archives Your write: | unless on a vms system it is converted in unpacking to (13 10), | tex will treat the bare (^^M) the same as a % and ignore | everything that follows until it *really* detects end-of-line | (i.e. ). this has been documented in warnings in tugboat | and discussed by tex-implementors some time ago. since our first On Macintosh, the bare _IS_ the record mark, so this problem does not occur here. On DOS, I believe I remember that TeX's response would depend on the implementation: PTI would treat the as a character in its own right, since it was not immediately followed by . I think a Unix system would do the same. However, I didn't remember that the `bare cr' was interpreted as the comment character (this would depend, of course on the catcode assigned to 13). Assuming this really happened, how did this come about? Note: I am not aware of Zoo for Macintosh. Pointers? Discxlaimer: I am not here advocating actually using the as a record mark. Arthur Ogawa Internet: ogawa@orion.arc.nasa.gov Ph: 1/415/691-1126 TeX consultant AppleLink: ogawa FAX:1/415/962-1969 From carlip@oucsace.cs.ohiou.edu Sat Sep 14 15:12:08 1991 Flags: 000000000001 Received: from oucsace.cs.OhioU.Edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03784; Sat, 14 Sep 91 15:11:35 MDT Return-Path: carlip@oucsace.cs.ohiou.edu Received: from localhost.cs.ohiou.edu by oucsace.cs.OhioU.Edu (5.64/2.890722) id AA14965; Sat, 14 Sep 91 17:11:18 -0400 Message-Id: <9109142111.AA14965@oucsace.cs.OhioU.Edu> To: "Arthur Ogawa" Cc: tex-archive@csc-sun.math.utah.edu Subject: Re: Macintosh Zoo In-Reply-To: Your message of "Sat, 14 Sep 91 13:53:49 PDT." <9109142053.AA08154@orion.arc.nasa.gov> Date: Sat, 14 Sep 91 17:11:17 -0400 From: carlip@oucsace.cs.ohiou.edu > Note: I am not aware of Zoo for Macintosh. Pointers? This has recently been discussed on USENET in comp.sys.mac.wanted. Here is a semi-definitive answer (thanks to Bill Johnson): > Great question! The bad news is that it doesn't exist yet, but it is > a PERFECT opportunity for a c programmer who is looking for a way to > learn Mac programming and become a net.hero at the same time! > > There is a .zoo extractor for the Macintosh; it's called MacBooz v.2.1 > and it was written by Michael Niehaus (who also did the CTB IBM 3270 > terminal emulator cterm). The "2.1" here is just a coincidence, > unfortunately. MacBooz will extract files archived with the old > ".zoo" but it won't handle the new .zoo archives created with the > high compression option of zoo 2.10. > > -- Bill (johnston@minnie.me.udel.edu) --Walter Carlip _____________________________________________________________________________ Walter Carlip **** carlip@ace.cs.ohiou.edu **** (the "3" is invisible) **** oztex@midway.uchicago.edu **** _____________________________________________________________________________ From "bbeeton " Sat Sep 14 16:38:25 1991 Flags: 000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04089; Sat, 14 Sep 91 16:37:42 MDT Date: Sat 14 Sep 91 18:39:38-EST From: bbeeton Subject: Re: file-archives To: ogawa@orion.arc.nasa.gov Cc: tex-archive@csc-sun.math.utah.edu Message-Id: <684887978.0.BNB@MATH.AMS.COM> In-Reply-To: <9109142053.AA08154@orion.arc.nasa.gov> Mail-System-Version: the answer is on page 343 of the texbook: the \catcode for ^M is 5 = end-of-line. however, the choice of what really is an end-of-line character is very system-dependent, and particular implementations must do different things on this account. in tugboat 9 #2 (pp 182-183) i included everything that i could determine about the subject in a warning; this included commentary >From both don knuth and dave fuchs. the tugboat file is a bit longer than i really want to post to this list, but i'll be happy to send a copy to anyone who asks. -- bb ------- From "George D. Greenwade " Thu Sep 26 15:43:11 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00949; Thu, 26 Sep 91 15:40:22 MDT Received: by SHSU.edu (MX V2.3-1) id 24288; Thu, 26 Sep 1991 16:06:37 CDT Date: Thu, 26 Sep 1991 16:06:37 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu, TeXhax@cs.washington.edu Message-Id: <0094F3A3.7A56BA20.24288@SHSU.edu> Subject: New version of SHADOW.STY available on FILESERV Mauro Orlandini , who is the author of shadow.sty (creates "shadowed" \fbox'es) forwarded me a fix (dated 10 May 1991) to the style so it can now work within a \twocolumn environment. The updated file may be retrieved by including the command: SENDME STY.SHADOW in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). General information on FILESERV can be retrieved by including the command HELP in the body of your mail message. This file is also available for anonymous ftp retrieval from Niord.SHSU.edu (192.92.115.8) in the [.STY] directory. Thanks are extended to Mauro (who just joined INFO-TeX today!) for contributing this file update. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "George D. Greenwade " Fri Sep 27 14:16:57 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09992; Fri, 27 Sep 91 14:15:15 MDT Received: by SHSU.edu (MX V2.3-1) id 25826; Fri, 27 Sep 1991 07:58:06 CDT Date: Fri, 27 Sep 1991 07:58:06 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu, TeXhax@cs.washington.edu Cc: UKTeX@TeX.ac.uk, tex-archive@math.utah.edu Message-Id: <0094F428.644CC8C0.25826@SHSU.edu> Subject: SPFONTWARE updates available at FILESERV Norman Walsh has provided me with updates for the files in the SPFONTWARE package (MergeSFP, SFPtoPK, PKtoSFP) for converting Hewlett-packard softfonts to and from TeX PK/TFM formats. Attached is Norm's announcement, as well as FILESERV's description of this package. For users who have previously retrieved the files in this package, please note that Norm's address has changed from to: Norman Walsh #42I Southwood Apartments Brittany Manor Drive Amherst, MA 01002 Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% PKtoSFP version 1.4 Over the past few weeks, I've made several modifications to PKtoSFP and SFPtoPK. At this time, I would like to announce new releases of these programs. Here is a summary of the modifications, in brief: PKtoSFP - Added support for creating accented characters in the output softfont. PKtoSFP can accent any character in the input font with any other character. Accents can be above or below the accented character. A character set file appropriate for producing softfonts with the Roman-8 symbol set is provided. I have only had time to construct a character set file for the Roman-8 symbol set, if you create character set files for other symbol sets, please send them to me and I will include them in the next release. These changes are very recent and I have not "pounded on" the new code as much as I would like to. I've decided to release it as it is rather than wait until I have enough time to test it in great detail. If anyone has any difficulty, I will do my best to correct it immediately. - Fixed the bug that caused a run-time error when converting the TeX math fonts. The math fonts have a space factor of zero and this was an unanticipated condition. PKtoSFP now uses the quad space factor if the space factor is zero. (if the quad space is zero, it uses 1/4 of the design size). SFPtoPK, MergeSFP - Changes in the way that I/O is performed have dramatically improved performance when reading softfonts that can fit entirely in memory. The generalized softfont I/O routines that I use take a very liberal view of what constitutes a valid softfont and this generality creates a certain amount of overhead; for softfonts small enough to be read entirely into available memory (and less than 64kb) this overhead has been removed. norm 09/27/1991 =========================================================================== SPFONTWARE ---------- The SPFONTWARE package includes three UUENCODEd ZIP files for Norm Walsh's (walsh@cs.umass.edu) utilities to convert Hewlett-Packard softfonts to *and* from TeX PK/TFM format (Version 1.4; as of September 23, 1991). All of these files are for MS-DOS platforms. The file SPFONTWARE.SPFtoPK_UUE converts HP LaserJet softfont files into TeX fonts. This file is distributed in four parts which need to be concatenated together prior to UUDECODEing. Features of SPFtoPK in brief: - Converts softfonts directly into PK files (allowing up to 256 chars/font) - Option to move characters from anywhere in the softfont to standard TeX positions (this is especially useful for ligatures and accents). - Option to automatically build ligatures into the TeX font - Supports a flexible kerning algorithm - Options for ``stealing'' accents off of accented characters -- even baseline accents like the cydil - Similar option for stripping accents *off* of characters -- useful to produce the undotted i's and j's if nothing else. - Can dynamically adjust the size of an interword space - Can dynamically adjust the x-height - Can calculate the appropriate slant value for most fonts - Handles compressed (PCL4/5) softfont files - Handles scaled fonts (i.e, cmr10 scaled \magstep5) - Changes in the way that I/O is performed have dramatically improved performance when reading softfonts that can fit entirely in memory. - Complete documentation provided in a DVI file The file SPFONTWARE.PKtoSFP_UUE converts TeX fonts into LaserJet softfont files. This file is distributed in two parts which need to be concatenated together prior to UUDECODEing. Features of PKtoSFP in brief: - Converts directly from PK files (allowing up to 256 characters/font) - Added support for creating accented characters in the output softfont. PKtoSFP can accent any character in the input font with any other character. - Handles the \L slash character at position '040 in the TeX font (so your softfont doesn't have a non-blank space) - Handles scaled fonts (i.e, cmr10 scaled \magstep5) - Fixed the bug that caused a run-time error when converting the TeX math fonts. - Complete documentation provided in a DVI file The file SPFONTWARE.MergeSFP_UUE combines multiple HP softfont files into a single softfont. This file is distributed in two parts which need to be concatenated together prior to UUDECODEing. Features of MergeSFP in brief: - Many options for defining the output softfont - Handles compressed (PCL4/5) softfonts - Changes in the way that I/O is performed have dramatically improved performance when reading softfonts that can fit entirely in memory. - Complete documentation provided in a DVI file To retrieve the entire set of three files, please include the command SENDME SPFONTWARE in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). To retrieve a specific file from this distribution, say SPFONTWARE.MergeSFP_UUE_1OFF2, include the command: SENDME SPFONTWARE.MergeSFP_UUE_1OF2 For all files in a single file, such as SPFONTWARE.SFPtoPK_UUE, include the command: SENDME SPFONTWARE.SFPtoPK* in the body of the mail message to FILESERV. Unencoded copies of the ZIP files as well as the ZIP files themselves are available for anonymous ftp retrieval from Niord.SHSU.edu (192.92.115.8) in the directory [.SPFONTWARE]. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: UUDECODEs to: ------------------------------------------------------------------------------- SPFONTWARE.MergeSFP_UUE_1OF2 53 MergeSFP.UUE MergeSFP.ZIP SPFONTWARE.MergeSFP_UUE_2OF2 53 concatenate to part 1 SPFONTWARE.PKtoSFP_UUE_1OF2 79 PKtoSFP.UUE PKtoSFP.ZIP SPFONTWARE.PKtoSFP_UUE_2OF2 79 concatenate to part 1 SPFONTWARE.SFPtoPK_UUE_1OF4 79 SFPtoPK.UUE SFPtoPK.ZIP SPFONTWARE.SFPtoPK_UUE_2OF4 79 concatenate between parts 1 and 3 SPFONTWARE.SFPtoPK_UUE_3OF4 79 concatenate between parts 2 and 4 SPFONTWARE.SFPtoPK_UUE_4OF4 79 concatenate to part 3 Approximate total blocks in full SPFONTWARE package = 580 From "George D. Greenwade " Sun Sep 29 15:48:10 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04710; Sun, 29 Sep 91 15:45:00 MDT Received: by SHSU.edu (MX V2.3-1) id 31040; Sun, 29 Sep 1991 16:44:59 CDT Date: Sun, 29 Sep 1991 16:44:59 CDT From: "George D. Greenwade" To: tex-archive@math.utah.edu Message-Id: <0094F604.538E16A0.31040@SHSU.edu> Subject: SFPtoPK.ZIP fixed on Niord To everyone who has ftp'ed the file SFPtoPK.ZIP in the [.SPFONTWARE] directory on Niord.SUSU.edu (192.92.115.8) prior to this post: Yes, the file has a problem and, yes, it won't unzip. Norm Walsh has fixed the file and it is now available for retrieval. My sincerest apologies for any inconvenience this may have caused. If anyone comes across any other problem children, please bring it to my attention so it, too, can be fixed as expeditiously as possible. My thanks are extended to Norm, who quickly figured out the problem and got the new file to me for installation (what are we doing working on a weekend?). Regards and apologies, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "mike@inrs-telecom.uquebec.ca (Mike Ferguson)" Fri Oct 4 06:38:01 1991 Flags: 000000000001 Return-Path: Received: from VIDEO.INRS-TELECOM.UQUEBEC.CA ([192.26.211.64]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25642; Fri, 4 Oct 91 06:37:17 MDT Received: from vimy.INRS-Telecom.UQuebec.CA by VIDEO.INRS-TELECOM.UQUEBEC.CA with SMTP; Fri, 4 Oct 1991 8:36:42 -0400 (EDT) Received: by vimy.INRS-Telecom.UQuebec.CA (5.57/Ultrix3.0-C) id AA03093; Fri, 4 Oct 91 08:36:31 -0400 From: mike@inrs-telecom.uquebec.ca (Mike Ferguson) Message-Id: <9110041236.AA03093@vimy.INRS-Telecom.UQuebec.CA> Subject: INRSTeX available via FTP To: info-tex@shsu.bitnet, tex-archive@math.utah.edu Date: Fri, 4 Oct 91 8:36:31 EDT X-Mailer: ELM [version 2.3 PL0] I am making the INRSTeX document preparation package available over the network. There is both a unix and a pc version available. These differ only in the way they handle auxiliary files and graphics. It is available from aldebaran.insl.mcgill.ca /pub/inrstex/pc directory for the pc and /pub/inrstex/unix for the unix version. A short description of the package follows: ---------------------------------------------------------------------- Michael Ferguson -- Aug. 1991 mike@inrs-telecom.uquebec.ca (514)765-7834 INRSTeX is a complete document preparation package, including graphics for document preparation. It was designed from the beginning for use in a bilingual (French/English) environement. The system, excluding its graphics component, is usable with any TeX system but is most useful, when using ordinary "cm" fonts with an MLTeX system. TeXGraph will work with any reasonable PostScript driver ans has been specialized here to work with a modified modified version of Nelson~Beebe's DVIALW on the IBM~PC and uses Tom~Rokiki's DVIPS on the UNIX workstations. The PC Version of the package includes an MSDOS version of the modified DVIALW. The INRSTeX macro package kernel is built on top of PLAIN. All the facilties of plain are left intact and available. Additional facilities are included for * section and chapter heads, * lists, * easy tables, * floating figure and table insertions, * footnotes, * automatic generation of table of contents, list of figures, and list of tables, * automatic numbering of equations, section heads, etc., * symbolic referencing of equations, sections, etc., * optional margin notes to aid in keeping track of symbolic references, * automatic generation of citation lists (IEEE style only) * a subdocument feature for building large documents in pieces. * a verbatim style using {\tt typewriter} fonts for such things as program listings, * a several document styles including a paperstyle and bookstyle. * TeXgraph, a graphics system for drawing figures and inserting external figures. This uses the graphics primitives of PostScript. It is inside rather than outside the TeX system. * slide making including graphics for letterhead, ---------------------------------------------------------- From "George D. Greenwade " Tue Oct 8 13:30:32 1991 Flags: 000000000001 Return-Path: Received: from odin.shsu.edu ([192.92.115.4]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00742; Tue, 8 Oct 91 13:26:03 MDT Received: by SHSU.edu (MX V2.3-1) id 22276; Tue, 08 Oct 1991 13:53:30 CDT Date: Tue, 08 Oct 1991 13:53:30 CDT From: "George D. Greenwade" To: info-tex@SHSU.edu, texhax@cs.washington.edu, tex-archive@math.utah.edu Cc: TeX@RMCS.Cranfield.ac.uk Message-Id: <0094FCFE.DDE2D420.22276@SHSU.edu> Subject: DVILN03 version 4.1 on FILESERV Brian {Hamilton Kelly} kindly passed along his new release (version 4.1) of the DVILN03 package. I have retained the VMS backup saveset as he sent it to me for your retrieval. For mail users of FILESERV, the file has been MFTU encoded, then VMS_SHAREd into 102 50-block files. Upon executing the VMS_SHARE file, you will have the MFTU encoded backup saveset (DVILN03.BCK_MFT). A file is provided (00BUILD_SAVESET.COM) which will MFTU decode the file into DVILN03.BCK, a complete backup saveset, as built by Brian. You can retrieve the package by including the command: SENDME DVILN03 in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). If you do not already have MFTU (Mail File Transfer Utility; provided in Macro32 code and easily built), include the command: SENDME MFTU in the body of your message to FILESERV. If you are unfamiliar with FILESERV, you may also want to include the command HELP in the body of your message for an overview of the commands, syntax, and use of FILESERV. For those of you with ftp access (by far preferred simply due to the sheer size of this transfer), the file is available as a backup saveset from Niord.SHSU.edu (192.92.115.8) in the directory [.DVILN03.FTP] as DVILN03.BCK. Effective immediately, the DVItoLN03 package (version 4.0) is no longer available from FILESERV nor from Niord. DVILN03 (version 4.1) is now the supported package. Below is the file 00README.TXT from the saveset. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% DVItoLN03 Version 4.1 1st October 1991 ========= =========== ================ Changes in the V4.1 release are the introduction of two new qualifiers: /[NO]VERBOSE - the default for this may be set up at a site as either state; with /NOVERBOSE, most terminal output is suppressed, apart from the name of the input file, the total bytes of down- loaded fonts, and progress indication as each page is output. /PAPER_SIZE - the default for this should reflect the setting of the paper size selection switch on the rear of the machine. The program requires knowledge of the physical paper size to handle pages which mix landscape and portrait orientation material. This distribution contains the following files: 00README.TXT - the file you are reading Files for building the program: DVITOLN03.CH - a change file for DVItoLN03, for revising V4.0 of the Web to V4.1 DVITOLN03.CLD - VMS command language definition for the DVILN03 command DVITOLN03.EXE - a ``load-and-go'' executable, for VMS V5.4-2 DVITOLN03.OBJ - object code, for linking uder different versions of VMS DVITOLN03.WEB - the WEB source of DVItoLN03 (V4.0) Files for generating the documentation: CHANGEBAR.STY - for those without this: style option for changes DVILN03.HLP - on-line (DCL) help for DVItoLN03 DVILN03.LN3_PUBLISH - file ready to be COPYed to your LN03 DVILN03.TEX_PUBLISH - the ``local guide'' for DVItoLN03 (in LaTeX) LOCAL_GUIDES.BIB - a BibTeX database used at RMCS --- needs BibTeX V0.99c GRAPHICS.STY - a local LaTeX style file for graphics inserts OPENCLOSE.SIX - a Sixel dump of the screen of a terminal, scaled 2:1 OPENCLOSE.SMALL - the same dump, but scaled 1:1 TEXPRINT.COM - command procedure implementing the TEXPrint command (Note that LOCAL.MF is no longer included; better collections of mode_defs have been published, and are available from good archives everywhere.) DVILN03.HLP is a standard (DCL) help file, for inclusion in SYS$HELP:HELPLIB.HLB or your local specialized help library. ******************************************************************************** * This bit is IMPORTANT: many of the reports that the author receives that * * ``DVItoLN03 doesn't work properly'' are because the sites have not set up * * the LN03 device correctly. The only place this is specified is in the user * * manual, and if your printer isn't already set up correctly, it won't PRINT * * unless you send it with PRINT/PASSALL. And even then, it won't come out * * correctly if the DIPswitch on the printer is set to AutoWrap! * ******************************************************************************** You should produce a copy of our local guide. If your LN03 is not spooled, then simply COPY the file DVILN03.LN3_PUBLISH directly to YOUR LN03. Please note that this file includes LOTS of eight-bit characters, so you may need to fetch it again in binary mode if your FTP connection has stripped off the 8th bit. If your LN03 is set up as a printer queue (as the local guide recommends), the safest bet is to PRINT it /PASSALL until you've found out how to set up the queue compatibly; one important caveat is that the terminal line MUST be set up /NOWRAP (see the local guide). Everything is explained, I hope, in the local guide. As supplied, DVILN03.TEX_PUBLISH assumes that you have a working copy of the previous version (V3.1-1 or later) of DVItoLN03, but it does not use any of the special facilities provided by this new release. If you are currently using a different driver, you will have to modify the line at the start of DVILN03.TEX_PUBLISH that reads > \let\iffulldoc=\iftrue %%% Change to \iffalse if you don't have DVItoLN03 to say instead > \let\iffulldoc=\iffalse %%% Change to \iffalse if you don't have DVItoLN03 and then LaTeX it and pass through your existing driver. The guide should be edited to suit YOUR site; I have attempted to flag all site-specific details in DVILN03.TEX with the string SYSDEP, on, or near to, the relevant line(s). Ensure that you define the macros \sitename and \contact; all queries at any site should be channelled through the latter individual, and if he/she cannot resolve them, then I shall be delighted to (attempt to) help. However, the real meat is in DVITOLN03.WEB; this is a WEB version of a DVI-to... driver for the DEC LN03/LN03-Plus laser printers. This program has been revised to V4.0 and is now capable or reading EITHER packed or expanded raster files, virtual fonts, missing fonts (!), landscape/portrait orientation (mixed on one page, even!). It also supports the DEClaser~2100 and~2200 (otherwise known as the LN05 and LN06). Packed (.nnnPK) files are used in preference to .PXL files (if both are available), and are sought in directory given by the /PK_FONT_DIRECTORY qualifier; the .CLD file provided specifies this as TEX_PK:. PXL files are sought in the directory given by the /PXL_FONT_DIRECTORY qualifier, and, at RMCS, are kept in separate subdirectories of TEX_PXL_ROOT:, which is a concealed device specified as the value for this qualifier. Details are given in the user guide, including rearranging the allocation of font files to different directory structures. The program no longer looks in TEX$FONTS: for .TFM files, but instead in whatever is defined as the default for the /TFM_DIRECTORY qualifier; this allows TeX administrators to abandon use of logical names with dollars in them, as recommended by Digital. This implementation of DVItoLN03 has the following advantages over certain other DVItoLN03 programs (these are not in order of importance; the new features are at the end of the list): i) It IS written in WEB, as opposed to C and other such kludgy languages. ii) It downloads to the LN03's font memory the rasters for only those characters actually used in the document. As such, it does not run out of font memory just because you've used a few characters from each of a large number of different fonts. iii) It HAS a capacity for SIMPLE graphics inclusions. These have to be in a format the LN03 understands (DEC sixels), and are copied verbatim into the output file generated. iv) It works in landscape and portrait orientations. v) It makes use of the ``proper'' VAX/VMS DCL interface for commands. vi) It CAN print glyphs whose rasters are too large to be downloaded to the LN03 as a font file (by performing a sixel graphics dump of the bitmap); obviously this slows things down considerably! vii) It CAN handle the invisible fonts used by SliTeX; each such character is actually downloaded as a null character locator, ans is imaged by the appropriate amount of whitespace. viii) Either packed or unpacked font files (or both) may be provided in either flat or rooted directory structures; if logical names are used to specify these locations (as in the .CLD file provided), the files may be spread over a number of different directories or volumes. ix) The error messages are improved over earlier versions of the program, and are now all indexed in the woven (WEAVEd?) WEB. They are also all listed in the users' manual. x) The program can now handle fonts with more then 128 characters, up to TeX's limit of 256. Therefore, it can now process documents which use Silvio Levy's Greek fonts. xi) Retention of the log (.TYP) file may now be forced, suppressed, or allowed to be determined by the success of the processing. xii) Minor revisions and corrections have been made, in particular, it now correctly understands the physical limitations to the imaging area. xiii) Correct some log reports; report files read (except font files); provide the /OUTPUT qualifier, to permit utilization of a scratch directory or direct spooling to the output device. xiv) Support for Flavio Rose \special commands, for drawing changebars, was added by Robin Fairbairns at Laser Scan of Cambridge, UK. xv) TeX Font Metrics (TFM files) are no longer sought in the hard-wired directory TEX$FONTS:, but are instead controlled through the /TFM_DIRECTORY qualifier. xvi) Support for Virtual Fonts; the .VF files are sought in whatever is specified as the value of the /VIRTUAL_DIRECTORY qualifier; users can speed processing fractionally by specifying /NOVIRTUAL_DIRECTORY if it is known that no virtual fonts are used in the document. If virtual fonts are never used at your site, make this the default. xvii) Fonts for which the program cannot find any rasters no longer cause the processing to be abandoned; solid rules of appropriate dimensions are subsituted for each missing glyph. xviii)Landscape and portrait mode material may be mixed within a document, and even on a single page, through \special{landscape} and \special{portrait}. However, some suitable style option still needs to be written to make this feature useful. xix) Qualifiers /LEFT_MARGIN and /TOP_MARGIN now take a dimension (eg 1in) rather than being required to be entered in pixels; the additional called PX (pixel) has been added to TeX's normal set. xx) Support for the new DEClaser 2100 and 2200 printers has been provided by Karsten Nyblad of the Danish Telecomms Research Lab. Users can select the paper source tray, separately for the first and subsequent sheets, and also the printing mode (simplex or duplex). There is even a duplex mode for the ordinary LN03 (no, it doesn't really print two-sided) which, by interspersing blank sheets at appropriate points, produces a single-sided master suitable for photocopying directly to a double-sided document. xxi) Last, but definitely not least, the program has been speeded up, in both the font mapping and the imaging phases, so that overall it runs approximately 25% faster than V3.1-4. The program assumes that the LN03 has sufficient font memory --- for most meaningful documents you will need at least one RAM cartidge (part number LN03X-CR); the program WILL work with just the RAM in the basic printer, but you will probably have to restrict yourself to printing documents 3--4 pages at a time: very messy! Not having one personally, I don't know what memory requirements apply to the new DEClaser printers. Known deficiencies: none (I hope). Possible future work: Make the program accept binary files (DVI, TFM and fonts) that are not in the default organization used by TeXware under VMS (512-byte fixed- length records). This would make importing such files from other operating systems, such as Unix or MS-DOS, easier, since at present such files have to be padded out to some multiple of 512 bytes, and moreover with some appropriate characters, which differs from file to file. Any other suggestions??? Contact ======= If anyone is experiencing difficulty in installing DVItoLN03, they are welcome to contact the author --- B Hamilton Kelly Royal Military College of Science Shrivenham SWINDON UK SN6 8LA Swindon (++44 793) 785252 [Direct line] or via JANET: tex@uk.ac.cranfield.rmcs INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk Bitnet: tex@rmcs.cranfield.ac.uk Good Luck! Brian HAMILTON KELLY From "mike@inrs-telecom.uquebec.ca (Mike Ferguson)" Wed Oct 9 10:22:40 1991 Flags: 000000000001 Return-Path: Received: from VIDEO.INRS-TELECOM.UQUEBEC.CA by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09175; Wed, 9 Oct 91 10:19:28 MDT Received: from vimy.INRS-Telecom.UQuebec.CA by VIDEO.INRS-TELECOM.UQUEBEC.CA with SMTP; Wed, 9 Oct 1991 12:19:17 -0400 (EDT) Received: by vimy.INRS-Telecom.UQuebec.CA (5.57/Ultrix3.0-C) id AA10229; Wed, 9 Oct 91 12:18:47 -0400 From: mike@inrs-telecom.uquebec.ca (Mike Ferguson) Message-Id: <9110091618.AA10229@vimy.INRS-Telecom.UQuebec.CA> Subject: MLTeX Change files via FTP To: info-tex@shsu.bitnet (Info TeX), tex-archive@math.utah.edu (TeX Archive) Date: Wed, 9 Oct 91 12:18:45 EDT X-Mailer: ELM [version 2.3 PL0] Michael J. Ferguson Return Address: mike@inrs-telecom.uquebec.ca ----- Oct. 1991 ---- I am making the change files for MLTeX available on aldebaran.insl.mcgill ca 132.206.94.5 They are in the directories /pub/mltex -------------------------------------- MLTeX is modification of TeX 3.+ that allows hyphenation of words with accented letters using ordinary "cm" fonts. It does this by translating TeX's internal code, following the TeX EC standard, into an equivalent just before the character is sent out to the .dvi file. These modifications have been called, internally "charsubdef". In order to use it, you must merge the char_sub.ch file with the appropriate change file for your port. This char_sub.ch change file is essentially system independent. -------------------------------------- The files included in both mltex.zip and mltex.tar.Z are as follows: 1. char_sub.doc -- \charsubdef documentation 2. char_sub.ch -- change file for \charsubdef --- modified May 1991 -- missing characters in sub list. 3. extdef.tex -- an essentially ISO-Latin 1 definition of \charsubdef ... including \uccodes (Mar 91) 4. compatible.tex -- a set of macros to translate accent sequences into internal 8 bit codes. This set also includes inverses for the characters. 5. masthyph.tex -- a master hyphenation control file that allows pattern files with accented letters to be input with the accented letters given by TeX's backslash codes eg \'e for ... 6. frhyph.tex -- a (the?) French hyphenation file illustrating the \.. coding in the patterns. 7. ctex_csb.ch -- The Unix change file for converting TeX 3.14 to Big MLTeX Yours, Michael Ferguson =============================================================================== From "George D. Greenwade " Tue Oct 29 10:44:28 1991 Flags: 000000000001 Return-Path: Received: from odin.shsu.edu ([192.92.115.4]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01054; Tue, 29 Oct 91 10:40:15 MST Received: by SHSU.edu (MX V2.3-1) id 906; Tue, 29 Oct 1991 11:37:38 CST Date: Tue, 29 Oct 1991 11:37:38 CST From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: texhax@cs.washington.edu, tex-archive@math.utah.edu Message-Id: <00950D6C.5E1744A0.906@SHSU.edu> Subject: MIDNIGHT Macros available on FILESERV Marcel van der Goot kindly notified me of his updated Midnight macros set, which have been placed on FILESERV and are available from Niord. The home server for these is csvax.cs.caltech.edu [131.215.131.131], in the directory pub/tex/Midnight (with a midnight.tar.Z in pub/tex). Below is the description file for this package. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MIDNIGHT -------- The MIDNIGHT package includes the 15 files of Marcel van der Goot's Midnight Macros. The Midnight Macros provide a rather diverse set of macros. Some are useful in general applications (e.g., loop.tex); some can be used to write other macros (e.g., dolines.tex); and some are intended for very specific typesetting problems (e.g., labels.tex). What they have in common is (somewhat) the style of programming, applicability in a variety of situations (e.g., through parametrization), and, maybe most important, a user manual. The files come in pairs: xxx.tex is the file you should \input to use the macros; xxx.doc is a TeX file that describes how to use them. A list of the available files with one line descriptions can be found in the Index file. You may retrieve the entire package of 15 files by including the command: SENDME MIDNIGHT in the body of a mail mesasge to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). A complete distribution of this version of MIDNIGHT requires all 15 files in this package, so this command is suggested. If, for some reason, you should only need one of these files, say MIDNIGHT.INDEX, use the command: SENDME MIDNIGHT.INDEX in your message to FILESERV. For users with anonymous ftp facilities, these files are available from Niord.SHSU.edu (192.92.115.8) in the directory [.MIDNIGHT]; a compressed tar file of this package is available in the directory [.MIDNIGHT.FTP]. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- MIDNIGHT.BORDER_DOC 33 BORDER.DOC MIDNIGHT.BORDER_TEX 23 BORDER.TEX MIDNIGHT.DOLINES_DOC 27 DOLINES.DOC MIDNIGHT.DOLINES_TEX 12 DOLINES.TEX MIDNIGHT.GLOSS_DOC 24 GLOSS.DOC MIDNIGHT.GLOSS_TEX 9 GLOSS.TEX MIDNIGHT.INDEX 2 INDEX MIDNIGHT.LABELS_DOC 21 LABELS.DOC MIDNIGHT.LABELS_TEX 24 LABELS.TEX MIDNIGHT.LOOP_DOC 13 LOOP.DOC MIDNIGHT.LOOP_TEX 7 LOOP.TEX MIDNIGHT.QUIRE_DOC 44 QUIRE.DOC MIDNIGHT.QUIRE_TEX 37 QUIRE.TEX MIDNIGHT.STYLEDEF_DOC 28 STYLEDEF.DOC MIDNIGHT.STYLEDEF_TEX 16 STYLEDEF.TEX Approximate total blocks in full MIDNIGHT package = 320 From "George D. Greenwade " Wed Oct 30 11:56:55 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11901; Wed, 30 Oct 91 11:55:06 MST Received: by SHSU.edu (MX V2.3-1) id 4825; Wed, 30 Oct 1991 12:10:13 CST Date: Wed, 30 Oct 1991 12:10:13 CST From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: texhax@cs.washington.edu, tex-archive@math.utah.edu, uktex@tex.ac.uk Message-Id: <00950E3A.154ABF80.4825@SHSU.edu> Subject: ADDRESS files available at FILESERV Jackie Damrau kindly forwarded me a share file of the paper and related macros she and Michael Wester presented at the last TUG meeting. This is a very nice package for handling mailing labels and personalized form letters! Below is the description file. If you would like a brief primer on using FILESERV, please include the command HELP in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ADDRESS ------- The ADDRESS package includes the macro files and presentation paper of Jackie Damrau and Michael Wester's ADDRESS macro set. From the abstract of the paper ("Form Letters with 3-Across Labels Capability" presented at the 1991 TUG meetings in Dedham, MA): [ADDRESS presents] a general-purpose program for generating form letters, using either TeX or LaTeX. Given three inputs: a preamble file for initializations, a list of blank separated addresses, and a letter template, this program can be used to generate a letter per address and provide personalizations as directed by the template. Sample applications are presented, including one which constructs 3-across mailing labels. Thus, both form letters and mailing labels can be generated from the same list of addresses by simply changing two inputs to the program. You may retrieve the entire package of 10 files by including the command: SENDME ADDRESS in the body of a mail mesasge to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). A complete distribution of the ADDRESS macro set requires all 10 files in this package, so this command is suggested. If, for some reason, you should only need one of these files, say ADDRESS.README, use the command: SENDME ADDRESS.README in your message to FILESERV. For users with anonymous ftp facilities, these files are available from Niord.SHSU.edu (192.92.115.8) in the directory [.ADDRESS]; a single file of the complete package is available in the directory [.ADDRESS.FTP] as ADDRESS.SHAR. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: ------------------------------------------------------------------------------- ADDRESS.3ACROSS_TEX 1 3ACROSS.TEX ADDRESS.3PRE_TEX 1 3PRE.TEX ADDRESS.ADDRESS_TEX 40 ADDRESS.TEX ADDRESS.ENVELOPE_TEX 1 ENVELOPE.TEX ADDRESS.ENVPRE_TEX 1 ENVPRE.TEX ADDRESS.EXAMPLE_TEX 2 EXAMPLE.TEX ADDRESS.LETTER_TEX 5 LETTER.TEX ADDRESS.PAPER_TEX 54 PAPER.TEX ADDRESS.PREAMBLE_TEX 2 PREAMBLE.TEX ADDRESS.README 3 README Approximate total blocks in full ADDRESS package = 110 From "karl@cs.umb.edu (Karl Berry)" Sat Nov 2 14:50:44 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10023; Sat, 2 Nov 91 14:49:14 MST Received: from claude.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA07338; Sat, 2 Nov 91 16:47:24 EST Received: by claude.cs.umb.edu (4.1/1.34) id AA08571; Sat, 2 Nov 91 16:43:53 EST Date: Sat, 2 Nov 91 16:43:53 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9111022143.AA08571@claude.cs.umb.edu> To: info-tex@shsu.BITNET, tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Subject: modes.mf version 0.8 released I have released version 0.8 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/modes.mf You can also get it by email from George Greenwade's (thanks, George!) file server if you cannot ftp: mail fileserv@shsu.edu with a body of `sendme modes'. It is about 42K. This file is a collection of Metafont mode_def's (probably close to all of them in existence). It also makes common definitions for write-white printers and `special' information. This version has several changes: * new modes (for IBM, Epson, and other devices) * better values for the SparcPrinter, Printware 720IQ devices * CanonSX is no longer claimed to be write-white * mode_setup can be safely called more than once for write-white devices If you have mode_def's which are not listed below, or corrections to the existing ones, please send them to me. In particular, I would also appreciate getting definitive information on the Linotronic printers. (Notes in the file reflect the current state of confusion.) karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga mode_def AtariSLMEightZeroFour = % Atari ST SLM 804 printer mode_def AtariSMOneTwoFour = % Atari ST SM 124 screen mode_def aps = % Autologic APS-Micro5 mode_def ApsSixHi = % Autologic APS-Micro6 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def boise = % HP 2680A mode_def CanonCX = % Canon CX, SX, LBP-LX mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CItohEightFiveOneZero = % CItoh 8510A mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def dover = % Xerox Dover mode_def epsonlo = % Epson at 120dpi mode_def EpsonLQFiveZeroZeroMed = % Epson LQ-500, 360x180dpi mode_def EpsonLQFiveZeroZeroLo = % Epson LQ-500, 180x180dpi mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def GThreefax = % 200 x 100dpi G3fax mode_def HPDeskJet = % HP DeskJet 500 mode_def IBMD = % IBM 38xx mode_def IBMFourTwoFiveZero = % IBM 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMProPrinter = % IBM ProPrinter mode_def IBMSixOneFiveFour = % IBM 6154 display mode_def IBMSixSixSevenZero = % IBM 6670 (Sherpa) mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMEGA = % IBM VGA monitor mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetlo = % HP LaserJet at 150dpi mode_def LASevenFive = % DEC LA75 mode_def LinotypeOneZeroZeroLo = % Linotype Linotronic [13]00 at 635dpi mode_def LinotypeOneZeroZero = % Linotype Linotronic [13]00 at 1270dpi mode_def LinotypeThreeZeroZeroHi = % Linotype Linotronic 300 at 2540dpi mode_def LNZeroOne = % DEC LN01 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NEC = % NEC mode_def NEChi = % NEC-P6 at 360x360dpi mode_def Newgen = % Newgen 400dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def OCESixSevenFiveZeroPS = % OCE 6750PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def qms = % QMS (Xerox engine) mode_def RicohFourZeroEightZero = % e.g., the TI Omnilaser mode_def RicohLP = % e.g., the DEC LN03 mode_def SparcPrinter = % Sun SPARCprinter mode_def StarNLOneZero = % Star NL-10 mode_def sun = % Sun and BBN Bitgraph at 85dpi mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX, EpsonLQ mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperFiveZeroSixZeroW = % Varitype 5060W mode_def VarityperFourTwoZeroZero = % Varityper Phototypesetter 4200 B-P mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxEightSevenNineZero = % Xerox 8790 or 4045 mode_def XeroxFourZeroFiveZero = % Xerox 4050 mode_def XeroxNineSevenZeroZero = % Xerox 9700 mode_def XeroxThreeSevenZeroZero = % Xerox 3700 mode_def help = % What modes are defined? From "kuku@acds.physik.rwth-aachen.de (Christoph Kukulies)" Sun Nov 3 12:18:31 1991 Flags: 000000000001 Return-Path: Received: from acds.physik.rwth-aachen.de ([134.130.31.30]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15044; Sun, 3 Nov 91 12:18:25 MST Received: by acds.physik.rwth-aachen.de (5.57/Ultrix3.0-C) id AA18747; Sun, 3 Nov 91 20:16:11 GMT Date: Sun, 3 Nov 91 20:16:11 GMT From: kuku@acds.physik.rwth-aachen.de (Christoph Kukulies) Message-Id: <9111032016.AA18747@acds.physik.rwth-aachen.de> To: info-tex@shsu.edu, karl@cs.umb.edu, tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Subject: Re: modes.mf version 0.8 released A question from the MF-neophyte: What is mode_def useful for? Does the mundane user need to have it? --Chris From "Mail Delivery Subsystem " Sun Nov 3 12:27:37 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB15046; Sun, 3 Nov 91 12:18:25 MST Date: Sun, 3 Nov 91 12:18:25 MST From: Mail Delivery Subsystem Subject: Returned mail: Host unknown Message-Id: <9111031918.AB15046@math.utah.edu> To: owner-tex-archive To: owner-tex-fonts ----- Transcript of session follows ----- 421 Host columbiasc.ncr.com not found for mailer tcp. 550 gary.beihl@columbiasc.ncr.com... Host unknown 421 afsc-bmo.af.mil: Host AFSC-BMO.AF.MIL is down, will keep trying for 3 days 421 iruccvax.ucc.ie: Connection refused by cunyvm.cuny.edu, will keep trying for 3 days 421 prime.cob.ohio-state.edu: Host prime.cob.ohio-state.edu is down, will keep trying for 3 days Connected to ics.uci.edu: >>> MAIL From: <<< 451 Nameserver timeout during parsing 421 cunyvm.cuny.edu: Connection refused by cunyvm.cuny.edu, will keep trying for 3 days ----- Unsent message follows ----- Return-Path: Received: from acds.physik.rwth-aachen.de ([134.130.31.30]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA15044; Sun, 3 Nov 91 12:18:25 MST Errors-To: beebe Received: by acds.physik.rwth-aachen.de (5.57/Ultrix3.0-C) id AA18747; Sun, 3 Nov 91 20:16:11 GMT Date: Sun, 3 Nov 91 20:16:11 GMT From: kuku@acds.physik.rwth-aachen.de (Christoph Kukulies) Message-Id: <9111032016.AA18747@acds.physik.rwth-aachen.de> To: info-tex@shsu.edu, karl@cs.umb.edu, tex-archive@math.utah.edu, tex-fonts@math.utah.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Subject: Re: modes.mf version 0.8 released A question from the MF-neophyte: What is mode_def useful for? Does the mundane user need to have it? --Chris From "Ralph Youngen " Wed Nov 6 13:08:58 1991 Flags: 000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14177; Wed, 6 Nov 91 13:05:07 MST Date: Wed 6 Nov 91 15:06:14-EST From: Ralph Youngen Subject: AMSFonts for Textures posted to e-MATH To: tex-archive@math.utah.edu, info-tex@shsu.bitnet, texhax@cs.washington.edu, UKTeX%uk.ac.tex@nsfnet-relay.ac.uk Cc: REY@MATH.AMS.COM Message-Id: <689457974.0.REY@MATH.AMS.COM> Mail-System-Version: In response to several requests, we have posted the Macintosh version of the AMSFonts for use with Textures to e-MATH.ams.com. These fonts are stored as as BinHex'd StuffIt archives in the directory /ams/macintosh. For convenience, the AMS-LaTeX 1.1 and AMS-TeX 2.1 distributions are also stored in this same manner in the same directory. As always, please let us know if anyone finds problems with any of these files. Thanks. Ralph Youngen Technical Support Manager American Mathematical Society Internet: REY@MATH.AMS.COM ------- From "karl@cs.umb.edu (Karl Berry)" Wed Nov 13 11:52:25 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04434; Wed, 13 Nov 91 11:49:26 MST Received: from claude.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA25103; Wed, 13 Nov 91 13:47:13 EST Received: by claude.cs.umb.edu (4.1/1.34) id AA22154; Wed, 13 Nov 91 13:47:10 EST Date: Wed, 13 Nov 91 13:47:10 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9111131847.AA22154@claude.cs.umb.edu> To: tex-archive@math.utah.edu Cc: opbibtex@neon.stanford.edu, raymond@math.berkeley.edu Subject: version numbers and locations; texhax Reply-To: karl@cs.umb.edu I just got this note: Date: Mon, 11 Nov 91 07:16:43 -0800 From: Oren Patashnik Subject: TeXhax I think that the current version number for btxmac.tex should probably be listed along with the other version numbers (every tenth issue of TeXhax). Do you agree, or do you think it would look funny to have btxmac listed but not Eplain (is it appropriate to list Eplain there)? ... This reminded me that (I think) Raymond Chen is stopping maintenance of his ftp list as of 1/1. I think this kind of directory is extremely important to keep up-to-date and available. I don't think ``every tenth issue'' of Texhax has enough space or is frequent enough to be very useful. Do others agree? If so, and if Raymond doesn't find another volunteer, and no one here can volunteer (perhaps I will; I haven't decided if I can yet), then perhaps we should suggest that TUG spend some of its hard-won resources on this. Also, on the subject of texhax, I'm unsure how valuable the erratically-published digest format is, now that George Greenwade has established info-tex. Perhaps TUG and the U. of Washington could divert texhax resources elsewhere, and texhax could be an alias for info-tex. Thoughts? karl@cs.umb.edu From "karl@cs.umb.edu (Karl Berry)" Wed Nov 13 13:09:59 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04956; Wed, 13 Nov 91 13:07:09 MST Received: from claude.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA27154; Wed, 13 Nov 91 15:05:11 EST Received: by claude.cs.umb.edu (4.1/1.34) id AA22201; Wed, 13 Nov 91 15:05:07 EST Date: Wed, 13 Nov 91 15:05:07 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9111132005.AA22201@claude.cs.umb.edu> To: tex-archive@math.utah.edu Subject: [raymond@math.berkeley.edu: Re: version numbers and locations; texhax; TeX supplement maintenance] Reply-To: karl@cs.umb.edu I guess we don't need to worry about the ftp list. I'd still appreciate thoughts on my idea of making texhax == info-tex. Date: Wed, 13 Nov 91 10:57:01 PST From: raymond@math.berkeley.edu (Raymond Chen) To: karl@cs.umb.edu Subject: Re: version numbers and locations; texhax; TeX supplement maintenance I already have a volunteer to take over on 1/1 lined up, so I hope that the Supplement will continue to be kept up-to-date after my retirement >From the effort. The December edition will contain more information. From "Arthur Ogawa " Wed Nov 13 15:30:03 1991 Flags: 000000000001 Return-Path: Received: from orion.arc.nasa.gov by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05898; Wed, 13 Nov 91 15:28:30 MST Received: Wed, 13 Nov 91 14:39:20 -0800 by orion.arc.nasa.gov (5.64/1.2) Date: Wed, 13 Nov 91 14:39:20 -0800 From: "Arthur Ogawa" Message-Id: <9111132239.AA05924@orion.arc.nasa.gov> To: karl@cs.umb.edu Cc: tex-archive@math.utah.edu, info-tex@SHSU.edu In-Reply-To: Karl Berry's message of Wed, 13 Nov 91 13:47:10 EST <9111131847.AA22154@claude.cs.umb.edu> Subject: texhax Karl writes: > Also, on the subject of texhax, I'm unsure how valuable the > erratically-published digest format is, now that George Greenwade has > established info-tex. Perhaps TUG and the U. of Washington could divert > texhax resources elsewhere, and texhax could be an alias for info-tex. > Thoughts? My feeling is that texhax has always seemed a bit out-of-date, most issues having been fairly settled by the time the digest appears in my mailbox. However, the digest had served as a reference or repository of useful problems/solutions, and I woulld look it over on an FYI basis. Urgent problems seem to be solved more promptly via info-tex. The existence of an archive of info-tex satisfies the function of a texhax digest. Therefore I support Karl's suggestion to make texhax be an alias for info-tex. At the same time I would like to encourage working out three technical issues: 1. mailer problems with info-tex such as we experienced over the last 3-4 days. 2. Replies to info-tex queries should by default get cc'd back to info-tex. Or has relying on the poster to summarize to info-tex been effective? 3. Connection between comp.text.tex and info-tex. I know that George has solicited comments about this. What was the upshot? From "bbeeton " Thu Nov 14 09:46:10 1991 Flags: 000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12349; Thu, 14 Nov 91 09:44:21 MST Date: Thu 14 Nov 91 11:45:24-EST From: bbeeton Subject: Re: texhax To: ogawa@orion.arc.nasa.gov Cc: karl@cs.umb.edu, tex-archive@math.utah.edu Message-Id: <690137124.0.BNB@MATH.AMS.COM> In-Reply-To: <9111132239.AA05924@orion.arc.nasa.gov> Mail-System-Version: really, i should let george greenwade answer this, but since he's probably still busy trying to clean up after the recent disaster, i thought a quick response from someone else might allow him a little (well-deserved) rest. i think george's explanation to info-tex on what happened to cause all the bounce-backs was pretty thorough. it was also clear that it's not impossible for the same thing to happen again, owing to the way different mail handlers deal with the headers. i'd like to point out, by the way, that a large part of the reason why texhax is usually late is because the moderator's time is taken up dealing with such mailer and list problems. but since texhax is moderated, all the reader sees is the delay. with info-tex, one sees all the gory detail. you takes your choice. in an earlier time, replies were automatically cc'ed to info-tex. the result was a lot of marginal traffic along with the useful stuff. after a number of subscribers signed off, the auto-cc was removed. not, i think, a really viable option. i think george has determined on the basis of comments that comp.tex.tex will be forwarded to info-tex as soon as some real technical problems are ironed out. (all possibilities for circularity have to be eliminated.) i hope i've got this right, and invite george to correct anything that isn't. -- bb ------- From Thu Nov 14 15:12:40 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14175; Thu, 14 Nov 91 15:07:50 MST Received: by SHSU.edu (MX T2.4-2) id 13353; Thu, 14 Nov 1991 15:36:31 CST Sender: Date: Thu, 14 Nov 1991 15:35:33 CST From: "George D. Greenwade" To: tex-archive@math.utah.edu Cc: info-tex@SHSU.edu Message-Id: <00951A20.40988220.13353@SHSU.edu> Subject: RE: texhax Sorry for the very long post, but I hope it will provide some clarification. Feel free to discuss it on INFO-TeX or privately with me. This all starts on a post of Wed, 13 Nov 91 13:47:10 EST, by Karl Berry to TeX-archive. > This reminded me that (I think) Raymond Chen is stopping maintenance of his > ftp list as of 1/1. I think this kind of directory is extremely important > to keep up-to-date and available. I don't think ``every tenth issue'' of > Texhax has enough space or is frequent enough to be very useful. I like the ``every tewnth issue'' policy simply because it reduces size of the distribution and is adequately periodic. It ought to be somewhere in the FAQ of FAQ Supplement, as well, though. > Do others agree? If so, and if Raymond doesn't find another volunteer, and > no one here can volunteer (perhaps I will; I haven't decided if I can yet), > then perhaps we should suggest that TUG spend some of its hard-won > resources on this. As already pointed out in an earlier post, the replacement victim is already lined up. This is extracted from Raymond's last FAQ Supplement: > On 1 Jan 91, ownership of this file will be transferred to Guoying Chen > (chenguo@spunky.cs.nyu.edu) [no relation]. Now, on to the gory other thoughts. From Karl: > Also, on the subject of texhax, I'm unsure how valuable the > erratically-published digest format is, now that George Greenwade has > established info-tex. Perhaps TUG and the U. of Washington could divert > texhax resources elsewhere, and texhax could be an alias for info-tex. > Thoughts? On Wed, 13 Nov 91 14:39:20 -0800, Arthur Ogawa replied: > My feeling is that texhax has always seemed a bit out-of-date, most issues > having been fairly settled by the time the digest appears in my mailbox. > However, the digest had served as a reference or repository of useful > problems/solutions, and I woulld look it over on an FYI basis. > > Urgent problems seem to be solved more promptly via info-tex. The existence > of an archive of info-tex satisfies the function of a texhax digest. > > Therefore I support Karl's suggestion to make texhax be an alias for > info-tex. > > At the same time I would like to encourage working out three technical > issues: > > 1. mailer problems with info-tex such as we experienced over the last > 3-4 days. > > 2. Replies to info-tex queries should by default get cc'd back to info-tex. > Or has relying on the poster to summarize to info-tex been effective? > > 3. Connection between comp.text.tex and info-tex. I know that George has > solicited comments about this. What was the upshot? On Thu, 14 Nov 91 9:26:15 EST, Walter D. Neumann posted to INFO-TeX: > Please no automatic replies to info-tex. Think of the mass of mail it > would generate. Even if a poster does not summarize replies, it is easy > enough for an interested party to ask the poster directly what (s)he has > found out. Followed on Thu, 14 Nov 91 14:37:54 MEZ, from Peter Schmitt to INFO-TeX: > A few remarks to the discussion on TeXhax: > > (1) certainly discussion is better performed on a list ("live"), but > > (2) a moderated digest has its advantages and uses as well: > it is well suited for - summaries > - announcements > - surveys > and it is much more convenient to review the results of some > discussion, if it has been well edited > > Therefore, I think that TeXhax has its merits and should be continued > --- maybe with a changed and newly formulated editorial policy, > but it should be continued (especially since TeXMaG seems to > have stopped to be published). > [Of course, a clear distinction of purpose between TeXHaX and Info-TeX > --- and possibly others --- would help to use both more efficiently] And, finally, in a Thu 14 Nov 91 11:45:24-EST post to TeX-archive by bbeeton > really, i should let george greenwade answer this, but since he's probably > still busy trying to clean up after the recent disaster, i thought a quick > response from someone else might allow him a little (well-deserved) rest. > > i think george's explanation to info-tex on what happened to cause all the > bounce-backs was pretty thorough. it was also clear that it's not > impossible for the same thing to happen again, owing to the way different > mail handlers deal with the headers. > > i'd like to point out, by the way, that a large part of the reason why > texhax is usually late is because the moderator's time is taken up dealing > with such mailer and list problems. but since texhax is moderated, all the > reader sees is the delay. with info-tex, one sees all the gory detail. > you takes your choice. > > in an earlier time, replies were automatically cc'ed to info-tex. the > result was a lot of marginal traffic along with the useful stuff. after a > number of subscribers signed off, the auto-cc was removed. not, i think, a > really viable option. > > i think george has determined on the basis of comments that comp.tex.tex > will be forwarded to info-tex as soon as some real technical problems are > ironed out. (all possibilities for circularity have to be eliminated.) > > i hope i've got this right, and invite george to correct anything that > isn't. First, I am quite honored by the words of encouragement I have received over the past two days -- thanks to all who have sent their kind thoughts. After dealing with over 4,000 pieces of mail, I am now within the almost nearly to 200-to-go range. Allow me to interject my feelings on this topic (and I am not attempting to stick my beliefs on the list -- the list is here to help everyone and I am only one subscriber). I am going to begin this with an introspective simply to give everyone my perspective on this. The original concept for INFO-TeX goes back to when TEX-L, served by various LISTSERV's worldwide, handled both TeXhax and a somewhat interactive discussion such as we now have on INFO-TeX. One day, the discussion dimension was dropped for no apparent reason. I asked back then, and continually more or less for three years, as to why the dual function no longer existed. To be quite honest, the best response I received from among the many was "if you want something like that, go start your own list." After cajoling our local computer services people about the possibility, I was told if I could find reliable and affordable software to do it, I could. I am forever indebted to our computer services for allowing me, a mere economist, the ability to do what I do on mail. Since we are a VMS site, LISTSERV, per se, does not exist. I was quite fortunate to find Matt Madison's Message Exchange (MX) mailer software for our VMS cluster, a fantastic public domain mailer package, which we now use as the basis of our lists and FILESERV. We are fortunate that Matt (RPI) has listened patiently to our wish list on MX (many functions came from suggestions of INFO-TeX subscribers); this is one reason why we put a heavily-used production site into beta testing -- many of the changes in recent releases of MX have been as a result of suggestions from us on how to serve you better. Barbara Beeton and Max Hailperin were kind enough to allow me to experiment with them as "subscribers" initially (and a few others came on board, as well). Finally, on November 28, 1990, INFO-TeX came to life (yes, it's been almost a year now). Enough introspection. Conceptually, there is a healthy difference between a digest, such as TeXhax, and a discussion list, such as INFO-TeX. The digest function, as I see it, is to consolidate announcements, developments, and summaries of projects -- a very important role indeed! The discussion function, as I see it, is to get help on something *now*. The structure is open and topics can vary to anything a subscriber wishes to add -- indeed, discussion lists exist only because subscribers have something to add. The digest serves as a long-term repository -- just look at the number of sites which have TeXhax in their archives. The discussion serves more in a short term, problem solving capacity. The only aspect of TeXhax which I might suggest for change would be to go to a known periodicity, such as UKTeX Digest's weekly, each Friday or Saturday, model. That, I believe, is a good way to reduce the erraticism Karl implies. As Barbara points out, though, each type of distribution has its problems -- what you see of them is simply of a different variety. Regarding a Reply-To: list -- NO! We tried that for about two weeks and it happened to just come at the time when someone said "post to me for more information." Darned if people didn't reply -- unfortunately to everyone. The practice of using follow-up posts has been basically effective, as I see it, although I would like to see more still. However, the trade-off between losing a few follow-ups and getting misdirected traffic weighs heavily in favor of losing follow-ups. Misdirected traffic is not something we need to support (we just saw that this week and I was just as ticked off about it as you were -- probably more so since it was worldwide information that something I was responsible for was screwed up in a major way). By the way, the one side benefit of the bounces is that it is very probable that someone might be looking into writing an RFC to standardize mail bounces (it's amazing who sees INFO-TeX and comp.text.tex!) -- that would be a major development which would benefit everyone since, in the absence of a standard, it is largely impossible to filter out problems. On the issue of the INFO-TeX archives serving as a good repository. That is my long term wish. However, I can tell you already that without some form of indexation, they really aren't all that great. As I mentioned, we are not a LISTSERV, per se, site, so we do not have the LISTSERV LDBASE functions. I hope that someday soon we will have something more along these lines (or those of Archie or something else altogether) to facilitate archival searches. Even if the software is never employed, simply getting things into a usable form is going to need to be considered sometime soon if the archives are going to be of great use to anyone not located specifically at SHSU (and it is real nice to have them handy). I'm open to suggestions. The comp.text.tex<->INFO-TeX link can go up at any time. I am relatively confident that the technology exists to preclude looping from within "good" messages. We have two of my lists which I co-own, FedTax-L and INFO-TPU, completely linked to USENET's misc.taxes and vmsnet.tpu. So far, I have seen absolutely no problems. The total daily traffic on this combination is around 15-40 per day, so I feel confident that we would have seen a problem by now. Moreover, the USENET site we link to is extraordinaly experienced at providing these services and has no problems I have seen on other lists/newsgroups I know they are associated with. The only drawback to c.t.t<->I-T is that it will mean an increased level of traffic. Approximately 75% of the respondents to my poll about adding c.t.t to I-T said to link with 25% saying leave it alone. One option is to run two lists (one as presently configured; the other fully linked). If the poll is any indication, my guess is that 75% will subscribe and post to the linked list and 25% will stay on the mail-only list. Pure guess now, but traffic on the mail-only list would drop by 75% (reason -- I still have trouble convincing people to post to I-T instead of to c.t.t, even though I-T posts get to c.t.t right now). In other words, traffic would be so small as to not justify the mail-only list. So......... One of the major benefits is that c.t.t would finally have an archival home, but my comments above on their usefulness become even more relevant since we are talking about quite a few more posts. Maybe this would make a good TUG standing committee project. Among the things to be watching for -- under our new version of MX, SET NOMAIL (so you can stay subscribed but turn mail off) is an option to LISTSERV, as are a few other LISTSERV-type functions. Also, a broad expansion of our archives to include Aston's archives as well as TeX.ac.uk's TeXServer software to service it is planned (I hope I'm not speaking out of turn on that as I'm still waiting for Brian {Hamilton Kelly} to get me that software as soon as the upgrade to it is finished; we recently installed the disk space for this, so that major technicality has already been taken care of). In other words, INFO-TeX and SHSU are here to serve in whatever realistic capacity its users wish. I am open to any and all suggestions and look forward to a good future of working with you. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From "JANET CHAA006@UK.AC.RHBNC.VAX " Fri Nov 15 05:16:33 1991 Flags: 000000000001 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20189; Fri, 15 Nov 91 05:12:20 MST Received: from vax.rhbnc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <10720-4@sun2.nsfnet-relay.ac.uk>; Thu, 14 Nov 1991 17:56:34 +0000 Date: Thu, 14 NOV 91 14:19:12 BST From: CHAA006@vax.rhbnc.ac.uk To: TEX-ARCHIVE <@nsfnet-relay.ac.uk:TEX-ARCHIVE@MATH.UTAH.edu> Subject: RE: (59) version numbers and locations; texhax Actually-To: Sender: JANET "CHAA006@UK.AC.RHBNC.VAX" Message-Id: <202046E6_000754C0.00951A1594933B00$23_2@UK.AC.RHBNC.VAX> Reply-To: Philip Taylor (RHBNC) Originally-To: CBS%UK.AC.NSFNET-RELAY::EDU.UMB.CS::KARL,CBS%UK.AC.NSFNET-RELAY::EDU.UTAH.MATH::TEX-ARCHIVE Mailer: Janet_Mailshr V3.5 ( 13-OCT-1989 14:07:27 ) Karl --- >>> This reminded me that (I think) Raymond Chen is stopping maintenance of >>> his ftp list as of 1/1. I think this kind of directory is extremely >>> important to keep up-to-date and available. I don't think ``every tenth >>> issue'' of Texhax has enough space or is frequent enough to be very >>> useful. >>> Do others agree? If so, and if Raymond doesn't find another volunteer, >>> and no one here can volunteer (perhaps I will; I haven't decided if I >>> can yet), then perhaps we should suggest that TUG spend some of its >>> hard-won resources on this. I don't use the FTP list at all; I don't even know what it is. However, I spend 85% of my time using and supporting TeX, so I feel permitted to suggest that perhaps it's not quite as `important to keep up-to-date and available' as you suggest. However, others may well disagree ... >>> Also, on the subject of texhax, I'm unsure how valuable the >>> erratically-published digest format is, now that George Greenwade has >>> established info-tex. Perhaps TUG and the U. of Washington could divert >>> texhax resources elsewhere, and texhax could be an alias for info-tex. On the other hand, I find TeX-hax invaluable; I wouln't want to see it subsumed into any other list. Philip Taylor ``The University of London at Windsor'' From "karl@cs.umb.edu (Karl Berry)" Wed Dec 4 15:49:39 1991 Flags: 000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00520; Wed, 4 Dec 91 15:48:26 MST Received: from claude.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA21609; Wed, 4 Dec 91 17:48:08 EST Received: by claude.cs.umb.edu (4.1/1.34) id AA00693; Wed, 4 Dec 91 17:48:02 EST Date: Wed, 4 Dec 91 17:48:02 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9112042248.AA00693@claude.cs.umb.edu> To: tex-archive@math.utah.edu, info-tex@shsu.BITNET Subject: modified musictex available Reply-To: karl@cs.umb.edu Many people have asked me for my modifications to Daniel Taupin's musictex for a different system of inputting note pitches. I've put a complete distribution of my modified musictex on ftp.cs.umb.edu [192.12.26.23] in pub/tex/kmusictex.tar.Z. It is really too large to email; if there is enough interest, perhaps someone will make it available from a mail server, but I don't know about such things. Taupin has made additional improvements to musictex since I did my modifications. This distribution does not include those improvements (and in fact, I haven't even looked at them yet). I don't know if I ever will or not. I explicitly do not support this in the way I do Eplain and modes.mf and my font naming scheme and web2c, and just can't answer questions about how to use it; the documentation I wrote for my modifications varies >From sketchy to nonexistent (but the sources and all the scores we've typeset are there). I understand Taupin's latest distribution (from rsovax.circe.fr), includes expanded documentation (in [musictex]notice.tex), so perhaps you will want to get that. The bulk, if not all of it, should still apply. Enjoy. karl@cs.umb.edu Member of the League for Programming Freedom---write to league@prep.ai.mit.edu. From "Piet van Oostrum " Thu Dec 5 01:33:14 1991 Flags: 000000000000 Return-Path: Received: from ruuinf.cs.ruu.nl by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04142; Thu, 5 Dec 91 01:28:27 MST Received: from gnu.cs.ruu.nl by ruuinf.cs.ruu.nl with SMTP (5.61+/IDA-1.2.8) id AA15944; Thu, 5 Dec 91 09:27:37 +0100 Received: by alchemy.cs.ruu.nl (15.11/15.6) id AA10082; Thu, 5 Dec 91 09:27:31 -0100 Date: Thu, 5 Dec 91 09:27:31 -0100 From: Piet van Oostrum Message-Id: <9112050827.AA10082@alchemy.cs.ruu.nl> To: karl@cs.umb.edu Cc: info-tex@shsu.BITNET, tex-archive@math.utah.edu, MUTEX@stolaf.edu Subject: Re: modified musictex available References: <9112042248.AA00693@claude.cs.umb.edu> The copy in our archive includes the newest version of Daniels files and Karl Berrys modifications in a separate subdirectory (together in a compressed tar archive). Karls files have as date aug 19 (that's the date I got them). I don't know if that is his latest version. I haven't tried if Karls modifications will work with the new version of musictex. Our archive is reachable by mail and ftp. How to get musictex.tar.Z from the archive at Dept. of Computer Science, Utrecht University: NOTE: In the following I have assumed your mail address is john@highbrow.edu. Of course you must substitute your own address for this. This should be a valid internet or uucp address. For bitnet users name@host.BITNET usually works. by FTP: (please restrict access to weekends or evening/night (i.e. between about 20.00 and 0900 UTC). ftp archive.cs.ruu.nl [131.211.80.5] user name: anonymous or ftp password: your own email address (e.g. john@highbrow.edu) Don't forget to set binary mode if the file is a tar/arc/zoo archive, compressed or in any other way contains binary data. get TEX/musictex.tar.Z by mail-server: send the following message to mail-server@cs.ruu.nl (or uunet!mcsun!hp4nl!ruuinf!mail-server): begin path john@highbrow.edu (PLEASE SUBSTITUTE *YOUR* ADDRESS) send TEX/musictex.tar.Z end NOTE: *** PLEASE USE VALID INTERNET ADDRESSES IF POSSIBLE. DO NOT USE ADDRESSES WITH ! and @ MIXED !!!! BITNETTERS USE USER@HOST.BITNET *** The path command can be deleted if we receive a valid from address in your message. If this is the first time you use our mail server, we suggest you first issue the request: send HELP -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Tue Dec 17 10:18:23 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07286; Tue, 17 Dec 91 10:03:11 MST Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA04118; Tue, 17 Dec 91 18:01:46 +0100 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA14638; Tue, 17 Dec 91 18:01:43 +0100 Date: Tue, 17 Dec 91 18:01:43 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9112171701.AA14638@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA07311; Tue, 17 Dec 91 18:01:43 +0100 To: tex-archive@math.utah.edu Subject: New LaTeX 2.09 and NFSS releases Reply-To: Schoepf@sc.ZIB-Berlin.DE Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin I have just put the new releases for LaTeX (version 2.09 of Dec 1, 1991) and NFSS onto the Stuttgart and Heidelberg archives. Stuttgart: directories are soft/tex/latex/ and soft/tex/latex-style-supported/nfss Heidelberg: All LaTeX files are in LATEX FILELIST, except the fonts which are in MFSOURCE FILELIST, to retrieve the NFSS files send the command GET FONTSEL PACKAGE to LISTSERV@DHDURZ1.BITNET Rainer Schoepf Konrad-Zuse-Zentrum ,,Ich mag es nicht, wenn fuer Informationstechnik Berlin sich die Dinge so frueh Heilbronner Strasse 10 am Morgen schon so D-1000 Berlin 31 dynamisch entwickeln!'' Federal Republic of Germany or From "schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf)" Tue Dec 17 11:05:56 1991 Flags: 000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07690; Tue, 17 Dec 91 11:00:14 MST Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA04149; Tue, 17 Dec 91 18:58:39 +0100 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA14709; Tue, 17 Dec 91 18:58:37 +0100 Date: Tue, 17 Dec 91 18:58:37 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9112171758.AA14709@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA07401; Tue, 17 Dec 91 18:58:37 +0100 To: tex-archive@math.utah.edu Subject: LaTeX update Reply-To: Schoepf@sc.ZIB-Berlin.DE Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin Concerning the LaTeX update I announced: here are some release note; maybe this should be included in the distribution. --------------------------------------------------------------------- LaTeX version 2.09 -- Release of Dec 1, 1991 -------------------------------------------- This release supercedes ILaTeX which is to disappear. There are some incompatibilities due to bug fixes. For more information see latex.bug. Especially fix #197 (changing the counter in thebibliography) and style changes #56/57 might cause problems. The Metafont source files have also been updated. This does not mean that the shape of the characters were changed, only a few internals like the font identifier for the invisible fonts, and the addition of a check so that the line and circle fonts can no longer be run with cmbase. It should be noted explicitly that ALL files have to be updated: otherwise it will not work. --------------------------------------------------------------------- From "Mail Delivery Subsystem " Tue Dec 17 12:10:38 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB07962; Tue, 17 Dec 91 11:50:52 MST Date: Tue, 17 Dec 91 11:50:52 MST From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <9112171850.AB07962@math.utah.edu> To: beebe ----- Transcript of session follows ----- 421 arbortext.com: Host blue.arbortext.com is down, will keep trying for 2 days, 23 hours Connected to nsfnet-relay.ac.uk: >>> RCPT To: <<< 550 (BHST) Unknown host/domain name in "cczdao <@nsfnet-relay.ac.uk:cczdao@clan.nott.ac.uk>" 550 cczdao%clan.nott.ac.uk@nsfnet-relay.ac.uk... User unknown ----- Unsent message follows ----- Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07690; Tue, 17 Dec 91 11:00:14 MST Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA04149; Tue, 17 Dec 91 18:58:39 +0100 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA14709; Tue, 17 Dec 91 18:58:37 +0100 Date: Tue, 17 Dec 91 18:58:37 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9112171758.AA14709@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA07401; Tue, 17 Dec 91 18:58:37 +0100 To: tex-archive@math.utah.edu Subject: LaTeX update Reply-To: Schoepf@sc.ZIB-Berlin.DE Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin Concerning the LaTeX update I announced: here are some release note; maybe this should be included in the distribution. --------------------------------------------------------------------- LaTeX version 2.09 -- Release of Dec 1, 1991 -------------------------------------------- This release supercedes ILaTeX which is to disappear. There are some incompatibilities due to bug fixes. For more information see latex.bug. Especially fix #197 (changing the counter in thebibliography) and style changes #56/57 might cause problems. The Metafont source files have also been updated. This does not mean that the shape of the characters were changed, only a few internals like the font identifier for the invisible fonts, and the addition of a check so that the line and circle fonts can no longer be run with cmbase. It should be noted explicitly that ALL files have to be updated: otherwise it will not work. --------------------------------------------------------------------- From "Mail Delivery Subsystem " Tue Dec 17 12:11:30 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AC07962; Tue, 17 Dec 91 12:10:39 MST Date: Tue, 17 Dec 91 12:10:39 MST From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <9112171910.AC07962@math.utah.edu> To: beebe ----- Transcript of session follows ----- 421 arbortext.com: Host blue.arbortext.com is down, will keep trying for 2 days, 22 hours Connected to nsfnet-relay.ac.uk: >>> RCPT To: <<< 550 (BHST) Unknown host/domain name in "cczdao <@nsfnet-relay.ac.uk:cczdao@clan.nott.ac.uk>" 550 cczdao%clan.nott.ac.uk@nsfnet-relay.ac.uk... User unknown Connected to infngw.INFN.IT: >>> QUIT <<< 421 Smtp service is not available at the moment. ----- Unsent message follows ----- Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07286; Tue, 17 Dec 91 10:03:11 MST Received: from dagobert.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/7.11.91 ) id AA04118; Tue, 17 Dec 91 18:01:46 +0100 Received: from quattro.ZIB-Berlin.DE by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/31.1.91) id AA14638; Tue, 17 Dec 91 18:01:43 +0100 Date: Tue, 17 Dec 91 18:01:43 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9112171701.AA14638@sc.zib-berlin.dbp.de> Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA07311; Tue, 17 Dec 91 18:01:43 +0100 To: tex-archive@math.utah.edu Subject: New LaTeX 2.09 and NFSS releases Reply-To: Schoepf@sc.ZIB-Berlin.DE Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin I have just put the new releases for LaTeX (version 2.09 of Dec 1, 1991) and NFSS onto the Stuttgart and Heidelberg archives. Stuttgart: directories are soft/tex/latex/ and soft/tex/latex-style-supported/nfss Heidelberg: All LaTeX files are in LATEX FILELIST, except the fonts which are in MFSOURCE FILELIST, to retrieve the NFSS files send the command GET FONTSEL PACKAGE to LISTSERV@DHDURZ1.BITNET Rainer Schoepf Konrad-Zuse-Zentrum ,,Ich mag es nicht, wenn fuer Informationstechnik Berlin sich die Dinge so frueh Heilbronner Strasse 10 am Morgen schon so D-1000 Berlin 31 dynamisch entwickeln!'' Federal Republic of Germany or From Thu Dec 19 15:46:26 1991 Flags: 000000000001 Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24927; Thu, 19 Dec 91 15:44:44 MST Received: by SHSU.edu (MX V3.0) id 27592; Thu, 19 Dec 1991 16:16:05 CST Sender: Date: Thu, 19 Dec 1991 16:15:50 CST From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu, cameron@midd.cs.middlebury.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Message-Id: <009535A6.ACADC3C0.27592@SHSU.edu> Subject: PGFRAME available on FILESERV Cameron Smith agreed to allow us to include his pageframe documentstyle option and related documentation in our archives for your retrieval. Below is the FILESERV description file for the package (retained as PGFRAME) which also includes information about ftp retrieval from Niord. --George =========================================================================== PGFRAME ------- The PGFRAME package includes the files associated with the pageframe documentstyle option by Cameron Smith as posted to comp.text.tex on December 3, 1991. THE COMPLETE SET OF FILES IN THIS PACKAGE SHOULD BE RETRIEVED TO ASSURE PROPER DOCUMENTATION. The pageframe document style option was written as an aid for people who are using LaTeX to make books. It assumes that the pages generated by LaTeX are printed on paper larger than the ultimate trimmed and bound size of the leaves of the book (for example, pages of a 7"x9" book printed on 8.5"x11" paper). The pageframe style option provides the following services: o Corner marks to serve as guides in trimming the page to final size o An identifying line of text (commonly called a tag line) across the top of each printed page, outside the final trim area, containing: - the name of the job that produced the page (this is the name of the main input file), - the time and date when the job was run, - the folio (the number of the page in the document's own numbering system---this number may be a roman numeral, and it may not be unique within the document), and - the absolute sequence number of the sheet within the document (this starts at number 1 and increases throughout the document) o A frame around the trim area of the page o Frames around the running head, text body, and footline o A grid (of user-specified dimensions) within the text body The tag line and corner marks are always printed; the other features may be turned on (separately) for draft or proof runs but would be turned off when the final form of the document is being generated. PGFRAMEDOC.TEX illustrates and explains the features that the pageframe style provides. The pages of the document are printed with different combinations of the pageframe option settings; you may want to look at the LaTeX source for the document to see how these are specified. You will find a summary of the pageframe commands near the end of this document. To retrieve the entire set of 3 files, include the command: SENDME PGFRAME in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). For ftp users, the files are available on Niord.SHSU.edu (192.92.115.8) in the directory [.PGFRAME]. A compressed tar file containing the set of three files is available for users on U*ix systems; a PKZIP'ped file containing the set of three files is available for users on DOS systems. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: DOS name in ZIP file: ------------------------------------------------------------------------------- PGFRAME.PAGEFRAME_STY 20 PAGEFRAME.STY PAGEFRAM.STY PGFRAME.PGFRAMEDOC_TEX 62 PGFRAMEDOC.TEX PGFRMDOC.TEX PGFRAME.PGFRAMETEST_TEX 3 PGFRAMETEST.TEX PGFRMTST.TEX Approximate total blocks in full PGFRAME package = 85 From "Mail Delivery Subsystem " Thu Dec 19 18:52:22 1991 Flags: 000000000001 Return-Path: Received: by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB25828; Thu, 19 Dec 91 18:50:03 MST Date: Thu, 19 Dec 91 18:50:03 MST From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <9112200150.AB25828@math.utah.edu> To: beebe ----- Transcript of session follows ----- Connected to nsfnet-relay.ac.uk: >>> RCPT To: <<< 550 (BHST) Unknown host/domain name in "cczdao <@nsfnet-relay.ac.uk:cczdao@clan.nott.ac.uk>" 550 cczdao%clan.nott.ac.uk@nsfnet-relay.ac.uk... User unknown ----- Unsent message follows ----- Return-Path: Received: from Niord.SHSU.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24927; Thu, 19 Dec 91 15:44:44 MST Received: by SHSU.edu (MX V3.0) id 27592; Thu, 19 Dec 1991 16:16:05 CST Sender: Date: Thu, 19 Dec 1991 16:15:50 CST From: "George D. Greenwade" To: info-tex@SHSU.edu Cc: tex-archive@math.utah.edu, cameron@midd.cs.middlebury.edu, texhax@cs.washington.edu, uktex@tex.ac.uk Message-Id: <009535A6.ACADC3C0.27592@SHSU.edu> Subject: PGFRAME available on FILESERV Cameron Smith agreed to allow us to include his pageframe documentstyle option and related documentation in our archives for your retrieval. Below is the FILESERV description file for the package (retained as PGFRAME) which also includes information about ftp retrieval from Niord. --George =========================================================================== PGFRAME ------- The PGFRAME package includes the files associated with the pageframe documentstyle option by Cameron Smith as posted to comp.text.tex on December 3, 1991. THE COMPLETE SET OF FILES IN THIS PACKAGE SHOULD BE RETRIEVED TO ASSURE PROPER DOCUMENTATION. The pageframe document style option was written as an aid for people who are using LaTeX to make books. It assumes that the pages generated by LaTeX are printed on paper larger than the ultimate trimmed and bound size of the leaves of the book (for example, pages of a 7"x9" book printed on 8.5"x11" paper). The pageframe style option provides the following services: o Corner marks to serve as guides in trimming the page to final size o An identifying line of text (commonly called a tag line) across the top of each printed page, outside the final trim area, containing: - the name of the job that produced the page (this is the name of the main input file), - the time and date when the job was run, - the folio (the number of the page in the document's own numbering system---this number may be a roman numeral, and it may not be unique within the document), and - the absolute sequence number of the sheet within the document (this starts at number 1 and increases throughout the document) o A frame around the trim area of the page o Frames around the running head, text body, and footline o A grid (of user-specified dimensions) within the text body The tag line and corner marks are always printed; the other features may be turned on (separately) for draft or proof runs but would be turned off when the final form of the document is being generated. PGFRAMEDOC.TEX illustrates and explains the features that the pageframe style provides. The pages of the document are printed with different combinations of the pageframe option settings; you may want to look at the LaTeX source for the document to see how these are specified. You will find a summary of the pageframe commands near the end of this document. To retrieve the entire set of 3 files, include the command: SENDME PGFRAME in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu). For ftp users, the files are available on Niord.SHSU.edu (192.92.115.8) in the directory [.PGFRAME]. A compressed tar file containing the set of three files is available for users on U*ix systems; a PKZIP'ped file containing the set of three files is available for users on DOS systems. Files in this package: (1 Block = 512 bytes) File Blocks Save file as: DOS name in ZIP file: ------------------------------------------------------------------------------- PGFRAME.PAGEFRAME_STY 20 PAGEFRAME.STY PAGEFRAM.STY PGFRAME.PGFRAMEDOC_TEX 62 PGFRAMEDOC.TEX PGFRMDOC.TEX PGFRAME.PGFRAMETEST_TEX 3 PGFRAMETEST.TEX PGFRMTST.TEX Approximate total blocks in full PGFRAME package = 85