TeXhax Digest Wednesday, February 24, 1988 Volume 88 : Issue 20 [SCORE.STANFORD.EDU]TEXHAX20.88 Editor: Malcolm Brown Today's Topics: Strange Interaction in Latex LaTeX style and indented 1st paras DVI2LN3 V12.3 Possible fix for VMS METAFONT V1.3(?) delatex Times Roman in Metafont tbl to TeX halign wanted generalizing \boxit with \leaders type construction for border More on transferring DVI files to VAX VMS cmnaro? LaTeX Notes (TeXhax V88 #18) standardizing dvi2ps TeX-to-C Padding dvi files hanging letters More Common TeX vs. TeX-to-C benchmarks Metafont mode_def settings for Dataproducts LZR-2665 Re: stripping comments from .sty files RE: Flame; LaTeX Notes indentation question ---------------------------------------------------------------------- From: VARDI%ALMVMA.BITNET@forsythe.stanford.edu Date: 18 Feb 88 17:30 PST Subject: Strange Interaction in Latex In the following example, there is a strange interaction between the \small, the theorem environment, and the enumerate environment. If you Latex it as it is, the items of the list are indentened to the left of the left margin. Take away the \small, and the items are indented properly. Moshe Vardi vardi@ibm.com, vardi@almvma.bitnet \documentstyle[12pt]{article} \begin{document} \newtheorem{theorem}{Theorem} Here is some text. This is simple text. There is nothing special about this text. There is absolutely nothing special about this text. \small Here is some text. This is simple text. There is nothing special about this text. There is absolutely nothing special about this text. \normalsize Here is some text. This is simple text. There is nothing special about this text. There is absolutely nothing special about this text. \begin{theorem} Here is some text. This is simple text. There is nothing special about this text. There is absolutely nothing special about this text. \begin{enumerate} \item Here is some text. \item Here is some text. \end{enumerate} \end{theorem} \end{document} ------------------------------ Date: Fri, 19 Feb 88 00:45 GMT From: Peter Flynn UCC Subject: LaTeX style and indented 1st paras Julian Bradfield takes Leslie Lamport to task for his abrasive style. That may be so, I happen to like some of his more caustic comments, but then that may just be *my* style. The issue is, who is the arbiter of typographic elegance? Is it the document designer or the reader? (I can't answer this one, I doubt if anyone can.) JB seems to be complaining that LL dislikes people requesting mods to LaTeX style, when in fact people are quite free to make the mods themselves, it's a question of whether *they* should ask LL to install those mods as standard or not. LaTeX as delivered is LL's baby: people who want it different should do it themselves, document it, and submit it to the list for general consumption, but not expect LL to accept it as a de facto standard. (I am excluding actual bug fixes from this, of course.) BTW, non-indented 1st paras are quite nice. They are an improvement to the appearance when \parindent is quite small (a few ems) because they lead to a less lop-sided feel when preceded by a lot of vertical white space, which you typically get (a) at the start of a document, (b) after an itemised list, (c) after a change in the \leftskip, (d) after display math. The (d) is done automatically by TeX, anyway, isn't it? I don't use LaTeX, so I can't say if (b) and (c) apply, but they ought to, if (a) applies. If, as some people do, you set \parindent=\hsize \divide\parindent by2 and then use a grouped \parindent=4em for \item etc, you can probably get away without de-indenting the 1st para, because the eye will pick up oddball formats like this more easily than more normal ones. Peter Flynn, University of Cork, Ireland ------------------------------ Date: Thu 18 Feb 88 21:37:54-PDT From: BELL%KUPHSX.SPAN@STAR.STANFORD.EDU (Did someone need a Subject: DVI2LN3 V12.3 Well, it seems that I didn't quite fix the problem with finding the correct PXL files under various magnifications in version 12.2 of DVI2LN3. I have now made DVI2LN3 figure out the correct magnification of the PXL files as best it can (given TeX's penchant for rounding off) and then checking that directory. If it can't find it there, it then checks directories with one more and one less than the magnification DVI2LN3 calculates. This means that it will check (for example) TeX$PXLDIR:[1643] first, and then [1644] and [1642] if it cannot find the file. This usually fixes the problem, as has been pointed out many times in past issues of TeXhax. I have already sent corrected versions of the necessary files to people who requested V12.2. If you requested the driver more than 2 weeks ago and have not yet received it, there are two possibilities: (1) You message got lost in the network; or (2) I tried to send the files, and the mailer(s) didn't like the address I gave. I only try once, so you might consider requesting the driver again. There have been no other enhancements of the driver, as my dissertation work has been taking up too much time lately. I'll try and keep everyone informed as to future upgrades. Ed Bell Dept. of Physics \& Astronomy The University of Kansas Lawrence, KS 66045-2151 (913)864-3610 Reply to (in order of preference for each net): ARPANET: Bell%KUPHSX.SPAN@STAR.STANFORD.EDU or Bell%KUPHSX.SPAN@JPL-VLSI.ARPA or Bell%KUPHSX.SPAN@128.8.250.4 BITnet: Bell%KUPHSX.SPAN@SU-STAR.ARPA or Bell@UKANVAX SPAN/HEPnet/ European Decnet: KUPHSX::Bell (7.220) or 7388::Bell THEnet: UTADNX::UTSPAN::KUPHSX::Bell ------------------------------ Date: Fri 19 Feb 88 07:25:49-PDT From: BELL%KUPHSX.SPAN@STAR.STANFORD.EDU (Did someone need a Subject: Possible fix for VMS METAFONT V1.3(?) I have noticed that several people have had some trouble lately generating a functional version of METAFONT V1.3 on VMS systems. Since our version has worked for some time now, I thought I would suggest something which I did last summer with V1.0. I was getting several PASCAL compiler errors and (at times) getting the program to outright blow-up in my face. It turned out that the VMS change file contained some lines that said something to the effect of "Change to fix V3.X bug". As soon as I deleted these sections of lines, the programs compiled and ran perfectly (at least it doesn't traceback). I don't know if the people having trouble have ever eliminated these lines from their change files, but it seems to me to be a good place to start. Ed Bell ------------------------------ Date: Fri, 19 Feb 88 07:27:22 PST From: jageorge@nla1.cs.utk.edu (J.ALAN GEORGE) Subject: delatex I would like to use spell on my LaTeX documents, and need the analog of deroff to remove the LaTeX control words, math, figures etc. from the file before running it through spell. Anyone have a sed script to do this? Alan George Mathematical Science Section Oak Ridge National Laboratory Oak Ridge, TN 37831 jageorge@ornl-msr.arpa ------------------------------ Date: 19 Feb 88 11:35:09 +1100 (Fri) From: munnari!wcc.oz.au!alw@uunet.UU.NET (Alex Warman) Subject: Times Roman in Metafont Does anyone know if a Times Roman has been produced in Metafont, either PD or for $$. I would be interested if some-one has Times Roman fonts for the Laserwriter too, even if they are not done with Metafont. In fact has any-one compiled a list of typefaces/fonts available, done in Metafont or with other tools, and availability/prices etc. ? thanks, Alex Warman (alw@wcc.oz) ------------------------------ Subject: tbl to TeX halign wanted Date: Fri, 19 Feb 88 12:33:23 PST From: Jeffrey Goldberg We have users running code that generates tbl input, but nobody here uses troff; we all use TeX. Does anyone have a filter that will take tbl input and generate useful TeX input? I may end up writing something myself, but I don't know tbl, and my TeX isn't that good either. Please send mail. I will post a summary of positive responses. (There is no need to post a summary of "Let me know what you find out" messages.) Thanks, jeff goldberg -- Jeff Goldberg Internet: goldberg@csli.stanford.edu ------------------------------ Date: Fri, 19 Feb 88 18:20 EST From: (Bob Jantzen, BITNET:JANTZEN@VUVAXCOM) Subject: generalizing \boxit with \leaders type construction for border Has anyone thought of putting together the Texbook \boxit macro (p.225) with a \leader type construction to replace the rules by repetitions of an arbitrary character, in such a way that the corners work out nicely, i.e., the corner copies of the character align both horizontally and vertically with the two leaders which meet there? Is this even possible? I must confess I haven't even solved the first problem which ignores corner effects. Bob Jantzen Villanova University Bitnet: jantzen@{villvm | vuvaxcom} Arpa: jantzen%{villvm | vuvaxcom}.bitnet@eddie.mit.edu UUCP: ...!vu-vlsi!excalibur!jantzen Snail: deptmathsciences villanova university villanova pa 19085 At&t: (215)645-7335 PS: rarely logon to ibm ------------------------------ Date: Thu, 18 Feb 88 09:36 DST From: Reid Rowlett Subject: More on transferring DVI files to VAX VMS Nelson Beebe reported his experience in TeXhax #16 with transferring DVI files from Unix to VAX VMS. I have encountered similar tribulations sending DVI files from a PC to a VMS system, and some TeXhax readers might be helped by what I discovered. Some of my problems may have been specific to the various software elements, so for the record, I was running Micro-TeX on my IBM-compatible PC, and using K&S IMPRINT (for VAX/VMS) to print the DVI files on an Imagen laser printer. The problem, as Beebe points out, is the over-elaborate (to my mind, anyway) record structure that VMS uses for all files. IMPRINT expects DVI files to have 512-byte fixed length records. Any other file format will cause IMPRINT to burp. Fortunately, there's a way out of the morass. I have two ways of transferring a DVI file from my PC to the VAX: Kermit and FTP (using Excelan Ethernet software). I use Kermit for reasonably short files, and FTP for longer ones, for reasons unimportant here. To use Kermit, one must tell the VAX Kermit to use "fixed" format, and the PC Kermit to use "binary" format. Kermit then luckily creates a VAX file with the proper record length. I was not so fortunate with FTP: a binary transfer from PC to VAX creates a file with "undefined, maximum 1024-byte length records", which IMPRINT cannot handle. The solution is to use the VMS FDL (File Definition Language) CONVERT utility to create a new file with the correct record structure from the old file after it has been FTP'd to the VAX. Being generally lazy and forgetful of VMS's endearingly multitudinous /THIS/THAT syntax, I created a one-line command file FIXUP.COM to do the work for me: $! FIXUP.COM -- Convert file to fixed-length 512-byte records $! Usage: @FIXUP $ convert/fdl=fixup 'P1'/pad 'P1' The CONVERT utility reads a file FIXUP.FDL which contains the specification for the new file (512-byte fixed length records) and then creates a new version of the file in that format. The FIXUP.FDL file should look like: RECORD BLOCK_SPAN yes CARRIAGE_CONTROL none FORMAT fixed SIZE 512 This can also be done interactively using EDIT/FDL (for masochists only). Of course, the DVI file on the PC must originally have a length which is a multiple of 512 bytes, which for Micro-TeX (or any TeX, I suspect) it does. I have other PC software that creates DVI files which do not have N*512-byte lengths, and I simply use DEBUG on the PC to pad them with zeroes out to a 512-byte multiple length before transferring. I hope this will be of use to some TeXhax-er out there. Reid Rowlett Unisys Corporation Reston Technology Center CSNet: rowlett@reston.unisys.com ------------------------------ Date: Fri, 19 Feb 88 16:43:04 CST From: hrp%windsor.CRAY.COM@uc.msc.umn.edu (Hal Peterson) Subject: cmnaro? When I first got a TeX tape, it contained a font called ``amnaro'': a bold, sans-serif font with tall, antique letters. It's ideal for chapter heading quotes. What happened to it? I haven't seen a cm equivalent, nor any parameter files. I can still use the old one, but I'd like more variety in size---there's only one amnaro. Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145 ------------------------------ Date: Mon, 22 Feb 88 11:11 N From: (Nico Poppelier) Subject: LaTeX Notes (TeXhax V88 #18) This is a small response to the discussion between Julian Bradfield and Leslie Lamport. In his reply, Lamport states "I can't recall anyone disagreeing with me in TeXhax." In the first two issues of 1988, a few European TeX users, e.g., Hubert Partl (V88 #1), Oliver Schoett (V88 #2), attempted to discuss foreign-language modifications to LaTeX, following a suggestion by Renzo Beltrame (V87 #106). Leslie Lamport had made it very clear, in V88 #1, that he disagreed with Renzo Beltrame, and never replied to the submissions of the two European users, who clearly disagreed with him. Could Mr. Lamport please comment on the foreign-language matter again? Regards, Nico Poppelier ------------------------------ Date: Mon, 22 Feb 88 14:36:09 GMT From: Sebastian Rahtz Subject: standardizing dvi2ps Ken Yap's plea for standards in dvi2ps filters is appropriate; the version on the current Unix tape is well out of date in terms of features, for instance, so one has to hack ones own. What happened to Stephan v Bechtolsheim's? I was shown some output from it last summer, and there were announcements, but it seems to have gone dead. If anyone DOES merge all the offerings together, could I make a pathetic plea NOT just to make it available on that mysterious anonymous FTP you have other there? On two occasions when I have mentioned dvi2ps on TeXhax, people have contacted me for copies because they have no access to USA networks for FTP. In reference to Ken's wishlist, he does not specifically mention MacDraw files, which present special problems; I would also suggest that many features could be provided as TeX macros, once a basic PostScript-passing mechanism is in place (the approach that 'psfig' takes, inserting \specials without you knowing about it. ------------------------------ From: Sebastian Rahtz Subject: TeX-to-C at the risk of being boring, where does one get Tim Morgan's TeX-to-C? sebastian rahtz ------------------------------ Subject: Padding dvi files Date: Mon, 22 Feb 88 10:15:35 PST From: Richard Roy I had the need a few years ago to kermit some dvi files from a UNIX VAX to a VAX VMS 4.1 OS. I wrote the following program to pad the dvi file so it would successfully print using the IMPRINT system of Kellerman and Smith. --------------------- #define BUFSIZE 512 #define PADCHAR '\337' #include /* * dvipad is a simple program to generate dvi files which are multiples * of 512 characters in length, padding the last bytes with 233 or * 337 octal, a character which the IMPRINT spooler on VAX/VMS 4.1 * apparently wants to see at the end of the dvi files (the postamble). * Written 10/16/85 by rhr q */ main() { char buf[BUFSIZE]; int n,cnt=0; while ((n=read(0,buf,BUFSIZE)) == BUFSIZE ) { cnt++; if ( write(1,buf,n) != n ) fprintf(stderr,"write error on buffer %d!\n",cnt); } if ( n <= 0 ) { fprintf(stderr,"read error\n"); exit(1); } fprintf(stderr,"%d buffers copied!\n",cnt); if ( write(1,buf,n) != n ) fprintf(stderr,"write error on last buffer!\n"); fprintf(stderr,"padding file with %d 0337's\n",BUFSIZE-n); while ( n++ < BUFSIZE ) putchar(PADCHAR); } ------------------------- It's not a work of art, but for 10 minutes of work, it solved the problem. RR ------------------------------ Date: Mon, 22 Feb 88 16:08 EDT From: DAVIS%scrvx2.sdr.slb.com@RELAY.CS.NET Subject: hanging letters There have been a couple of messages about hanging letters at the beginning of a paragraph. Sadly, none of the answers seen so far appears to have done it correctly. Having been playing with it for a few days, I don't think that I know enough about TeX to solve it, but can provide one specification for what is *really* needed - coming from inspection of about 15 books which use such devices: 1) Its important that the bottom of the hanging letter (in the case of a capital, its baseline I imagine) lines up exactly with the baseline of the lowest indented line. ie; 2) It is desirable that the hanging letter be of sufficient point size to meet condition (1) and extend vertically above uppermost indented line (or at least, above a reference line drawn across the tops of the tail-less letters like n, m, o etc.) by at least 1em. I tried two approaches to (2) - firstly, having the macro accept an argument that uses the number of lines into which the hanging letter should hang, and then using scalable PostScript fonts (scalability being a virtue here, for once!) to generate a letter of the appropraiate point size. Secondly, I tried just taking a given \largefont, and hanging an appriate number of lines fr that size. The problem is - interline glue. You cannot just lower the box that contains the letter by NoOfHangingLines*\baselineskip, because there is no guarantee that this will line it up with the lowest line, because of interline glue, which we don't want turned off.... It seems to me that one theoretical approach is to get a number of lines to hang (either as an argument or determined by a font size) and then to \hangindent (NoOfHangingLines - 1) before setting the box containing the letter (and modified to have zero height....). So here's a pseudo-algorithm: get number of lines to \hangindent into NumLines LinesBoxed = 0 while (LinesBoxed < NumLines) box up a line set the hanging letter box set the final indented line and continue...... I do not know how to do this....... can anyone out there do this, or at least converge on the same aim - the setting of hanging letters in a way that does justice to TeX ? Don Knuth made it easy by designing his bend signs with a reference point that sets them in the right place automatically....... or so it seems..... Paul Davis davis%m_blue%sdr.slb.com@relay.csnet "whoever does not understand Unix is condemned to reinvent it.. badly!" ps: please reply direct while Malcolm is out of town... thanks ------------------------------ From: ekrell@ulysses.att.com Date: Mon, 22 Feb 88 17:13:28 EST Subject: More Common TeX vs. TeX-to-C benchmarks I was surprised by the figures showing Common TeX being faster than TeX-to-C. I have recently built both versions, and I got quite different results. The following are my figures, obtained on a lightly loaded Vax 8650 running 4.3 BSD Unix. I have Common TeX version 2.1 and TeX-to-C applied to TeX 2.9. I ran both programs on two different documents, one is a paper I am writing and it is currently 6 pages long. The second document is another paper, 18 pages long. The results of timing several runs of both programs under the same enviromental conditions yields the following: Document 1 Document 2 CommonTeX TeX-to-C CommonTeX TeX-to-C real 11.00 13.00 25.92 23.93 user 6.25 6.10 16.90 16.27 sys 0.50 0.60 1.28 1.20 The numbers are in seconds and I believe the meaning of these numbers has been previously explained. As you can see, there is no much difference between the two, and in the longer document, TeX-to-C is about 5% faster. Furthermore, CommonTeX is about twice as big as TeX-to-C (1.5 MB vs 750 KB). ------------------------------ Date: Mon, 22 Feb 88 23:55:17 EST From: elwell@tut.cis.ohio-state.edu (Clayton Elwell) Subject: Metafont mode_def settings for Dataproducts LZR-2665 The Dataproducts LZR-2665 laser printer is a high-speed PostScript printer that uses a Toshiba write-white engine. So far the best settings I've found for this marking engine are the ones John Gourlay proposed for the Xerox XP-12 engine in TUGboat V8N2: pixels_per_inch := 300; blacker := .6; fillin := -.3; o_correction := .6; With fonts generated using these settings, you can use 'dvi2ps' and still be able to read your output... It's not perfect, but it sure beats using fonts generated for the Canon engine. Clayton M. Elwell / elwell@tut.cis.ohio-state.edu ------------------------------ Subject: Re: stripping comments from .sty files Date: Tue, 23 Feb 88 11:44:34 -0500 From: Ken Yap I'm taking the liberty of forwarding this: > Some user's experience follows: > > As suggested by LL in TEXHAX #16, I measured the times for loading > .sty versus .doc files. I used an `empty' LaTeX document: > > \documentstyle{siam} > \begin{document} \end{document} > > I am using an ATARI ST with 20 MB harddisk. The results are: > > After .. seconds | happens > -------------------------------------------------------------------------- > siam.sty+siam10.sty|siam.doc+siam10.doc| > |(renamed to *.sty) | > -------------------------------------------------------------------------- > 6 | 6 | ``This is TeX ...'' > -------------------------------------------------------------------------- > 16 | 16 | ``(e:test.tex \\LaTeX Version..\\ > | | (siam.sty\\Documentstyle 'siam'..\\ > | | (siam10.sty'' > -------------------------------------------------------------------------- > 19 | 22 | ``)'' (siam10 finished) > -------------------------------------------------------------------------- > 25 | 29 | ``)'' (siam finished) > -------------------------------------------------------------------------- > 32 | 35 | Everything finished. > -------------------------------------------------------------------------- > > Conclusion: There is really no noticeable difference. > > A more serious problem is disk space: > siam10.doc+siam.doc take up 42 KB vs. 14 KB for the *.sty files! > Is this really necessary? Maybe some less verbose section headings > would be sufficient. (Suggestion to the authors?) A 6 MB partition > is so quickly filled... Interesting... > Finally something which annoyed me several times: The .doc files contain > or characters which, during the migration through netland, > keep getting translated into something else which either my editor or > TeX won't eat. Last time they ended up as question marks which were > greeted by LaTeX with a ``missing \begin{document}'' error message. > (But then also the backslashes in TEXHAX digests use to show up as > question marks at this site...) OK, I have edited the style files with form feeds so that they are preceeded by %. Future submitters to the collection please note. Also try to stay within 80 columns. You'd think card readers have been junked by now, sigh. :-) > Martin Costabel > TH Darmstadt, W.Germany Ken ------------------------------ Date: Tue, 23 Feb 88 16:22:47 -0800 From: Alastair Milne Subject: RE: Flame; LaTeX Notes indentation question As the questioner to whom Dr. Lamport's reply was addressed, I'm afraid I have to agree about the quality of the reply. While I have done enough ridiculous things in my life, and promptly been told so, that one more or less is of no grave consequence to me, I was rather disappointed with the relative lack of new information. It was always my assumption that a major phototypesetter would indeed be designed by people who knew about typography, and I did not particularly require confirmation of it. It is possible, however, that I was unclear about my particular need for exceptional indentation rules; and that I was perhaps the 572nd person to imply, however unintentionally, that the standard indentation rules in LaTeX's article style are in error. I can imagine that would quickly get on one's nerves. For the most part, I don't think they are so. I have in fact been very pleased overall with my results from LaTeX, which is the main reason I'm willing to invest some time (of which, like most of us, I have much too little) in learning its more sophisticated features. Certainly, being able to treat a large printing job as a programming problem has made things much easier when it really counted. Nevertheless, I can't suddenly start using different indentation styles from what have been our practise for years, even when different ones are recommended by typesetters. LaTeX's usefulness will therefore be compromised if I can't induce it to maintain our indentation practices. So I had hoped for a reasonably informative reply, and did feel rather let down by what I did get. I am not eager to invest the time in learning and modifying .sty files; but if there is no simpler way that somebody can show me, I suppose I'll have to try. BTW: for anybody still interested, the indentation problem I have is this: I need paragraphs to be formatted for technical documentation with an overhang like this. Several people were already kind enough to demonstrate how to use \leftskip and \parindent to do so, but these are not applied to the first paragraph in a [sub[sub]]section. With the overhang on all succeeding paragraphs, this looks rather silly. I've tried defining a special sectioning command that includes both \section and \indent, but the space that results between the section head and the first paragraph is much too big. So for the moment, it looks as if I'm off to explore the wilderness of .sty files. Hope the comments are good -- I'll need them. Alastair Milne ------------------------------ %%% %%% subscriptions, address changes to: texhax-request@score.stanford.edu %%% please send a valid arpanet address!! %%% %%% BITNET distribution: subscribe by sending the following %%% line to LISTSERV@TAMVM1.BITNET: %%% SUBSCRIBE TEX-L %%% %%% submissions to: texhax@score.stanford.edu %%% %%%\bye %%% ------------------------------ End of TeXhax Digest ************************** -------