UKTeX Digest Friday, 1 Mar 1991 Volume 91 : Issue 9 Today's Topics: {Q&A}: BoxedEPSF.tex DVI to 24-pin EmTeX distribution from Aston Re: Changebars.sty Problem with M & S Font Selection Scheme Baselinestretch when using M & S font selection scheme re: use of PK founts under MS-DOS Euler fonts and MFJOB use of PK founts under MS-DOS New smaller.sty Forward from Eberhard Mattes: [use of PK founts under MS-DOS] TUG Conference Proceedings Summaries {Announcements}: Formation of ITALIC (Irish TeX And LaTeX Interest Community) Greek typesetting UK TeX archive directory listings Announcing DVItoLN03 V4.0 for VAX/VMS Official new lplain and splain files {Archive News}: Additions to archive Re: Changebars.sty Rail package for diagrams and TeX new version of xdvi Rich Text Format conversion RE: Greek Typesetting Apologies to UUCP clients of TeXserver Would clients of Aston TeXserver please check disk quotas! Convert MSWord to LaTeX (crude but useful) Administrivia: Moderator: Peter Abbott (Aston University) Editor: David Osborne (University of Nottingham) Contributions: UKTeX@uk.ac.tex Administration, subscription and unsubscription requests: UKTeX-request@uk.ac.tex ------------------------------------------------------------ Date: Thu, 21 Feb 91 23:10:32 +0100 From: LCS%FR.MATUPS.MATUPS@UK.AC.MHS-RELAY Subject: BoxedEPSF.tex %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% EPSF graphics integration via TeX \special's --- a gentle path out of chaos [version of 22 Feb 1990] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Back in Fall 1990, Teresa A. Ehling , and Berthold K.P. Horn of Cambridge Mass posted an open letter on integration of Encapsulated Postscript graphics Files (EPSF's) graphics in TeX documents (TeXhaX digest22 Oct 90). Their problem is exactly one I have met in editing a conference proceedings volume on 3-manifold topology over the past year. Encouraged to believe this problem is typical, I would like to offer my particular solution. It is valid immeditely for just about everyone, given a modicum of cooperation from readers here. Ehling and Horn state the problem very well: > > Publishers, particularly those active in > technical areas, are rapidly moving towards the > use of author-supplied, machine- readable > material, for both journal and book production. > In mathematical and scientific areas, text > material is often best communicated in the form > of DVI files. Figures to be inserted are most > commonly provided in Encapsulated PostScript > (EPSF) form. > > A major stumbling block to completion of the > transition to seamless electronic publishing is > that every DVI processing program supports a > different usage convention for the \special > command. This means that every book or journal > project must be customized: instead of a smooth > operation involving only the transfer of the > authors DVI and EPS files, serious programming > effort is often required to deal with the myriad > variations in the \special syntactical rules. > > Realistically, all that the author requires is a > way of inserting an EPS-defined figure at a given > place in the TeX document. Our experience with a > large number of author-supplied DVI files > indicates that the predominant use of \special is > for simple figure insertion. In a small number of > cases, the figure also needs to be scaled. We > have yet to encounter a case where a figure needs > to be shifted, rotated, skewed, or clipped. More > importantly, no use is ever made of the ability > to insert verbatim PostScript commands, to call > on PostScript functions native to a particular > DVI processing program, or to produce overlays. > While these transformations represent interesting > and powerful extensions, they apparently are not > vital to the production of even the most > sophisticated texts. > In my own case, articles are moving constantly back and forth across several continents by email and ftp. Graphics that arrive by paper mail weeks or months later are anathema. Each article consists of an ascii ".tex" file for the print and a number of ascii EPS files for the graphics inserts. Our editors and publisher cannot manage with less than three distinct drivers, and authors would greatly appreciate support for an ever increasing number. One quibble though. We almost always use the scaling feature in \special commands, even when the artist is able to control scaling; in this way the editor and publisher almost never have to play with EPSF files and can concentrate their efforts on the TeX file. With this nuance, I agree that that our graphics insertions, like those encountered by Ehling and Horn, currently require only the bare basics they mention. Ehling and Horn make a strong plea for the rapid adoption of a \special standard covering at least the basics. Unfortunately even if such a standard is rapidly adopted, the present chaotic situation may not much improve for a few years while drivers are being revised. The gist of the present note is that a portable EFSF integration package can come quite close to providing the seamless integration Ehling and Horn dream of, even if the present anarchy in usage for \special commands persists. In a sense this makes the standard nearly (but not quite) irrelevant. Further it will be able assimilate a \special standard the day it appears. I programmed BoxedEPSF.tex for just this purpose, and am now making it available to the public. Here is how it is used. One \input's the file BoxedEPSF.tex. So long as there is no \special standard, you also have to identify your driver by a command like \SetArborEPSFSpecial %%(for the ArborTeX dvi to PS driver) Other driver commands \Set...EPSFSpecial are listed in BoxedEPSF.tex (or its documentation). Thereafter, one can place a postscript figure given by an EPS File myfile.ps by simply typing (for example) \BoxedEPSF{myfile.ps scaled 400} Here the (optional) scaling is to 40 percent = 400 mills. The result is a graphics insert that behaves like a TeX character or *box*, whose height and width are the height and width indicated in the bounding box comment of the EPS file, (in the line beginning "%%Bounding Box:" before the line beginning "%%EndComments"). It is well known that TeX can be made to read this comment, reserve a blank box of space of this size (scaled), and then set up an appropriate \special command of the driver in question, causing the Postscript printer to insert the (scaled) graphics nicely into this box. That is what \BoxedEPSF{...} is programmed to do. This should be contrasted with insertion by naked \special commands, which by convention imposes no displacement. Note that the user does not have to know about \special commands since he uses \BoxedEPSF instead. He just has to pick, out of a preestablished list, the \Set...EPSFSpecial command that corresponds to his driver. Yes, that IS a pain, and it will only go away only when a \special standard comes into use. But it not a big pain, and not debilitating, even for beginners. All the ideas above have been in circulation for several years and BoxedEPSF.tex is not the first package to offer all of them well knit together. However, the packages that have come to my attention each serve very few drivers, and often are so "feature-loaded" --- that porting is problematic. This one is built for easy portability and makes lowest-common-denominator demands on the driver. It is a single ".tex" file (the same for all drivers) BoxedEPSF.tex is currently available from the author at the addresses below; when it is considered to be in definitive shape it will be posted more conspicuously. Hopefully soon. BoxedEPSF.tex offers, via simple TeX programming, quite a few convenient extra features such as sliding, framing, trimming, squeezing, squashing, and aligning --- so far as actions worthy of these names can be accomplished without making extra demands on the driver. On the other hand it does not explicitly support sophisticated PostScript features such as shared prologues, clipping, rotations, distortions etc. The initial list of \Set...EPSFSpecial commands for support of specific drivers is: %%\SetTexturesEPSFSpecial for Textures %%\SetArborEPSFSpecial for ArborText DVILASER/PS %%\SetOzTeXEPSFSpecial for OzTeX %%\SetPsprintEPSFSpecial for sprint for Vax and VMS %%\SetUnixCoopEPSFSpecial early unix "dvi2ps" driver. %%\SetRokickiEPSFSpecial for Rokicki's "dvips" driver. To extend this list is easy, but it will require a bit of cooperation from the users of other drivers. Who, for example is willing to be a correspondent for the Beebe drivers? To let me extend support to ANY OTHER driver PLEASE SEND ME the \special syntax required to insert a file myfile.ps with scaling 76 percent! For example, the right answer for ArborTex was (I hope!): \special{ps: epsfile myfile.ps 760} And that was (almost) enough to let me program \SetArborEPSFSpecial. One more scrap of information is essential. Some \special's for EPSFs place the lower left corner of the (scaled) bounding box at the TeX insertion point (which requires reading the bounding box comment), and others simply place the lower left corner of the artist's page at the insertion point. No other choice seems consistent with Knuth's recommendations in the TeXbook. Textures and ArborTeX belong to the first type, while OzTeX and Rokicki's dvips belong to the second. Please report on the basis of documentation and/or experimentation, which type is in question. An experimental test routine is provided below. In general, some testing and/or driver documentation may be needed to clear up lingering questions. For example, are decimals allowed in in the scaling specification? For ArborTeX I believe the answer is no. An information form is included below for those who would like to see BoxedEPSF.tex adapted to another driver. When a \special standard finally appears, a command \SetStandardEPSFSpecial will be added to the list above. And when the standard is widely respected \SetStandardEPSFSpecial will no longer be commented out, and consequently it will make the default setting correspond to the standard. Laurent Siebenmann Mathematique, Bat. 425, Univ de Paris-Sud, 91405-Orsay, France lcs@matups.matups.fr (best for big files) LS@FrMaP711.bitnet (good for big files) siebenma@FRLAL51.bitnet (reliable!) siebenmann@LALCLS.decnet.cern.ch (reliable!) Fax number: 33-1-6941-6221 PS. Request \BoxedEPSF.tex and its documentation by email. PS. Culled from the correspondence on the net, here are four references that may give you leads to alternative solutions. --- PSFIG a package by Trevor Darrell (for at least two drivers) available by anonymous ftp from whitechapel.media.mit.edu (18.85.0.124) in ./psfig or linc.cis.upenn.edu (130.91.6.8) in the directory ./dist/psfig. --- Merging PostScript Illustrations: Gerald Roylance 1987, 1989, see MIT AI Laboratory Working Paper 299a; this package supports dvi2ps and DVILASER/PS. --- dvips and epsf.tex by by T. Rokicki --- Nicolas Jungers two postings in the GUTenberg forum 9 Nov 90 and 17 Nov 90; a "do-it-yourself" kit. APPENDIX: AN INFORMATION KIT FOR OTHER DRIVERS -------------------------------cut %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% spectest.tex %%% Test to discover which point in % the graphics page (plane) your \special % command distinguishes and identifies to % the TeX insertion point. % % --- Put the file gsquare.ps into the same folder as % TeX and this testfile. Hopefully this will make % gsquare.ps accessible to the printer driver. % % --- Complete the \special{... gsquare.ps ...} command below % as your driver documentation recommends for printing % the EPSF file gsquare.ps --- without any scaling, or other % refinement. For example % \special{ps: epsfile gsquare.ps 1000} % is suitable for the ArborteX driver. % % --- Typeset this file % % --- Print the resulting .dvi file using your driver. % % INTERPRETATION: % % If the black box lies in the square, the % distinguished point is the lower, left-hand corner of the % PostScript bounding box. % % If the black box lies outside the square, the % distinguished point is the lower, left-hand corner of the % artist's page, i.e. the the PostScript origin. % % If the square is missing, your driver has probably not found % the EPS file gsquare.ps, or you have formulated the \special % command incorrectly. Follow driver instructions more % carefully. % % --- report results to Laurent Siebenmann % % on the special reply "reply.doc" form provided below. % % \null \vfill \vskip -1 in \moveright 1 in \vbox{\hrule height 1 in width 1 in} \vskip 1 in \special{... gsquare.ps ...}%% please carefully adjust this \eject \bye %% end of spectest.tex %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -------------------------------cut %!PS-Adobe-2.0 %%Title: gsquare.ps %%Pages: 0 %%BoundingBox: 216 216 432 432 %%EndComments 72 72 scale % units are now inches instead of big points newpath 3 3 moveto 3 6 lineto 6 6 lineto 6 3 lineto closepath 0.8 setgrey fill -------------------------------cut %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% reply.doc %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% INFORMATION FORM for adaptation of BoxedEPSF.tex to other "dvi-to-PostScript" printer drivers %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Please provide information on in the following items: --- Name and email address(es) of correspondent. --- Driver information :Name, version, date, copyright, vendor, computer(s) served, price etc. --- Syntax required to print the EPS File gsquare.ps scaled to 76 percent using a command of the form \special{... gsquare.ps ...}. Is scaling to exactly 76.33 percent available? --- More info on \special. --- Location of the distinguished point. (Report result of test in spectest.tex above). --- Source(s) of your EPSF files. --- Do you progam TeX? PostScript? A trial adaptation to your driver will be returned with BoxedEPSF.tex. Thank you for cooperating! Laurent Siebenmann Mathematique, Bat. 425, Univ de Paris-Sud, 91405-Orsay, France lcs@matups.matups.fr (best for big files) LS@FrMaP711.bitnet (good for big files) siebenma@FRLAL51.bitnet (reliable!) siebenmann@LALCLS.decnet.cern.ch (reliable!) Fax number: 33-1-6941-6221 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -------------------------------cut APPENDIX. HOW ARE THE EPS GRAPHICS FILES BEING CREATED? While everyone admires PostScript graphics, few TeX users are entirely happy with their tools for producing the EPSF files. As soon as your integration problem has been disposed of, this one will be back to haunt you! Here are a few notes that may help: a) DrawOver 1.0 copyright Michael Everest 1986, is a converter to EPSF from the PICT graphics norm of the Macintosh, a norm for which there are many excellent drawing programs such as MacDraw. DrawOver is distributed with Illustrator 88 on the Mac. It is aging inasmuch as it handles the PICTs of more recent MacDraw versions less and less well. b) Illustrator 88 on the Mac by Adobe Corp is a MacDraw-like program that uses the EPSF norm. c) Macintosh output to LaserWriter printers is postscript code, and can be diverted into a file. This file cannot be used as is, but a header file can be added which with a few other changes produces a (bulky) EPSF file. See the macps converter of unix, or OzTeX or the $20 shareware Mac package AddLPrep copyright 1988 by SoftWare 101, 15151 Old Ranch road, Los Gatos CA. The output is I believe equivalent at similar resolution to what the Macintosh-LaserWriter combination produces. However, starting from the same PICT file, method (a) often gives better results! d) fig and xfig by Micah Beck, Cornell University are MacDraw-like programs for unix and unix X-windows, for which a translator transfig exists to EPSF norm. e) Naked PostScript code. PostScript is a beautiful language, and the three Adobe manuals are very helpful. I am sure it would be extremely useful if readers would extend and improve the above list! Here is a first response from Berthold K.P. Horn: (*) Aldus Freehand on the Mac is a more sophisticated tool for generating graphic illustrations than Adobe Illustrator. Both are constrained to basically two-dimensional patterns. Both can produce output in EPS form. (*) Micrografx Designer on the PC is a more sophisticated tool for generating graphics illustrations than Adobe Illustrator. It is the PC's answer to `MacEnvy', since it provides a Windows based tool that is about as good as any on the Mac. Designer is also constrained to basically two-dimensional patterns. It can produce output in EPS form. (*) There are also CAD/CAM applications that run on high end PC's, Sun workstations that can handle `solid modelling' of three dimensional objects, but they are an order of magnitude more expensive, so few people have access to them. (*) Illustrate on the Symbolics LispMachine was one of the first drawing programs and is still used quite a bit. It can produce output in EPS form. Very similar features to the other 2-D illustration applications mentioned above. (*) Screen Dumps. Another useful source of graphic illustrations are screen dumps available on LispMachine, Windows on PC, and on Mac in EPS form. OF course, they are in bitmap form so very limited in quality and not resolution-independent, but useful for illustrating program operations. (*) Paint Programs. On the Mac and the PC there are programs that instead of manipulating curves and areas work directly with bitmaps. The output can be in EPS form. But same drawback as screendumps. Not used much. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% END OF : EPSF graphics integration via TeX \special's --- a gentle path out of chaos %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ----------------------------------------- ------------------------------ Date: Fri, 22 Feb 91 08:53:27 +0000 From: MJH@UK.CO.KERNEL-TECHNOLOGY Subject: DVI to 24-pin Some time back in December '90, there was a little talk in this forum about 24-pin printer drivers. There are now lots of these printers on the market at sensible prices, making them suitable for draft or home-based use by budding TeX'sters. I saw no follow-up to these requests, so I wonder if there is any further information is available. I assume that such drivers must be common in DOS based environments, but now that UNIX is getting cheaper - and unbundled - for 386 PCs, use in this UNIX environment must be growing too. So, are there any such drivers? If so, are they acceptable in terms of speed, quality and facilities? If not, are there any starting points (eg, a DOS version which uses a comparable font format) from which The development of a UNIX version may be started? Mark J. Hewitt bangpath: ...!ukc!kernel!mjh JANET: mjh@uk.co.kernel voice: (+44) 532 444566 other: mjh@kernel.co.uk fax: (+44) 532 425456 old style: mjh%uk.co.kernel@uk.ac.ukc paper: Kernel Technology Ltd, Development Centre, 46 The Calls, Leeds, LS2 7EY, West Yorkshire, UK ------------------------------ Date: Fri, 22 Feb 91 12:16:05 +0000 From: ABBOTTP@UK.AC.ASTON.VAX.SPOCK, ABBOTTP "Peter Abbott - Computing Service" Subject: EmTeX distribution from Aston > fr/ Duarte Trigueiros > Norwich 20/2/91 > > Dear Peter, > > Thanks for sending emTeX. I am returning six HD 5 1/4 disks to replace > those you kindly put to complete the lot. > > I also send you a few more disks because I believe some font libraries are > missing. Here is the list of the fonts I've got: > > LJ_O LJ_H LJ_I LJ_2 LJ_3 LJ_5B > > The drivers for HP Laser Jet+ and for Screen complain about not finding the > LJ_4. In fact, it's missing. > > Environment variables and paths seem correct. > > I also received the disk DVIPS2.21P with DVIPS on it. Is it the only disk > required to run DVIPS? If not, I would like to have it all since here at > UEA we have facilities for using PostScript printers. > > Enclosed is a cheque for paying the postage rate. > > Thanks again. Best regards, > > Duarte Duarte Your letter is of general interest to the wider community so a copy of this message is being sent to the digest. You are missing lj_4 and lj_5a simply because the ZIP files are too large for the low density 3.5" and (so I am told) on both densities at 5.25". A member of the archivegroup is working on a procedure to split ZIP files and this problem will eventually disappear. I have had the same problem on my portable at home and found that by backing up the zip files (DOS 3.3) the two ZIP files fitted onto 3 low density 3.5" disks. I also discovered that by removing the reference to lj_4 and lj_5a from the v.bat file that the previewer worked fine. If anyone needs the lj_4 and lj_5a urgently then they can be supplied in the usual way as backup (DOS 3.3 only). Otherwise the new zip split should be here soon. A bonus of the new zip split will be the ability to include other files which are not currently available on the low density disks. I have not yet loaded dvips2.zip onto my portable so cannot say if there is anything missing. No doubt someone else can answer this question for you. Peter ------------------------------ Date: Sun, 24 Feb 91 14:01:31 +0000 From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS Subject: Re: Changebars.sty is anyone rewriting this style file to support a case statement instead of an if...else construct for \special support? I could happily hack it to work with dvips, but would prefer to have a more acceptable framework agreed in advance sebastian ------------------------------ Date: Mon, 25 Feb 91 10:41:26 +0100 From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY Subject: Problem with M & S Font Selection Scheme From: P.ABBOTT@UK.AC.ASTON The following command has been used for the last two years when producing a newsletter. When used with M & S font selection scheme the \rm is NOT obeyed and the contents is then set in \bf. I had assumed that \rm and \bf are series commands (Page 300 (section 2.2) TUGboat Vol 11 no 2). Anyone know what I am doing wrong? Peter % % majorsec is used to produce the heading VAX GENERAL etc % \newcommand?\majorsec?[1]? \parbox?124mm???\huge\bf \special?greybox.ps? \begin?center?#1\end?center?? \vspace?0.1in? ? \addtocontents?toc??\protect\vspace?3pt?? \addtocontents?toc?? #1? \addtocontents?toc??\protect\newline? \addtocontents?toc??\protect\vspace?-8pt?? \addtocontents?toc??\protect\normalsize? \addtocontents?toc??\protect\rm? ? That depends on whether you are using the oldlfont or the newlfont option. In the former case it should behave as before (i.e. old lfonts.tex). With newlfont \rm changes only the family, \bf only the series. (Sorry for the ???????, I think it was UK.AC.RL striking again!!!) Rainer Sch\"opf Dr. Rainer Schoepf Konrad-Zuse-Zentrum fuer Informationstechnik Berlin Heilbronner Strasse 10 D-1000 Berlin 31 Federal Republic of Germany or ------------------------------ Date: Mon, 25 Feb 91 10:46:42 +0100 From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY Subject: Baselinestretch when using M & S font selection scheme From: P.ABBOTT@UK.AC.ASTON When using the new font selection scheme from M & S the baselinestretch no longer has any effect. To change to double line spacing \def\baselinestretch{1.5} gave the required result. What is the equivalent using the new font selection scheme? Peter Abbott There was a glitch in the New Font Selection Scheme that caused the \baselineskip not to be initialized properly. It was fixed in June last year (I think). This fix solves the problem if your \newcommand{\baselinestretch}{1.5} is placed in the preamble of the document. If you want to change \baselinestretch later on, somewhere within the document, you have to force a size change, e.g., \newcommand{\baselinestretch}{1.5} \small\normalsize This is the same behaviour as before (i.e. with old LaTeX's font selection); I hesitate to call it a feature, though. Rainer Sch\"opf ------------------------------ Date: Mon, 25 Feb 91 09:48:07 +0000 From: CUDAT@UK.AC.WARWICK.CU Subject: re: use of PK founts under MS-DOS Brian Hamilton Kelly sent me some electronic mail:- >Date: Thu, 21 FEB 91 11:00:27 GMT >From: TEX@UK.AC.CRANFIELD.RMCS >In a submission to UKTeX of Wed, 20 Feb 91 14:50:14 GMT, >J M Hicks wrote: >> Both DVISCRS and DVITOPS use the fount name, printer resolution >> and fount magnification to find the required PK file for a fount. >> To do this, DVITOPS can substitute (resolution x magnification) >> in the name of a file it is looking for (the resolution is in >> dots per inch). DVISCRS does something similar, but it >> uses (resolution x magnification x 5). >... >>... >The solution lies in your hands (well, actually in the configuration >file, or in the /PF qualifier used on the DVISCRS command line): define >the path for the packed pixel files as `C:\FONTS\DPI$r'; the `$r' means >``substitute the result of computing resolution x magnification''. >There's a different placeholder to specify ``compute the PXL file >magnification'', which you seem to be using. >... Brian is quite right; all I had to do was to use $r and I could use the same set of fount files with both programs. The confusion stems, I think, from the description in my copy of DVIDRV.ENG, the English translation of the German documentation. It refers to (magnification) and (resolution) rather than (magnification x resolution x 5) and (resolution x magnification). The former is explained in more detail but I can't find a detailed description of the latter. I have looked at the German original: I can't be sure but it looks as though the translation has been faithful. Perhaps I simply lack a knowledge of DVI device driver jargon. Many thanks to Brian for putting me right. - -- Jim Hicks, Computing Services, Warwick University, Coventry, England. CV4 7AL Office: Coventry (STD O2O3) 523262 On JANET: cudat@UK.AC.WARWICK.CU ------------------------------ Date: Mon, 25 Feb 91 10:36:30 +0000 From: A42JR@UK.AC.POLY-EAST-LONDON Subject: Euler fonts and MFJOB Some time ago I wrote asking about compiling the Euler fonts using emtex. I did receive some replies, but they were not all that useful. Has anyone actually successfully comiled these fonts using MFJOB, or the emtex MF. If so, how did they do it? John Rostron Division of Environmental Sciences, Polytechnic of East London Romford Rd, E15 4LZ ------------------------------ Date: Mon, 25 Feb 91 14:39:30 +0100 From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY Subject: use of PK founts under MS-DOS From: CUDAT@CU.WARWICK.AC.UK I have recently been setting up LaTeX for someone on an IBM PC compatible. I have been using DVISCRS (version 1.3i) from the emTeX collection as a previewer, and DVITOPS (by James Clark) to convert DVI files to PostScript. Both DVISCRS and DVITOPS use the fount name, printer resolution and fount magnification to find the required PK file for a fount. To do this, DVITOPS can substitute (resolution x magnification) in the name of a file it is looking for (the resolution is in dots per inch). DVISCRS does something similar, but it uses (resolution x magnification x 5). This makes it awkward to have the previewer and the printer driver use the same set of founts. (DVISCRS gives pretty good results with 300 d.p.i. founts and it seems silly to have two sets of PK files when one will do.) Fortunately DVITOPS is persistent enough to look in all the MS-DOS directories it is given until it finds exactly the right fount file, so I name the directories according to emTeX's convention and tell DVITOPS about each directory individually. This is a nuisance as the directory names then need to be kept short so that they can all fit into an MS-DOS environment variable. Is there any chance that developers might be encouraged to agree on the general principles of how to locate a required fount file? This is yet another chapter of a very sad story... The (resolution x magnification x 5) convention is an old one, and I don't see any reason why it should still be used. Actually, I don't see a reason why the directory names should contain the resolution. There should be one directory for every output device (thus implicitly or even explicitly containing the resolution of that particular device), with subdirectories for different magnifications, each one containing the appropriate .PK files. The names of these subdirectories should not contain the resolution, but the magnification, for a very simple reason: I find it very awkward to remember that cmr10 for \magstephalf is contained in, say, pk329 for a HP Laserjet, and in 1395pk for a 1270dpi Linotype. Instead, both directories should be named something like "mag1095". Driver programs should (1) be able to read a font substitution definition file, (2) have settable paths for the pk directories, preferably with variable parts to conform to different conventions, (3) no longer use .PXL files instead of .PK files. I think we should finally put away those old conventions that have ceased to be useful. Rainer Sch\"opf ------------------------------ Date: Mon, 25 Feb 91 14:43:54 +0100 From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY Subject: New smaller.sty From: PLA@UK.AC.EDINBURGH.COMPUTER-SCIENCE.TARDIS When acronyms or upper-case abbreviations are printed, it is good typographic style to set them in a smaller type-size to avoid undue emphasis (the output from WEB files is an example). Of course, it is possible to use {\small TEXT} in body text, {\scriptsize TEXT} in footnotes, etc. This falls over in section headings (even if you can remember the correct size command) when a table of contents is required (unless you really want a \Large word in there). One way round this is to use something like {\sc text}. Unfortunately, this only works for roman text, and the small caps font is often not available ov er a full range of sizes. A better solution is a relative size-changing command, and one appeared in TeXHaX(?) some time ago. Usage is {\smaller TEXT} and this works no matter what the current type size. Since it invokes LaTeX size-changing commands, it has the unfortunate side-effect of re-asserting roman type-face . It is possible to use {\smaller\em TEXT} in emphasized text, but this is tedious and inelegant. There is still a problem with section headings - {\smaller\bf TEXT} works fine in the heading itself, but again falls over in the table of contents because the \bf creeps in. The problem of `re-asserting roman type-face' disappears when the New Font Selection Scheme is used with its newlfont option. This is only one of the minor advantages of the NFSS. Rainer Sch\"opf ------------------------------ Date: Mon, 25 Feb 91 16:47:28 +0100 From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY Subject: Forward from Eberhard Mattes: [use of PK founts under MS-DOS] > dots per inch). DVISCRS does something similar, but it > uses (resolution x magnification x 5). Use (for instance) /pf\texfonts\canon\$rpk with dviscrs to use resolution x magnification. $r will be replaced with the font size (resolution x magnification). The 1.4d release of dvidrv ceased to use resolution x magnification x 5, but still supports $s for the old (pxl) convention. > Driver programs should > (1) be able to read a font substitution definition file, > (2) have settable paths for the pk directories, preferably with > variable parts to conform to different conventions, > (3) no longer use .PXL files instead of .PK files. All this can be done with the emTeX drivers. The /texfonts/canon/cmr10.300pk font naming scheme will be supported by the next release. You may want to use dvips 5.47, it can read the emTeX font libraries. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) ------------------------------ Date: Fri, 01 Mar 91 10:42:00 +0000 From: CBTS8001%IE.UCC.IRUCCVAX@UK.AC.EARN-RELAY Subject: TUG Conference Proceedings Summaries Christine Thiele has done a valiant task and compiled four files of proceedings summaries from all TUG meetings since 1987. I have the four file TUGPROC.1987, .1988, .1989, .1990 so I will upload them to the archives...IF... Can someone please post a summary of the correct addresses for the submission of material to: Aston Ymir Clarkson Labrea Heidelberg so that I and others know exactly to whom stuff can/should be sent. ///Peter ------------------------------ Date: Fri, 22 Feb 91 14:15:00 +0000 From: CBTS8001%IE.UCC.IRUCCVAX@UK.AC.EARN-RELAY Subject: Formation of ITALIC (Irish TeX And LaTeX Interest Community) \magnification=\magstep1 \vsize=9truein \hsize=6truein \font\lit=cmti10 scaled \magstep4 \font\mf=manfnt \font\sc=cmcsc10 \font\sltt=cmsltt10 \font\mrm=cmr10 scaled \magstep2 \font\msc=cmcsc10 scaled \magstep2 \def\larger{\let\rm=\mrm \let\sc=\msc\rm} \def\LaTeX{{\rm L\kern-.36em\raise.3ex\hbox{\sc a}\kern-.15em T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}} \def\MetaFont{{\mf METAFONT}} \def\csc#1{{\sc\lowercase{#1}}} \newbox\ibox\setbox\ibox=\hbox{{\mrm The}} \parindent=\wd\ibox\advance\parindent by.5em \nopagenumbers \setbox\ibox=\hbox{{\lit % i t a l i c % }}\newdimen\iwd\iwd=\wd\ibox \indent\box\ibox\par \setbox\ibox=\hbox to\iwd {\leaders\hrule height2pt\hfill} \indent\box\ibox\smallskip\begingroup\larger \item{The} Irish \TeX\ And \LaTeX\ Interest Community \bigskip\endgroup\parskip=\smallskipamount\noindent\ignorespaces At the \TeX90 conference in Cork last September there was a brief meeting to discuss forming a group for Irish users of \TeX, \LaTeX, \MetaFont\ and allied software. Users in Ireland and abroad are now invited to signal their interest in this group and join the mail discussion list {\tt ITALIC-L} by sending a one-line electronic mail message to {\tt LISTSERV@IRLEARN.BITNET} saying\hfil\break {\tt SUBSCRIBE ITALIC-L {\sltt your\_real\_name}} Present at the meeting were: Peter Flynn (UCC); M\i che\'al \'O Searc\'o\i d (UCD); Brendan Dixon (UCD); John Finnegan (UCG); Tim Murphy (TCD); John Simmie (UCG). \noindent\ignorespaces The following topics were discussed: \item{1.} Name of the group: the acronym \csc{ITALIC} had been suggested at the Texas \csc{TUG} conference by Pierre MacKay. Some members of the meeting felt an Irish word related to typography or calligraphy would be more appropriate: suggestions to date have been: \csc{TACA} (\TeX\ Agus Cl\'o-dhearadh Ailg\'eabrach---{\it \TeX\ and Algebraic Type Design\/}); \csc{CELTIC} (Cl\'od\'o\i reacht \'E\i feachtach Le \TeX\ \'I gC\'omhar---{\it Effective Printing together with \TeX\/}); \csc{CL\'AR} (Cl\'ochurad\'o\i reacht Le\i ctreonach Agus R\'\i omhchu\i d\i the---{\it Electronic and Computer-Aided Typesetting\/}). \csc{TACA} was turned down because the acronym has political connotations in Ireland. Comments on the others' suitability (or new suggestions) are welcomed. For the moment, \csc{ITALIC} remains the most comprehensible internationally. \item{2.} Mail distribution: \csc{BD} has set up {\tt ITALIC-L} on {\tt LISTSERV@IRLEARN} with some file space for storing pointers to the major repositories ({\it eg\/} filelists for Aston, Heidelberg, \csc{YMIR}, Clarkson and Labrea), but not much in the way of \TeX ware itself, as this is easily retrievable from the aforementioned repositories. \item{3.} \csc{PF} will supply a regularly-updated copy of the file {\tt ASTON%ARCHIVE}, containing the complete list of files at Aston in denormalised form, suitable for searching. \item{4.} \csc{TM} is to investigate the inclusion of \csc{SGML} users and software. \item{5.} \csc{TM} is also to contact Irish \TeX ware authors to arrange for their notification and eventual inclusion of their software where permitted. \item{6.} \csc{PF} is to contact the academic computer centres to sound out the possibility of making an institutional membership fee at a low level (instead of an individual membership fee) to cover (initially) the cost of a meeting later this year (1991) \bigskip\noindent\sl Peter Flynn, 19 February 1991, Computer Centre, UCC \hfil\break\tt cbts8001@iruccvax.ucc.ie \eject\end ------------------------------ Date: Mon, 25 Feb 91 10:35:49 +0100 From: SCHOEPF%DE.ZIB-BERLIN.SC@UK.AC.NSFNET-RELAY Subject: Greek typesetting From: CBTS8001%IE.UCC.IRUCCVAX@UK.AC.EARN-RELAY A user here wants to do real Greek, and I know there are fonts or macros to do this (Silvio Levy?) but where are they? There seems to be no mention in the lists at Aston or Heidelberg. ///Peter Three flavours of greek fonts have been installed in the MFSOURCE FILELIST at LISTSERV@DHDURZ1.BITNET a few weeks ago. Rainer Sch\"opf ------------------------------ Date: Mon, 25 Feb 91 18:04:21 +0000 From: TEX@UK.AC.CRANFIELD.RMCS Subject: UK TeX archive directory listings In every directory of the UK TeX archive at UK.AC.TEX there is a file called 00FILES.TXT which contains a list of the files in that directory. I've just modified the program used to generate the list to provide slightly more information on the type of file in the directory. Part of a 'typical' listing is quoted below: > Files matching DISK$TEX:[TEX-ARCHIVE.BINARY.VMS]*.* > listed in reverse time order (listing updated: 25-Feb-91 16:38). > > Last change Size Type File specification > -------------------------------------------------------------------------- > 22-Jan-91 03:23 3532 txt 00files.txt > 4-Dec-90 17:46 2590 txt 00readme.txt > 4-Dec-90 17:38 634 txt glib_index.dat > 4-Dec-90 17:29 102 txt grlib-options.opt > 4-Dec-90 13:09 16548 bin pktype.obj > 4-Dec-90 13:08 29418 bin gftype.obj > 4-Dec-90 13:06 29098 bin gftopxl.obj > 4-Dec-90 12:48 116736 *VMS* cmplain.base > 4-Dec-90 12:48 914 txt cmplain.inimf_lis > 4-Dec-90 12:47 69632 *VMS* plain.base ... > 3-Dec-90 12:28 51888 bin tangle.obj > 24-Sep-90 12:22 - *DIR* drivers.dir > 18-May-90 10:30 7172 bin wmerge.obj > 17-Aug-89 16:51 16538 bin pktopx.obj > 17-Aug-89 09:51 187158 bin bibtex.obj > 23-Mar-88 16:59 13816 bin pxtopk.obj > -------------------------------------------------------------------------- The possible file types and means of accessing them are: txt - an ordinary text file. Mail server access: yes JANET NIFTP access: yes (ASCII/text mode) bin - an 'ordinary' binary file. Mail server access: yes (with FILES /ENCODE) JANET NIFTP access: yes (binary mode) *DIR* - a VAX/VMS directory file Mail server access: DON'T !! JANET NIFTP access: DON'T !! *VMS* - a file with VAX/VMS specific attributes Mail server access: yes (with FILE/ENCODE) JANET NIFTP access: yes, but only from VAX/VMS systems using TRANSFER /CODE=FAST Niel Kempson (Aston archive group) ------------------------------ Date: Thu, 28 Feb 91 18:16:06 +0000 From: TEX@UK.AC.CRANFIELD.RMCS Subject: Announcing DVItoLN03 V4.0 for VAX/VMS DVItoLN03 Version 4.0 27th February 1991 ========= =========== ================= = This new release of DVItoLN03 provides support for virtual fonts, for mixing portrait and landscape orientation in a document (including on the same page) and for the newer DEClaser printers (LN05 & LN06), as well as managing to effect a 25% increase in speed: it has been placed in the UK TeX Archive as follows: Sources, documentation and other support: in [tex-archive.drivers.ln03.rmcs] -- get 00files.txt for details Binary files (can only be transferred to a VAX, using TRANSFER/CODE=FAST): in [tex-archive.binary.vms.drivers.dvitoln03] DVITOLN03.OBJ -- ought to link under any version of VMS DVITOLN03.EXE -- linked under VMS V5.3-1 DVITOLN03.BCK -- BACKUP save set containing the complete distribution; sites able to effect NIFTP can usefully fetch the whole shebang in one go. Please ensure that you fetch and read the 00README.TXT file. 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. (Can also manage Tektronix insertions on the LN03-plus.) 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 substituted 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 rather than a curiosity! 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. 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 ------------------------------ Date: Mon, 25 Feb 91 13:48:15 +0700 From: JL2%EARN.DHDURZ1@UK.AC.EARN-RELAY Subject: Official new lplain and splain files The new versions of the files lplain.tex and splain.tex that have been changed by Frank Mittelbach and myself to make them usable both with TeX 2.x and TeX 3.x have been included into the official LaTeX distribution at LaBrea.Stanford.edu. I have placed them into the LATEX FILELIST at listserv@dhdurz1 as well. Rainer Sch\"opf DANTE coordinator for server machines ------------------------------ Date: Fri, 22 Feb 91 18:34:40 +0000 From: CHAA006@UK.AC.TEX Subject: Additions to archive The following files have been added to the archive, by courtesy of Wayne Sullivan . Philip Taylor - -------- Directory DISK$TEX:[TEX-ARCHIVE.WEB.MS-DOS.BREITENLOHNER] DVICOPY.BOO;1 220/222 22-FEB-1991 18:24:04.56 GFTODVI.BOO;1 267/267 22-FEB-1991 18:09:51.28 TANGLE.BOO;1 412/414 12-FEB-1991 12:32:50.35 WEAVE.BOO;1 271/273 12-FEB-1991 12:02:30.69 Total of 4 files, 1170/1176 blocks. - -------- Directory DISK$TEX:[TEX-ARCHIVE.METAFONT.MS-DOS.SBMF] SBMF12.BOO;1 646/648 12-FEB-1991 11:32:40.57 Total of 1 file, 646/648 blocks. - -------- Directory DISK$TEX:[TEX-ARCHIVE.TEX.V3.MS-DOS.SB-TEX] SB32XET.BOO;1 732/732 22-FEB-1991 19:00:00.60 SB34TEX.BOO;1 712/714 22-FEB-1991 18:50:07.02 Total of 2 files, 1444/1446 blocks. ------------------------------ Date: Sun, 24 Feb 91 13:59:55 +0000 From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS Subject: Re: Changebars.sty the latest revision of a LaTeX style file supporting change bars, either with LN03 specials, or PostScript specials (for Clark's dvitops) is installed in the UK TeX Archive as [tex-archive.latex.contrib]changebar.sty Note that it is called changebar, not changebars!!!! this is because that is what the previous version was called, and it makes life easier for MSDOS and VM/CMS people sebastian rahtz ------------------------------ Date: Mon, 25 Feb 91 18:22:47 +0000 From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS Subject: Rail package for diagrams and TeX I have placed Luc Rooijakkers `rail' package in the UK TeX Archive. It helps making syntax diagrams (short description appended). The source can be found in [tex-archive.utils.rail] sebastian rahtz The Rail package, version 1.0 #0 -------------------------------- The Rail package allows you to include syntax diagrams (also known as railroad diagrams) in a LaTeX document. A UNIX manual page and LaTeX documentation are included. The package consists of a LaTeX style file (rail.sty) and a C program (rail) and works in two passes not unlike BibTeX. Diagrams are specified in a regular-expression like format between \begin{rail} and \end{rail} brackets, and are formatted using the standard LaTeX picture environment. To use the package, you need a UNIX system with LaTeX. Actually, the rail program should be portable to non-UNIX systems, but you need lex and yacc (or compatible programs such as flex and bison) and a C compiler. No fancy ANSI C constructions are used, and the program passes lint quite silently. -- Luc Rooijakkers Internet: lwj@cs.kun.nl Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj University of Nijmegen, the Netherlands tel. +3180652271 ------------------------------ Date: Mon, 25 Feb 91 18:25:07 +0000 From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS Subject: new version of xdvi I have placed the current release of the X11 previewer `xdvi' in the UK TeX Archive in [tex-archive.drivers.xdvi] updating the previous release. This is patchlevel 11, and fixes some bugs. Most notably (for me!) it no longer dies when asked for a character which is not in a font. Worth upgrading for this alone. Sebastian Rahtz ------------------------------ Date: Mon, 25 Feb 91 18:54:06 +0000 From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS Subject: Rich Text Format conversion Its not strictly TeXery, but as its quite small and as some people are interested in it, I have installed a small set of programs by Paul DuBois in the UK TeX Archive, which parse and translate Microsoft's RTF format. Maybe someone will pick it up and write us an RTF --> LaTeX or LaTeX--> RTF? [tex-archive.utils.rtf] Sebastian Rahtz ------------------------------ Date: Mon, 25 Feb 91 19:11:17 +0000 From: TEX@UK.AC.CRANFIELD.RMCS Subject: RE: Greek Typesetting In a message UKTeX V91 #6 on Tue, 05 Feb 91 11:44:03 -0000, P.TAYLOR@UK.AC.RHBNC.VAX wrote: > Peter Flynn wrote: > > >>> A user here wants to do real Greek, and I know there are fonts or macros > >>> to do this (Silvio Levy?) but where are they? There seems to be no mention > >>> in the lists at Aston or Heidelberg. > > I have, and use, the fonts regularly. If the consensus is that they are > not already in the archive, I'll put them there. But I suspect they are > really there all along ... Yes, they've all been there for ages; herewith the listing of the relevant parent directory: Files matching DISK$TEX:[TEX-ARCHIVE.FONTS.GREEK]*.* listed in reverse time order (listing updated: 22-Jan-91 03:45). Last change Size Type File specification - ----------------------------------------------------------------------------- 24-Sep-90 14:41 - DIR [tex-archive.fonts.greek]levy.dir 24-Sep-90 14:40 - DIR [tex-archive.fonts.greek]haralambous.dir 24-Sep-90 14:40 - DIR [tex-archive.fonts.greek]hamilton-kelly.dir - ----------------------------------------------------------------------------- (The directory dates are newer than the files; this is the date on which they were transferred to the new archive machine from the old one.) Brian {Hamilton Kelly} ------------------------------ Date: Mon, 25 Feb 91 20:53:11 +0000 From: TEX@UK.AC.CRANFIELD.RMCS Subject: Apologies to UUCP clients of TeXserver From an analysis of bounced mail, sent out by TeXserver@uk.ac.tex, in response to requests from users connected via UUCP outside the UK, I've discovered that the Janet-UUCP gateway at the University of Kent has been bouncing all the mail, because the new archive machine UK.AC.TEX appears not to be authorized to send international mail! Peter Abbott did request UKC to add this new machine towards the end of last year, and it did work for a while; now it's started to refuse traffic. I'm asking Peter to chase UKC and ask for them to (re-) register us. I expect this will get fixed within a day or two, so if those users of the archive who heard zilch in response to their requests would care to try again, I have every hope that they'll work this time! Sorry for curtailing your enjoyment! Brian HK ------------------------------ Date: Mon, 25 Feb 91 21:04:10 +0000 From: TEX@UK.AC.CRANFIELD.RMCS Subject: Would clients of Aston TeXserver please check disk quotas! Would users of the Aston Archive mail server, TeXserver@Uk.Ac.TeX, please ensure that they have sufficient room on their disks before requesting information from the archive. I've just been analysing the log of bounced mail, and a lot of it was due to traffic being returned by the target machine because the requesting individual had either insufficient disk quota, or the file system was full! If you are unsure as to how much space any particular file might take, you should fetch the 00files.txt from the relevant directory before requesting the file itself; such files are only about 1--2kB long, but something like [tex-archive]00directory.size is over 1MB in length. Still, if you _have_ got room to keep a copy of this file, it'll save you having to make DIRECTORY requests. The file is updated daily, so it's more efficient to request a copy of this (or its smaller brother, [tex-archive]00directory.list) rather than asking the TeXserver to repeat all the work by saying DIRECTORY [tex-archive...]! (You'd be amazed how often that one comes up.) Requesting files when you've got insufficient space to hold them not only results in your not getting them, but also wastes our limited bandwidth for e-mail (9600Bd only!), not to mention the time taken in the TeXserver sending them out, and the disk space of the TeXserver taken up by the bounced traffic. Brian HK ------------------------------ Date: Fri, 01 Mar 91 13:41:17 +0000 From: S.P.Q.RAHTZ@UK.AC.SOUTHAMPTON.ECS Subject: Convert MSWord to LaTeX (crude but useful) I have installed the folliowing item in the UK TeX archive: WD2LATEX.ZIP Convert MSWord to LaTeX (crude but useful) boo-encoded as [tex-archive.drivers.wd2latex]wd2latex.boo on uk.ac.tex It contains an executable and source. No experience or guarentees from me - I have not even tried it. Some notes follow. Sebastian Rahtz - ------------- Written by Dr Connor J Thomas (cthomas@f.adelaide.edu.au). The archive comes with both source and a binary. Selected excerpt from the README file: THE TRANSLATION PROGRAM works by interpreting Epson compatible printer codes and translating a limited set of these to appropriate LaTeX code. This approach is limited and cannot easily be used to interprete undelined text; tables etc also present dificulties. But I do have some MSWORD macros to help format basic LaTeX tables. The present version will cope with: IBM PC Hi-Ascii characters Special LaTeX characters such as \ % { } etc. Math characters such as + - Italicized text Bolded text Superscripts and Subscripts Small caps format Characters bolded and to be printed in Epson Large type will be interpreted as \section{text} but remember to bold first and change size second (See notes in source code). The program can be easily expanded to cope with more complex procedures. ------------------------------ UK TeX ARCHIVE at ASTON UNIVERSITY *** JANET Interactive and NIFTP access *** Host: uk.ac.tex (JANET DTE 000020120091) Username: public Password: public *** Files of interest *** [tex-archive]00readme.txt [tex-archive]00directory.list [tex-archive]00directory.size [tex-archive]00directory_dates.list [tex-archive]00last30days.files This year's UKTeX back issues are stored in the archive, in directory [tex-archive.digests.uktex.91] This year's TeXhax back issues are stored in the archive, in directory [tex-archive.digests.texhax.91] Latest TeXhax: #08 TeXMaG back issues are stored in the archive, in directory [tex-archive.digests.tex-mag] Latest TeXMaG: V5 N1 *** Media distributions *** Washington Unix tape (28 March 1990) TeX 2.993(==3.0), LaTeX 2.09, Metafont 1.9 (2.0) Unix 4.2/3BSD & System V. Tar 1600bpi, blockfactor 20, 1 file. Send one 2400' tape with return labels AND return postage. VMS backup of the archive requires two 2400' tapes at 6250bpi. VMS backup of TeX 2.991 plus PSprint requires one tape. Exabyte 8mm tapes: same formats available as 1/2in tapes. The following tapes are available: SONY Video 8 cassette P5 90MP, MAXELL Video 8 cassette P5-90, TDK Video 8 cassette P5-90MPB OzTeX (for Macintosh): Send 10 UNFORMATTED 800K disks with return postage. emTeX (for MS-DOS): Send 11 UNFORMATTED 1.44Mb or 18 720K 3.5" disks, or 12 UNFORMATTED 5.25" disks, with return postage. emTeX is now distributed with a copy of `Baskerville' and documentation. Please therefore send the disks in packing of A4 size or enclose an A4 envelope. *** Postage rates: all prices in pounds sterling *** (make cheques payable to Aston University) 0.5" tapes: UK: 2.50 (one tape), 5.00 (two tapes). Europe: 5.00 (one tape), 9.00 (two tapes). Outside Europe please enquire. 8mm tapes: UK: 1.00, Europe: 2.00. DC600A cartridges: UK: 1.00, Europe: 2.00. Diskettes: Quantity/Size Europe World UK 1st UK 2nd 18/3.5" 3.10 5.10 1.40 1.10 11/3.5" 1.80 2.90 0.80 0.65 18/5.25" 1.20 2.00 0.60 0.50 11/5.25" 0.80 1.30 0.50 0.35 *** Postal address *** Peter Abbott, Computing Service, Aston University, Aston Triangle, Birmingham B4 7ET (Please include SELF-ADDRESSED ADHESIVE LABELS for return postage). *** UK TeX Users Group *** For details, contact Malcolm Clark or Geeti Granger IRS John Wiley & Sons Polytechnic of Central London Baffins Lane 115 New Cavendish Street Chichester London W1M 8JS W Sussex PO19 1UD email: malcolmc@uk.ac.pcl.mole End of UKTeX Digest *******************