TeXhax Digest Sunday, February 10, 1991 Volume 91 : Issue 006 Moderators: Tiina Modisett and Pierre MacKay %%% The TeXhax digest is brought to you as a service of the TeX Users Group %%% %%% in cooperation with the UnixTeX distribution service at the %%% %%% University of Washington %%% Today's Topics: Re: TeXhax Digest V91 #005 TeXhax Digest V91 #002 Graphics, TeX, Metafont posting on special ----------------------------------------------------------------------------- Date: Mon, 04 Feb 91 09:41:57 EST From: furuta@cs.UMD.EDU Subject: Re: TeXhax Digest V91 #005 Keywords: G.W.Stewart >From: Erich Neuwirth > >Can anybody help me to contact G. W. Stewart. >He is the author of jeep.sty and his address was, >stewart@thales.und.edu >but this machines seems no longer to be known on internet. > >ERICH NEUWIRTH >BITNET (EARN): A4422DAB@AWIUNI11 >INTERNET: a4422dab@Helios.EDVZ.UniVie.AC.AT >Institute for Statistics and Computer Science >UNIVERSITY OF VIENNA, UNIVERSITAETSSTR. 5/9, A-1010 VIENNA, AUSTRIA Pete Stewart's email address is stewart@cs.umd.edu --Rick --------------------------------------------------------------------------- Date: Mon, 4 Feb 91 06:50:58 -0500 From: svb@cs.purdue.edu (Stephan Bechtolsheim) Subject: TeXhax Digest V91 #002 Keywords: TeX Sie muessen plain.tex 3.0 und nicht 2.9.... dafuer verwenden. \lefthyphenmin, \righyhyphenmin, .... Or in English: you need to use plain.tex 3.0 and not 2.9..... \lefthyphenmin, \righyhyphenmin, .... Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ------------------------------------------------------------------------ Date: 01/28/91 15:43:42 GMT+1 From: UO04%DDAGSI3@UWAVM.U.WASHINGTON.EDU Subject: Graphics, TeX, Metafont Keywords: Graphics, TeX, Metafont H.Friedrich Kammer 0441/798-3467 FB Physik Theorie Universitaet Oldenburg Postfach 2503 D-2900 Oldenburg FRG In recent time I have developed a new way to include graphics in TeX documents. I did this mainly for my own purposes - people, who are in a similar situation like me might also find this useful. Purpose: What I usually want to do is the inclusion of the output of a cer- tain graphics system in a TeX-document with same resolution etc. - NOT programming graphics in TeX directly (as PiCTeX enables). I am user of three different computers, one far away and with no access to its plotter output; the printer with best resolution I can use does not understand POSTSCRIPT. So site- and device- independent graphics are really important for me, and I need anyway some effort to get my output. What I usually have to do: - attach a vector handler to the graphic system, which creates basic METAFONT code. Many graphic systems offer such features; I use DISSPLA (product of ISSCO) and some special GDF-file inter- preter, which is used on the GSI computer center. - run METAFONT on the output - I have to do this for any output device I use (of course also GftoPXL etc. if necessary) - include the produced 'font' in TeX with a certain macro Advantages of the method: - DVI files remain small (different from PiCTeX) - no memory problems in TeX, except you use 30 or more pictures and many fonts in the same document (e.g. with SlITeX) - anything is fully device- and site-independent: pictures and text can be sent to any device and are printed in the same resolution Disadvantages: - GF and PXL files become very large - any device needs its own MF and conversion run - some DVI drivers still crash because of memory problems - long way from picture creation to final output Method: METAFONT is driven like a silly plotter - only few commands and features are used. The METAFONT input defines a matrix of 'characters', which contain the vectors created from the graphics system. It is NOT possible to pack one picture into one character - either METAFONT of GFtoXXX or the respective DVI drivers die on memory problems then. Usually characters have a size of less than 0.8x0.8in - this enables still picture sizes of about 12.8x12.8in (or rectangles with one side longer, the other shorter). The splitting of vectors gives some overhead, but most vectors are much shorter than the character dimensions (to form markers or graphics letters). Installation: For site-dependent reasons the vector-handler program is written in FORTRAN - DISSPLA and C do not run together under VM/CMS (which is on one of the sites I use). Together with DISSPLA the installation is simple: compile the program and call the respective device driver in the user program - DISSPLA does the rest. Other graphics systems will probably need recompilation and -binding. People who are interested will get the package, including program and some sample program, text and graphics. If anybody is interested in placing it on some server, I will not mind. Questions and remarks to 115358@DOLUNI1.BITNET and UO04@DDAGSI3.BITNET Friedrich Kammer ------------------------------------------------------------------------------ Date: 06 Feb 91 06:31:33+0100 From: Laurent SIEBENMAN Subject: posting on special Keywords: dviware, EPSF graphics EPSF integration via \specials --- a gentle path out of chaos Back in October 1990, Teresa A. Ehling, and Berthold K.P. Horn of Cambridge Mass posted an open letter on integration of EPSF 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 EPSF 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 surely not the first package to offer all of them well knitted together. However, the packages that have come to my attention are attached to a driver and/or make a point of using PostScript where possible --- with consequent limitations on portability. This one uses TeX alone and no Postscript code at all; it is built for portability with lowest-common-denominator requirements on the driver. Currently, it is 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, shunning PostScript code, it cannot explicitly support sophisticated PostScript features such as header dictionaries, clipping, rotations, distortions etc. The initial list of \Set...EPSFSpecial commands for support of specific drivers is: %%\SetTexturesEPSFSpecial for Textures %%\SetArborEPSFSpecial for ArborTeX %%\SetOzTeXEPSFSpecial for OzTeX %%\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. To let me extend support to your 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, and others 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 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. But it will not 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 three references that may give you leads to alternative solutions. --- dvips and epsf.tex by by T. Rokicki --- Nicolas Jungers two postings in the GUTenberg forum 9 Nov 90 and 17 Nov 90 --- PSFIG a package by Trevor Darrell (for LaTeX and several 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. PS. How are the EPS graphics files being created? a) DrawOver 1.0 copyright Michael Everest, 1986 is a converter to EPSF from the PICT graphics norm of the Macintosh (prefer early versions!), for which there are many excellent drawing programs such as MacDraw. DrawOver is distributed with Illustrator 88 on the Mac. 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! -------------------------------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 square.ps into the same folder as % TeX and this testfile. Hopefully this will make % square.ps accessible to the printer driver. % % --- Complete the \special{... square.ps ...} command below % as your driver documentation recommends for printing % the EPSF file square.ps --- without any scaling, or other % refinement. For example % \special{ps: epsfile square.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 square.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{... square.ps ...}%% please carefully adjust this \eject \bye -------------------------------cut %!PS-Adobe-2.0 %%Title: square.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 .02 setlinewidth stroke -------------------------------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 square.ps scaled to 76 percent using a command of the form \special{... square.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 ----------------------------------------------------------------------- %%% Further information about the TeXhax Digest, the TeX %%% Users Group, and the latest software versions is available %%% in every tenth issue of the TeXhax Digest. %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% %%% BITNET: send a one-line mail message to LISTSERV@xxx %%% SUBSCRIBE TEX-L % to subscribe %%% or UNSUBSCRIBE TEX-L %%% %%% Internet: send a similar one line mail message to %%% TeXhax-request@cs.washington.edu %%% JANET users may choose to use %%% texhax-request@uk.ac.nsf %%% All submissions to: TeXhax@cs.washington.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% JUNE.CS.WASHINGTON.EDU TeXhax/TeXhaxyy.nnn %%% yy = last two digits of current year %%% nnn = issue number %%% %%%\bye %%% End of TeXhax Digest ************************** -------