TeXhax Digest Wednesday, October 5, 1988 Volume 88 : Issue 86 Moderator: Malcolm Brown Today's Topics: DVI output on the HP DeskJet (why you probably don't want it) TeX Users Group Meeting Inquiry TeX/LaTeX math <=> Macsyma Form letters RE: PSPRINT and DVITOVDU Re: BibTeX documentation Bug in good.top and good.bot? Unix TeX in C Re: Problem installing TeX (V88 #80): compiler limits Re: Postscript, figures, and typesetters small caps (TeXhax Digest V88 #84) Page Make-up Chalenge ---------------------------------------------------------------------- Date: Sat 24 Sep 88 18:58:13-MDT From: "Nelson H.F. Beebe" Subject: DVI output on the HP DeskJet (why you probably don't want it) In TeXhax Digest V88 #83, Mary Coventry writes: >> Is there a driver for the HP Deskjet printer yet? Since I have received a few phone calls and Email queries about this same question, it seems worthwhile to repeat what I told them. The following text is lifted from one of my recent replies (14-Sep-88): >> I talked last week to David Babcock at HP Palo Alto about >> the DeskJet. He has a driver running for it, but doesn't >> view it as a satisfactory TeX output device. The problem is >> that it is a 300dpi printer, but has no memory of any >> consequence. It supports only 4 downloaded fonts, but has >> no page bitmap to record characters in, so it cannot do TeX >> that way. Although many of its commands are compatible with >> the HPLJ, its font download sequence is different. The only >> way then to drive it is via full-page bitmaps sent from the >> host. 8.5 x 11 x 300 x 300 / 8 = 1.05Mb; 6.5 x 9 x 300 x >> 300 / 8 = 658Kb. Thus at 9600 baud, or 960 char/sec, it >> will take 685 to 1090 sec (10 - 20 minutes) per page, which >> is just plain awful. The HPLJ Plus or II will do about 7 >> pages/minute with my drivers. If you really want to go >> ahead, use dvijet.c (NOT dvijep.c), and change the >> resolution from 100dpi to 300dpi (XDPI and YDPI), and adjust >> the resolution in the raster header. That is, a TeX DVI driver for the DeskJet is not at all impossible, but will not likely be satisfactory. ------------------------------ Subject: TeX Users Group Meeting Inquiry Date: 24 Sep 88 22:09:20 EDT (Sat) From: encore!cloud9!jjmhome!lmann@bu-cs.bu.edu (Laurie Mann) I gave a paper at the recent TUG meeting on macros for conditionalized text. At the conference, about 10 people gave me their business cards, and I said I'd be happy to send them the macros. Unfortunately, I went on vacation the week after the conference, and have been unable to find the business cards I collected. If you are interested in the single-sourcing macros, please write to me or send me E-mail and I'll get them to you. /*Common gopher button at Nolacon: It's not MY convention, monkey boy!*/ Hacking net address: {harvard,ulowell}!m2c!jjmhome!lmann ** lmann@jjmhome.UUCP Working net address: harvard!anvil!es!Laurie_Mann (Stratus Computer) uS(n)ail: Laurie Mann, Stratus, M22PUB, 55 Fairbanks Blvd, Marlboro, MA 01752 ------------------------------ Date: Sun, 25 Sep 88 21:06:04 EDT From: Mark W. Eichin Subject: TeX/LaTeX math <=> Macsyma Does anyone have code or ideas for easily converting from Macsyma equation output (any form) to LaTeX or TeX mathematical input? I would guess that this could take the form of lisp code for Macsyma, or gnuemacs-lisp code to convert while editing the document, or maybe a standalone processing program. I'd also be interested in information on other conversion to or from TeX/LaTeX math representation. Mark Eichin SIPB Member & Project Athena ``Watchmaker'' ps. Please reply by email; we haven't gotten any digests since August. ------------------------------ Date: 26 Sep 88 0:34 -0500 From: Michael Doob Subject: Form letters MURALI@TAMLSR in TeXhax vol. 81 asks how to do form letters. The following setup will handle form letters that are not too bizarre: (1) Put your macros (perhaps \today and such) in one file, say lmacs.tex. (2) Put your form in a file, say lform.tex. It might contain a fragment of the following type: \vglue .5in \leftskip \longindentation \today \vskip \baselineskip \begingroup \obeylines \parindent=0pt \sal\ \firstname\ \lastname \address \city \vskip \baselineskip Dear \sal\ \lastname, \vskip \baselineskip \endgroup ... Continue with the body of the letter . \vfill \eject (3) Now make the file of records to be inserted into the form: \input lmacs \def\sal{Mr.} \def\firstname{John} \def\lastname{Doe} \def\address{123 Main Street} \def\City{Smalltown, AA 12345} \input lform \def\sal{Ms.} \def\firstname{Jane} \def\lastname{Roe} \def\address{341 Oxford Street} \def\city{Bigcity, ZZ 54321} \input lform This last file is run through TeX to get the processed list. Michael ------------------------------ Date: Fri, 23 Sep 88 16:28 EDT From: Ted Nieland - SRL <@WPAFB-AAMRL.ARPA:TNIELAND@FALCON> Subject: RE: PSPRINT and DVITOVDU Newer version of PSPRINT and DVITOVDU have made it to America. Our friends from Italy sent a copy over. The new versions are PSPRINT 2.0 and DVITOVDU 2.0. This material is available on the new DECUS TeX Distibution Tape. It is available from the DECUS Library. I am willing to get the PSPRINT and DVITOVDU to some site who would like to make it available for anonymous FTP. I can either deposit on such a system or send them a tape with the material. I did send a copy of the DECUS distribution to TUG (via Barbara Beeton). NOTE: The new DECUS TeX Collection will be made available through DECUS LUGS at a later date as part of the 1988 Language and Tools Collection. The DECUS TeX Tape is VMS based, but does include material for UNIX and MS-DOS. It is a fairly complete TeXware collection and contains the following: TeX 2.93 TR2TEX LaTeX 2.09 PSPRINT 2.0 AMSTEX DVITOVDU 2.0 TeXsis DVI2PS PICTeX PSFIG RNOtoTEX GLOTeX DVI2LN3 IDXTeX The Utah DVI Driver Collection MAKEINDEX MetaFont 1.5 LN03 PK Fonts LSE Template DVIDIS CDVI for MS-DOS DVIEW for MS-DOS DVIVGA for MS-DOS PK Fonts for MS-DOS LaTeX Style Collection SPELL (VMS Spelling checker that knows TeX and LaTeX) Any suggestions for additions to the DECUS TeX Collections should be sent to TNIELAND@WPAFB-AAMRL.ARPA. | M. Edward (Ted) Nieland - Systems Analyst | US Snail: | Arpa Internet: | | Systems Research Laboratories, Inc. | TNIELAND@WPAFB-AAMRL.ARPA | 2800 Indian Ripple Road WP 196 | TNIELAND%FALCON@WPAFB-AAMRL.ARPA | Dayton, OH 45440 | | A T & T: (513) 255-8846/8760/5156 ------------------------------ Mail-From: PATASHNIK created at 26-Sep-88 06:23:58 Date: Mon 26 Sep 88 06:23:57-PDT From: Oren Patashnik Subject: Re: BibTeX documentation > From: toms@ncifcrf.gov > Subject: Re: yaffb (yet another format for bibtex) > Fortunately, I contacted Stephen Gildea, who kindly sent documentation > to me (it is called btxdoc.tex), and so I could finish the task. That was very nice of Stephen, but he shouldn't have had to do that. The file BTXDOC.TEX resides in BibTeX's standard distribution area on SCORE.STANFORD.EDU, and it should be distributed along with the rest of the BibTeX software. If there's something missing on your system you should complain to your system's LaTeX/BibTeX installer or to whoever sends you your distribution tapes (and/or FTP it from SCORE.STANFORD.EDU). > Oren Patashnik, your long letters were useless, though your un-named > language is lovely. If you had simply said > 'Well, I understand your desire for switches, but it is much more powerful > to define a whole language! Here is the document for the language.' > it would have kept me (and probably lots of other people) out of a bunch > of blind alleys.) Gee, I just reread the message I sent you, and I think it was pretty informative. In particular it said: There are infinitely many possible bibliography styles, but a set of switches can produce only finitely many styles, so this scheme isn't general enough. You need a programming language for full flexibility, which is why the .BST language exists. So I had said, in essence, what you just asked for. > I think that this language should be documented in the LaTeX book. I doubt Leslie Lamport wants to include the documentation in his book; it exists, however, in the files BTXBST.DOC and BTXHAK.TEX, which are in BibTeX's standard distribution area. I understand the frustration of trying to work without adequate documentation. But in this case the documentation exists, and it's just a matter of making sure that users *know* of its existence. I suggest, if they haven't already done it, that BibTeX installers state in their _Local Guide_ exactly where on their system the BibTeX documentation resides. --Oren Patashnik ------------------------------ Date: Mon, 26 Sep 88 15:43:05 BST From: CET1%phoenix.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK Subject: Bug in good.top and good.bot? In the following definitions from plain.mf (or p.273 of the MFbook) vardef good.lft primary z = save z_; pair z_; (z_+(pen_lft,0))t_=round((z+(pen_lft,0))t_); z_ enddef; vardef good.rt primary z = save z_; pair z_; (z_+(pen_rt,0))t_=round((z+(pen_rt,0))t_); z_ enddef; vardef good.top primary z = save z_; pair z_; (z_+(pen_top,0))t_=round((z+(pen_top,0))t_); z_ enddef; vardef good.bot primary z = save z_; pair z_; (z_+(pen_bot,0))t_=round((z+(pen_bot,0))t_); z_ enddef; surely the last two are wrong? Should the quantities added to z_ not be (0,pen_top) and (0,pen_bot) respectively? Certainly use of good.top and good.bot seems to give me anomalous results. It seems that the CM definitions use only good.x and good.y. Chris Thompson JANET: cet1@uk.ac.cam.phx ARPA: cet1%phx.cam.ac.uk@nss.cs.ucl.ac.uk ------------------------------ Date: Mon, 26 Sep 88 13:42:04 EDT From: russ@baklava.mitre.org (Russell Leighton) Subject: Unix TeX in C Could someone please tell me where I can obtian a C TeX version for our Unix systems? Please email: russ@mitre.arpa Thanks, Russ ARPA: russ@mitre.arpa Russell Leighton M.S. Z406 MITRE Signal Processing Lab 7525 Colshire Dr. McLean, Va. 22102 USA ------------------------------ Date: Mon, 26 Sep 88 14:09:29 EDT From: Chris Torek Subject: Re: Problem installing TeX (V88 #80): compiler limits Pierre is right about it being hard to diagnose this error at a distance, but in this case I know something about the implementations of both the compiler on the 3B2/400 and the Unix `yacc' utility. The 3B2 compiler is a variant of a descendent of PCC. PCC generates switch/case statements by accumulating the case constants in a table of---alas!---fixed size. The table is then sorted, and one of three switch algorithms is used depending on the density and number of cases (direct jump, heap comparison, or direct comparsion). The switch table overflow means that this table has been filled, not that the parser has run out of space; breaking up the cases (without doing anything about the switch itself) will have no effect. The problem with yacc, on the other hand, is that the *parser* runs out of stack space. Yacc produces a conventional LALR(1) parser. It too has a fixed array for its parse stack. Alas, it does not even check for overflow, and simply misbehaves by overwriting whatever is in the memory beyond the parse stack. (There may be some yaccs that check, but I have not heard about them.) The solution for this is to shun right recursion in yacc grammars. The real fix, of course, is not to use fixed-size tables. But then, even TeX itself has fixed-size arrays. There is an excuse for this in Pascal: new and dispose are, for some reason, considered `unnecessary' by many compiler writers, and if implemented at all, often poorly so---I know of several Pascals in which `dispose' is a no-op. So it goes. Even compilers without built-in limits are limited by the environment in which they are run. And TeX certainly stresses these limits! Incidentally, GF and DVI utilities could make use of a scheme I use in my own file reading software. Compilers often limit code more than they do data. (`No one would ever write 165 cases! It would take too long to type! ... What's a macro?') The trick is to use a table to compress the 256 opcodes into a smaller number of classes. Instead of case opcode in four_cases(X): code for X; sixty_three_cases(Y): code for Y; ... end; one writes var class_table : array [0..255] of class_type; ... case class_table[opcode] in class_X: code for X; class_Y: code for Y; ... end; Curiously, the result often runs faster. Chris ------------------------------ Date: Mon, 26 Sep 88 16:26:20 CDT From: William LeFebvre Subject: Re: Postscript, figures, and typesetters > The output [from the typesetter] was fine except that the only PS > figure was rotated 90 degrees and translated into the wrong column of > the two column output....Has anyone patched dvi2ps to work on both LWs > and some PS typesetter? [ duck....there's sarcasm ahead... ] Silly me! I thought PostScript was supposed to be universal. I thought it was supposed to produce the same results on all printers that supported it. I guess I was mistaken. [ Is it now my turn to duck? ] William LeFebvre Department of Computer Science Rice University ------------------------------ Date: Mon, 26 Sep 88 16:22:33 PDT From: mackay@june.cs.washington.edu (Pierre MacKay) Subject: small caps (TeXhax Digest V88 #84) The computer modern basic set has cmcsc10.mf and cmtcsc10.mf (typewriter CSC) The file csc.mf shows how the game is played, so other sizes could be generated without too much hacking. This version of caps and small caps e x t e n d s the small caps, and we have found it necessary, in an environment where we need to use a lot of csc, that we had to make up a wmcscc? set (Washington Modern small caps condensed). This is effectively the same as eight point caps beside ten-point caps. We feel it works better on a page where there are many small caps entries (Middle East Studies Association Bulletin -- Conferences and News of Members). There is presumably a converter from gf files to whatever you are using for your output device. It won't give you postscript, though. what you get is rasterized, and is fed to postscript as a hardwired bitmap. If you have any use for wmscc?? you are most welcome. All in the family, as we might say. What are you using for Greek? Adobe's largely unaccented Greek or Silvio Levy's fully accented set? Email: mackay@june.cs.washington.edu Pierre A. MacKay Smail: Northwest Computer Support Center TUG Site Coordinator for Lewis Hall, Mail Stop DW10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 ------------------------------ Date: Sat, 24 Sep 88 16:11:49 EDT From: "David F. Rogers" Subject: Page Make-up Chalenge Below is a copy of a paper that will appear in the next TUGboat. It is included here (with Barbara Beeton's permission) to insure wide distribution (some people who get texhax do not belong to TUG) and so that all you macro and output routine wizards can get a head start on the Challenge. Really, what is needed is a good constructive discussion of possible solutions to the problem outlined below. A Page Make-up Challenge The Problem I have been involved with typesetting relatively complex mathematical and engineering textbooks using TeX since late 1982. These are books that are typically 5-600 pages long with an average of more than a figure per page. Further, the text is liberally endowed with large complex display equations and tables both normal and turned. TeX's page make-up abilities are woefully lacking for this application. This lack is perhaps understandable since Knuth's design goal was to develop a system capable of consistently and beautifully typesetting the volumes of the Art of Computer Programming. Art of Computer Programming volumes contain few figures, large display equations or turned tables in the text. Publishers impose rather stringent page make-up requirements for figure placement in engineering, science and mathematical textbooks. Typical requirements in priority order are: 1. Numbered figures must be inserted in numerical sequence. 2. Numbered figures must be inserted after the first reference to the figure. 3. Numbered figures are to be placed flush left at the top or bottom of the page with minimum 1 1/2 pc and maximum 2 1/2 pc above and/or below to text. 4. Numbered figures should be visible from the first reference. 5. If page make-up places a numbered figure several pages after it's first reference, then and {\it only} then, may it be placed {\it before} it's first reference. However, it {\it must} be visible from it's first reference. Figure caption rules somewhat further complicate the problem. Examples for a standard 29 pc page width are: 1. Numbered figures 19 to 29 pc wide have the figure caption positioned flush left 1 pc below the figure by the page measure (\hsize) 2. Numbered figures less than 19 pc wide have the figure caption positioned 1 pc to the right of the figure by the remainder of the page width and based-aligned with the figure. 3. Sequentially numbered figures less than 13 pc wide are placed side-by-side in 13 pc wide boxes separated by a 3 pc space. Figure captions are placed flush left 1 pc below each box. Considering that TeX 's output routines do not look ahead very well, it is easy to see that such page make-up rules seriously complicate the task of typesetting and making-up a book of this nature. The Current Solution In applications of this nature both Plain TeX's \topinsert and \midinsert commands are known not to work. Further, LaTeX 's floating insert commands also do not work. Consequently, it is necessay to essentially do the page make-up by hand {\it using a computer}! The technique (TeXnique??) is conceptually simple and very labor intensive. The manuscript is broken up into 30-50 page segments within chapter boundaries (a chapter is assumed to always begin on a recto page). The segment is TeX'd. For the pages preceeding the first figure reference, white space is inserted or deleted to both balance the length of facing pages and to keep the page length within acceptable parameters. No, TeX does not always do it quite correctly, i.e. according to the page make-up rules. Immediately after the first figure reference, white space equal to the figure size is inserted along with the figure caption. If there is sufficient space at the bottom of the page containing the figure reference, called the current page, it is inserted there, if not, it is moved to the top of the next page. To reiterate, conceptually this technique is quite easy, in practice it is quite difficult. Adding white space and the figure caption to the bottom of the current page must be done by measuring up from the bottom of the page, finding the exact end of line corresponding to the required figure space plus the space occupied by the figure caption and inserting the white space and figure caption at that point in the manuscript. To prevent TeX from reformating the pages to this point a \vfill\eject is placed at the bottom of the previous page. This, of course, does not always work. TeX occasionally decides that the previous material is best presented with an incomplete last line! When this happens material is moved -- word-by-word -- from the current page to ahead of the \vfill\eject on the previous page until the result is correct. A similar technique is used when the figure is placed at the top of a page. A combination of the techniques is used when both a top and bottom figure appear on the same page. The {\it fun} really begins when a page contains large display equations or large numbers of display equations and both top and bottom figures. The result is a long, possibly nonconverging, iteration process. As Reference 1 illustrates, doing a book of this type with TeX is quite possible. It is just a bit painful. Unfortunately, it is also not cost effective. Currently, it is less expensive for a book publisher to simply typeset the manuscript using TeX without including figure captions or spaces and use the traditional Xacto knife and glue pot page make-up technique. That offends me, as I am sure it does you. The Challenge My initial thought was to simply write a \bottominsert macro similar to the \topinsert and \midinsert macros. However, discussions with output routine guru's at the recent Montreal TUG meeting have convinced me that this will not work, at least not very well. The Challenge then is for the output macro guru's to write a figure placement macro that incorporates items 1--3 above (4 and 5 can be handled manually). The suggested calling sequence for the macro is \figplace#1#2#3#4 where #1 is the vertical dimension of the white space to be left for the figure. #2 is the horizontal dimension of the white space to be left for the figure. #3 is the figure number. #4 is the figure caption. The assumption is that a custom figure caption macro is used within the figure placement macro. A sample figure caption macro might be: % define a figure caption macro % #1 is the figure number #2 is the caption % the caption is to be set in a `box' left and right justified 1em to % the right of the figure number % the size to the box containing the word Figure, its number and the 1em % skip is found in box0 % box1 is \hsize less the width of box0. % a \vtop is used along with an \halign to obtain the flush left and right % effect. \def\figcap#1#2{{% \setbox0=\hbox{{\bf Figure #1}\hskip 1em}% \setbox1=\vtop{\advance \hsize by -\wd0 \noindent \spaceskip=.3em plus .2em minus.2em #2} \halign{## & ## \cr \box0 & \box1 \cr}} \bigskip % put some space below the figure caption } Unfortunately, other commitments as well as my current level of expertise prevents me from attempting this job. References 1. Rogers, David F. Procedural Elements for Computer Graphics, McGraw-Hill Book Co., New York, 1985. COMMENTS to date: Upon receiving the paper Barbara Beeton commented (\it summarized): If you want to force a line to the full width at the end of a paragraph, you can say \parfillskip=0pt\endgraf and it will happen. You have to reset \parfillskip to the default, or bury the whole mess in a group, to get the following paragraphs to end normally. Note -- the \endgraf freezes whatever \parfillskip is in effect when the \endgraf happens; that means you can't separate the \parfillskip from the \endgraf by a }. How about \newskip\normalparfillskip \normalparfillskip=\parfillskip \def\MidParPageBreak{ \unskip \parfillskip=0pt\endgraf \eject \parfillskip=\normalparfillskip } Then you'd only have to move one `whatever' in case you had to adjust. With the \unskip, \MidParPageBreak could be put on a line by itself with a string of %%% following it so it can be spotted easily. dfr replied (expanded a bit here): This will work provided that the line is only 1 or 2 words short. However, if TeX is being obstreperous and ends the paragraph in the middle of the last line, then using \parfillskip=0pt results in a poorly set paragraph. For example, Knuth discusses doing this in the first paragraph on page 100 of the TeXbook. However, I mildly object to the setting of this paragraph. Notice the extra space (about 3 pts) before the You at the end of the third line from the bottom of the paragraph. Compare with the You in the next to last line 3 paragraphs below. Further, this only helps make using the Current Solution easier. It doesn't solve the fundamental problem. Let's keep the comments about this aspect of the problem to a minimum. So all you output and macro guru's have at it. Professor David F. Rogers Aerospace Engineering Department U.S. Naval Academy Annapolis, MD 21402 USA Tel: 301-267-3283/4/5 INTERNET: dfr@usna.mil UUCP: ~uunet!usna!dfr ------------------------------ %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% BITNET: send a one-line mail message to LISTSERV@TAMVM1.BITNET: %%% SUBSCRIBE TEX-L % to subscribe %%% %%% All others: send mail to %%% texhax-request@score.stanford.edu %%% please send a valid arpanet address!! %%% %%% %%% All submissions to: texhax@score.stanford.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% [SCORE.STANFORD.EDU]TEXHAXnn.yy %%% nn = issue number %%% yy = last two digits of current year %%%\bye %%% ------------------------------ End of TeXhax Digest ************************** -------