========================================================================= Date: Sun, 3 Feb 91 09:59:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Secretary for the group (was RE: re:Joachim's comment) Since no one else has volunteered, I'll go ahead and declare Joachim to officially be the secretary for the group. All subsequent amendments etc. should be sent to him for distribution (I'll still handle keeping up the FTP archive on ymir). -dh ========================================================================= Date: Wed, 6 Feb 91 19:55:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Forwarded note on \special From: IN%"lcs@matups.matups.fr" "Laurent SIEBENMAN" 5-FEB-1991 21:33:18.88 To: Beebe@csc-sun.math.utah.edu, DHosek@YMIR.CLAREMONT.EDU, EHLING%MITVMA@UW AVM.U.WASHINGTON.edu, TeXhax@cs.washington.edu, uktex@uk.ac.aston CC: Subj: posting on special Return-path: <@mirsa.inria.fr:lcs@matups.matups.fr> Received: from mirsa.inria.fr by YMIR.CLAREMONT.EDU with PMDF#10000; Tue, 5 Feb 1991 21:31 PST Received: from pamir.inria.fr by mirsa.inria.fr with SMTP (5.61+++/IDA-1.2.8) id AA20228; Wed, 6 Feb 91 06:31:15 +0100 Date: 06 Feb 91 06:31:33+0100 From: Laurent SIEBENMAN Subject: posting on special To: Beebe@csc-sun.math.utah.edu, DHosek@YMIR.CLAREMONT.EDU, EHLING%MITVMA@UWAVM.U.WASHINGTON.edu, TeXhax@cs.washington.edu, uktex@uk.ac.aston Message-id: <665818293.11751.0@matups.matups.fr> X-Envelope-to: dhosek X400-received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 06 Feb 91 06:31:05+0100 X400-received: by /PRMD=reunir/ADMD=atlas/C=fr/; Relayed; 06 Feb 91 06:28:05+0100 X400-received: by /PRMD=matups/ADMD=atlas/C=FR/; Relayed; 06 Feb 91 06:31:33+0100 The following is a submission to TeXhax and/or UKTeX Yours cordially, 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!) larry@function.mps.ohio-state.edu (temporary) Tel 33-1-6941-7949; -4735-8862; -4655-7885 Fax number: 33-1-6941-6221 ~t TeXhax@cs.washington.edu ~t uktex@uk.ac.aston ~t EHLING%MITVMA@UWAVM.U.WASHINGTON.EDU ~t DHosek@ymir.Claremont.edu ~t Beebe@science.utah.edu 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 the 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 among TeX users. 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. The 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 concentrate their efforts on the TeX file. With this nuance, I agree that that our graphics insertions, like theirs, 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. This 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, 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 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 \special{... square.ps ...} %% please carefully adjust this %% \special command before typesetting! \vskip-1in \kern 1 in \rule height 1 in width 1in \eject \bye -------------------------------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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -------------------------------cut ========================================================================= Date: Wed, 6 Feb 91 19:56:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Update to forwarded posting on \special From: IN%"lcs@matups.matups.fr" "Laurent SIEBENMAN" 5-FEB-1991 21:43:10.18 To: Beebe@csc-sun.math.utah.edu, DHosek@YMIR.CLAREMONT.EDU, EHLING%MITVMA@UW AVM.U.WASHINGTON.edu, TeXhax@cs.washington.edu, uktex@uk.ac.aston CC: Subj: special posting corrected Return-path: <@mirsa.inria.fr:lcs@matups.matups.fr> Received: from mirsa.inria.fr by YMIR.CLAREMONT.EDU with PMDF#10000; Tue, 5 Feb 1991 21:42 PST Received: from pamir.inria.fr by mirsa.inria.fr with SMTP (5.61+++/IDA-1.2.8) id AA20483; Wed, 6 Feb 91 06:41:28 +0100 Date: 06 Feb 91 06:41:45+0100 From: Laurent SIEBENMAN Subject: special posting corrected To: Beebe@csc-sun.math.utah.edu, DHosek@YMIR.CLAREMONT.EDU, EHLING%MITVMA@UWAVM.U.WASHINGTON.edu, TeXhax@cs.washington.edu, uktex@uk.ac.aston Message-id: <665818905.11751.0@matups.matups.fr> X-Envelope-to: dhosek X400-received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 06 Feb 91 06:41:16+0100 X400-received: by /PRMD=reunir/ADMD=atlas/C=fr/; Relayed; 06 Feb 91 06:38:16+0100 X400-received: by /PRMD=matups/ADMD=atlas/C=FR/; Relayed; 06 Feb 91 06:41:45+0100 The following is a CORRECTED submission to TeXhax and/or UKTeX. I sent an incomplete draft a few minutes ago!! Yours cordially, 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!) larry@function.mps.ohio-state.edu (temporary) Tel 33-1-6941-7949; -4735-8862; -4655-7885 Fax number: 33-1-6941-6221 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -------------------------------cut ========================================================================= Date: Wed, 20 Feb 91 10:56:55 +0100 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Eberhard Mattes Subject: Number of pages Implementors of DVI drivers for small systems beware! As a rule, \DVI\ processors must be able to interpret any {\tt DVI} file which falls within the following limits. This means, DVI drivers must be able to process DVI files containing up to 65535 pages. If a driver reads all the page numbers into memory before deciding which pages should be printed, 11*4*65535 bytes of memory are required (10 page numbers and the address of the BOP command for every page). That are about 2.75 megabytes. Keeping only \count0 for every page and storing \count1 to \count9 only if non-zero doesn't help for all DVI files: \count42=1 \count17=314159265 \count0=0 \def\strange{\count\count42=\count17 \advance\count17by1 \advance\count42by1 \ifnum\count42<10\let\next\strange\else \count42=1 \shipout\hbox{}\advance\count0by1 \ifnum\count0<65535\let\next\strange\else\let\next\relax\fi\fi \next} \strange \end The current release of the emTeX drivers can handle 1364 pages, the Beebe drivers 1000 pages. Unfortunately, the (rather complex) page selection scheme of the emTeX drivers requires multiple passes through the list of pages, so it would be nice if I could keep the list in memory. Remembering only the BOP pointers in the sequence in which the pages should be printed still requires up to 4*65535 bytes of memory; that's too much for some popular machines, as one needs the memory space for more important data. Ok, I am too late now: It would have been nice if the standard had specified `up to 2000 pages' or something like this. BTW, TeX doesn't complain if you try to generate more than 65535 pages. It either crashes or creates an invalid DVI file, depending on the implementation. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)