TeXhax Digest Friday, February 5, 1988 Volume 88 : Issue 11 [SCORE.STANFORD.EDU]TEXHAX11.88 Editor: Malcolm Brown Today's Topics: \vadjust in a box Re: \vadjust in a box LaTeX eqnarray environment tgrind.sty, xxxslides.sty, xxxcustom.tex mode_defs for Linotron 300 ? Switch of fonts in VERBATIM TeX on a Linotron 300 / PostScript DVI Driver Output from TANGLE macro to trim spaces Initial Impressions of Varityper VT600 Saving space for specials? LaTeX Notes (Re: TeXhax Digest V88 #09) Metafonting at 78 DPI (or, where did my pixels go?) bug in bibtex: doesn't like umlauts question? looking for dviimp Stephen Page's "Umlauts eaten by QMS printer" bug in bibtex alphabetic styles? New BibTeX ---------------------------------------------------------------------- Date: Sat, 30 Jan 1988 21:26 EST From: Jim Walker Subject: \vadjust in a box I am trying to write a macro to write marginal notes using \vadjust, but it doesn't work in certain cases; apparently \vadjust doesn't do anything when it occurs inside an hbox that is inside a paragraph. I can't find any admission or explanation of this in the TeXBook. I don't suppose this is a bug that has been fixed? (he said wistfully.) %% Barbara Beeton replies: ------------------------------ Date: Sat 30 Jan 88 19:48:19-PST From: Barbara Beeton Subject: Re: \vadjust in a box there are some elements that just won't migrate out of restricted horizontal mode; one such is \mark , and the texbook (p259, first paragraph) compares \mark to \vadjust and \insert in the way that it migrates. it is also stated "but a mark that is locked too deeply inside a box will not migrate". something similar happens to footnotes (which are inserts) in boxes, so it's not too surprising that your \vadjust items are disappearing. \mark, \insert and \vadjust are discussed on pp280-281, with a reference to a later discussion of migration. i doubt it's a bug; believe it to be an inconvenient feature. -- barbara beeton ------------------------------ From: B8AV%MCGILLC.BITNET@forsythe.stanford.edu Date: SAT JAN 30, 1988 23.51.06 Subject: LaTeX eqnarray environment Hi, I am using the eqnarray environment in LaTeX to align equations. It inserts extra space around the second field, which is usually a binary operator, such as an equal sign. It does, however insert more space than what plain usually does around a binary operator. This fine as long as I have one binary operator per line, but occasionally one may have more than one such operator. (We may not always want to align this operator.) For example, * I have the following \begin{eqnarray} C_1 &=& {\bf n} \cdot {\bf \lambda} = 0 \\ C_2 &=& {\bf n} \cdot {\bf n}-1 \\ C_3 &=& {\bf \lambda} \cdot {\bf \lambda}-1 \end{eqnarray} where the first line has an extra equal, but we do not want it to be aligned on the second line (I think it looks better if it stays on the same line), then the space inserted around the first equality is more than the second which does not seem to look good. What do I do to make the spacing better? I have tried to use the array environment, the spacing was OK, but I have to put \displaystyle in front of each line, and the vertical spacing is not right! the equations are touching each other. Adding \openup does not seem to help. I hope someone can help. Thanks Wai Hung Leung B8AV@MCGILLC.BITNET ------------------------------ Subject: tgrind.sty, xxxslides.sty, xxxcustom.tex Date: Sun, 31 Jan 88 22:10:02 -0500 From: Ken Yap Could the person who submitted these to the LaTeX style collection please step forward? It appears a file captcont.sty is missing. Ken ------------------------------ Date: Sat, 30-JAN-1988 17:21:54.21 GMT+1 From: (Harald Koenig) Subject: mode_defs for Linotron 300 ? Has anyone out there an existing mode_def for the Linotron 300 unsinf 1270 AND 2550 dpi? I made a first test using the definitions for for the Autologic APS-Micro5 and the Compugraphic 8600, but the thin lines are a bit too thin. So, are there already any experiances? Here's my first guess for mode_def: mode_def linotron = % linotron mode: for the Linotronic 300 proofing:=0; % no, we're not making proofs fontmaking:=1; % yes, we are making a font tracingtitles:=0; % no, don't show titles online pixels_per_inch:=1270; % a bit less than 20 per pt blacker:=.2; % make pens a teeny bit blacker fillin:=.2; % but compensate for diagonal fillin o_correction:=1; % and keep the full overshoot enddef; Harald Koenig (IGKH001@DTUZDV5A.BITNET) ------------------------------ Date: Mon, 1 Feb 88 08:52:43 EST From: John Boncek Subject: Switch of fonts in VERBATIM I'm new to LaTEX, and have a problem. I'd like to format a report in 12 point style, but have the VERBATIM areas formatted in something much smaller - say 6 point. (I want to display program listings in the text of the document.) How do I mark up my document? Thanks. John Boncek ------------------------------ Date: Mon, 1 Feb 88 10:06:03 EST From: elwell@tut.cis.ohio-state.edu (Clayton Elwell) Subject: TeX on a Linotron 300 / PostScript DVI Driver Since many people have expressed in my PostScript driver, which uses native Adobe fonts and hence works nicely on an L300, I have put together a preliminary release, containing the driver, a boatload of TFM files for Adobe fonts, and a sample .sty file for including EPSF graphics (such as those produced by Adobe Illustrator, for example). The driver is known to work on Pyramids, Suns, and the Apple Macintosh (using MPW C), so it should work without much problem on any system that provides a vaguely UNIXoid C runtime environment. I'd be happy to collect mods for other operating systems, as well. The next step is to get math mode working with the Adobe symbol font (which would be pretty ugly) or produce PostScript outline fonts for the CM family (whoch would take a lot of time, but I've got some ideas). Since we pay for each and every packet that goes through our X.25 link to the Internet, I cannot put it up for anonymous FTP from our site. [To Pierre Mackay: I have never succeeded in getting hold of you by phone or mail, but I'd be happy to let you stick it in the UNIX TeX distribution.] Any volunteers for FTP sites? --Clayton Elwell / The Ohio State University, CIS Department ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!elwell (UUCP) elwell@ohio-state.arpa (ARPA) 614-292-6546 (AT&T) ------------------------------ To: TexHax Immoderators Date: Mon, 01 Feb 88 01:53:37 PST From: Nick Cuccia Hello, Sorry if this has been answered many times before, but I would like information on C WEB, the version of WEB that generates C code rather than Pascal. Thanks in advance, --Nick Nick Cuccia cuccia%mica@ucbvax.berkeley.edu (Internet) {bellcore,cbosgd,decvax}!ucbvax!mica!cuccia (UUCP) ------------------------------ From: Alex Woo To: texhax-request@score.stanford.edu Subject: Output from TANGLE Are there CHange files for TANGLE so that it will output human-readable PASCAL? Alternatively, does anyone have a PASCAL pretty-printer which will do something reasonable with this TANGLE output? Alex Woo woo@pioneer.arc.nasa.gov ------------------------------ Date: Mon, 1 Feb 1988 14:51 EST From: Jim Walker Subject: macro to trim spaces How do you write a macro that takes its argument, trims leading spaces, and puts the result in another macro? \ignorespaces doesn't work, which must be one of those things about what TeX does in its mouth, stomach, etc. %% The first person to answer this question was Jim himself: From: Jim Walker Subject: macro to trim spaces, 2 Never mind about my question earlier today about trimming leading spaces. I figured out the answer: \def\trim#1{\innertrim#1\end} \def\innertrim#1#2\end{\def\answer{#1#2}} Incidentally, the reason I wanted to know this is that if you're going to write a macro with keyword parameters, it's nice to allow spaces after the commas. ------------------------------ Date: Mon, 1 Feb 88 14:35:57 PST From: forrest@Csa2.LBL.Gov (Jon L Forrest) Subject: Initial Impressions of Varityper VT600 After having played with a Varityper for a few days I thought I'd describe my initial impressions of it. Keep in mind that I'm not a Metafont expert. The printer was extremely easy to install. It worked right away on 9600 baud serial connections. It also fit in the Unix spooling universe extremely well. We were able to print transcript documents as soon as the Varityper was plugged in. As far as TeX is concerned, Doug Henderson and I sat down and came up with blacker=.8, fill=.2, and o_corr=1.0 as a good first pass at reasonable looking fonts. However, after comparing the output of the Varityper with an Apple Laserwriter, I'm not as convinced as I once was about the noticable improvement between 300dpi and 600dpi. The Varityper is better, no question about it, but I don't think the difference is enough to warrent the difference in prices, based on what a Varityper costs today. I don't blame the Varityper, though. It looks like the problem is simply that laser printer technology on regular paper isn't sufficient to make 600 dpi look as good as it should. Also, the Laserwriter prints much darker, given the same font bitmaps, resulting in what might be perceived as an artficially enhanced result. Keep in mind that our Varityper is brand new and might start printing darker too once it has been broken in. I'm going to keep my eye on the TeX output that gets printed on the Varityper and try to get other people's opinions about the output quality. If I were using my own money, I'd stick with 300 dpi technology and use a real phototypesetter for printing the few documents that really have to look great. Even though this would cost more, with the money I'd save by not having to buy a Varityper I'd still be ahead. Again, all these opinions are very subjective and are based on a very short trial period. Jon Forrest Lawrence Berkeley Lab FORREST@LBL.GOV (internet) FORREST@LBL (bitnet) ------------------------------ Date: Mon, 1 Feb 88 14:43:46 pst From: hildum@iris.ucdavis.edu (Eric Hildum) Subject: Saving space for specials? Hello, I am working on a macro which will be used within a LaTeX file to include an image from our image processor. I have been successful with including the images using the special command, but I would like to improve the macro to prevent possible problems. The current defintion is (from memory): \renewcommand{\includeimage}[3]{% \hbox{\vbox{\special{insert #3}\vskip #1}\hskip #2}} The use is: \includeimage{}{}{} Now, my questions are: 1. Is there a way to force the arguments to \vskip and \hskip to always be true sizes without forcing the writers to include the keyword true in the size specification? 2. Do I need to worry about the use of this command in the various environments (eg, will the use in a math environment cause problems)? 3. Is there a better way to reserve a rectangular region in a document? Thank you, Eric Hildum dehildum@ucdavis.ucdavis.edu (Internet) dehildum@ucdavis.bitnet (BITNET) ucbvax!ucdavis!dehildum (uucp) ------------------------------ Date: Mon, 1 Feb 88 15:45:42 pst From: lamport@src.dec.com (Leslie Lamport) Subject: LaTeX Notes (Re: TeXhax Digest V88 #09) Keith Pierce writes: I've stumbled upon a mysterious phenomenon in LaTeX... [W]hen the marginal note instruction is added, the value of \topmark gets trashed. Not so mysterious... LaTeX processes figures and marginal notes by calling the \output routine (by inserting a vertical penalty less than -10000). (This is done to enable LaTeX to figure out whether the marginal note will be on an even- or odd-numbered page.) Of course, the value of \topmark gets destroyed in the process. Pierce is probably content to have all his marginal notes appear in the right-hand margin, and he clearly demonstrates the necessary TeX hacking ability to put them there himself without using the \marginpar command. Leslie Lamport ------------------------------ Date: Mon, 1 Feb 88 21:05 EST From: Subject: Metafonting at 78 DPI (or, where did my pixels go?) --- INTRODUCTION ----------------------------------------------------- We recently used Metafont to make a large number of PK files for use with a previewer on a VAXstation. The results of this effort may be of interest to others contemplating a similar operation. Some of our documents will use fonts scaled up to magstep 5 for making overhead transparencies for class lectures, conferences, seminars, etc. The previewer can also add a magnification of up to 5 which is used often to check out subscripts and sub-subscripts. Therefore, we made the fonts in magsteps 0, half, 1, 2, ..., 10. Note we will not be able to request that the previewer add any magnification to a document containing a font scaled to magstephalf since it would then go looking for a font scaled to magstep 2.5, 3.5, etc. We made all the fonts that are on the standard VAX distribution except for the following: CMU10, CMITT10, CMSLTT10, CMTCSC10, CMTEX8, CMTEX9, CMTEX10, CMVTT10, CMFF10, CMFIB8, and CMFI10. Also, we made CMINCH only at its normal size. We created a command file which reads in a table from a second file that described which fonts were to be made; then, for each font and size, it (1) calls Metafont, (2) calls GFTOPK, and then (3) deleted the GF, LIS, and TFM files to help keep down the amount of disk space used. All work was done on a VAXstation II (i.e. it uses the MicroVAX II processor) running VMS 4.5 and Metafont 1.0.0. It has 5Mb of memory and two 71Mb disk drives. We are using the dvi-previewer and font-previewer written by Randy Buckland (TeXhax Volume 87 Issue 69) and obtained though the kind help of Mic Kaczmarczik (UT Austin Computation Center). --- RESULTS ---------------------------------------------------------- Two batch jobs were run. The first ran through all of the CMR fonts and took about 14 CPU hours. The second batch job ran through all of the remaining fonts and produced the following accounting information: Buffered I/O count: 65564 Peak working set size: 1024 Direct I/O count: 52828 Peak page file size: 2426 Page faults: 1050813 Mounted volumes: 0 Charged CPU time: 2 14:10:01.85 Elapsed time: 2 16:31:14.74 Note that the charged CPU time is 14+ hours plus two days! Altogether, it took about 76 CPU hours to produce 757 PK files which take up 6530 blocks of storage. --- ERRORS ----------------------------------------------------------- Our command file made a note whenever Metafont returned with an error status. Although there were no great disasters, a great many characters had bits and pieces missing; some very small characters came out completely blank. The user of the Previewer must decide, when the text looks ragged, whether there is really a problem, or whether it is merely a Metafont foulup. Printing the file at 300 DPI can of course always resolve the question. --- CONCLUSIONS ------------------------------------------------------ I would recommend that anyone in a similar situation (and with available CPU and disk resources) use Metafont to make whatever their previewer needs. It is VERY nice to be able to enjoy previewing anything that can be printed (except for graphics - but that's another story). I'm not too worried about the errors in the smaller fonts since I can't really see them anyway - I just want something to act as a place-keeper. The errors in the larger fonts (10pt and above) have proven to be only moderately annoying. However, since it will be a long time before we are all using 300 DPI screens to preview, it would be a great asset to have an improved Metafont, or perhaps a special version, which can handle low- resolution display devices. Perhaps running Metafont at double the actual screen resolution, then applying an anti-aliasing process which cuts the dot density in half, could help. Kent Eschenberg Applied Research Laboratory, Penn State University, State College, PA BITNET Address KEE@PSUARLC ------------------------------ Date: Mon, 1 Feb 88 09:26:37 +0100 From: Marc Shapiro Subject: bug in bibtex: doesn't like umlauts Bibtex (BibTeX, Version 0.98i for Berkeley UNIX) dosn't like umlauts. Something like author = "Kurt Sch\"{o}ner" doesn't work because bibtex thinks the \" is the closing double-quote. This is a bug. (A work-around is to use braces instead of double-quotes.) Does anybody have a fix? ------------------------------ Date: Tue, 2 Feb 88 10:28 N From: Subject: question? Has anybody a program to convert AFM files from the program "FONTOGRAPHER" on the MAC to TeX .TFM files? I'm also looking for a DVITODVI program on a PC or ATARI ST? Theo Jurriens ------------------------------ Subject: looking for dviimp Date: Tue, 02 Feb 88 04:50:23 EST From: moore@UTKCS2.CS.UTK.EDU I'm looking for a recent version of dviimp for Unix. In particular, I'm interested in a version that can read .gf files directly instead of .pxl files. After poking around the net awhile, I found such a program, but it's essentially useless as it doesn't handle magnifications for fonts read from .gf files, and it can't set page margins. If someone knows where I can find a better copy it will save me some hair-pulling trying to fix this one. Please reply to one of the addresses below, rather than to the list as a whole. Thanks in advance. Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkcs1 Knoxville Tennessee ------------------------------ Date: Tue, 2 Feb 88 12:55 O From: Subject: Stephen Page's "Umlauts eaten by QMS printer" QMS Lasergrafix umlaut problem ------------------------------ Obviously this very same problem was found in Computing Center, Unv. of Jyvaskyla Finland. I reported about this problem to local QMS dealer already in the beginning of -87. This problem occured after updating QMS's micro code. The problem in Jyvaskyla behaved in the following way. In some cases the umlauts ware ok in the first page that they occured but in the next pages they ware missing. Sometimes our QMS also hung up and I believe that this was due to this same problem. The bug was fixed by modifying QMS driver programme. Studing driver code it was found that umlaut was loaded to place 7F (decimal 127). Driver was changed by loading umlaut somewhere else than to 7F or to FF and after this change our QMS has been working without any problems. After all, there really is a bug in QMS Lasergrafix and it does not work as it is said in the user manual. It took many hours or even days to solve the problem here. Our TeX environment is VAX/VMS and QMS Lasergrafix 800 driver is written in Pascal. If you wish I can send a little bit of updated code. Best Regards Kauko Saarinen Saarinen@finjyu.bitnet ------------------------------ Date: Mon, 1 Feb 88 17:48:49 +0100 From: Marc Shapiro Subject: bug in bibtex alphabetic styles? It looks like I've found a bug in the alphabetic styles of bibtex, but it's so big I can't imagine noone found it before. If I feed the file below to bibtex (for a latex file containing the 3 corresponding \cite's or \nocite's, and \bibliographystyle{alpha}), there are printed in the order Atkins, Alon, Anderson, i.e. not in alphabetical order! If instead I use \bibliographystyle{plain}, they come out in the correct order: Alon, Anderson, Atkins. What have I done wrong? (I Use BibTeX, BibTeX, Version 0.98i for Berkeley UNIX). Here is the test file: % begin test file @string{podc7 = "The 7th International Conference on Distributed Computing Systems"} @Misc{un, author = "M. Stella Atkins and Gamik Bobloian", title = "Efficient Reliable Multicast Communication in Distributed Systems" } @TechReport{deux, author = "David P. Anderson and Dominico Ferrari and P. Venkat Rangan and Shin-Yuan Tzou", title = "The Dash Project: Issues in the Design of Very Large Distributed Systems", institution = "Computer Science Division {EECS}, University of California", year = 1987, number = "UCB/CSD 87/338", address = "Berkeley CA ({USA})", month = jan } @InProceedings{trois, author = "Noga Alon and Amnon Barak and Udi Manber", title = "On Disseminating Information Reliably Without Broadcasting", booktitle = podc7, year = 1987, pages = "74--81", organization = "IEEE", address = "Berlin, (West) Germany", month = oct } % end test file Marc Shapiro INRIA, B.P. 105, 78153 Le Chesnay Cedex, France. Tel.: +33 (1) 39-63-53-25 e-mail: shapiro@inria.inria.fr or: ...!mcvax!inria!shapiro ------------------------------ Date: Tue 2 Feb 88 05:54:45-PST From: Oren Patashnik Subject: New BibTeX The new version of BibTeX (0.99a) is now available from the standard distribution area, , on SCORE.STANFORD.EDU. To use the new BibTeX you'll need new bibliography styles (the new BibTeX and the old styles are incompatible, as are the old BibTeX and the new styles; old database files, however, work just fine with the new BibTeX). New versions of the four standard styles (plain, abbrv, alpha, unsrt) are available from the standard distribution area. New versions of four other styles (acm, apalike, ieeetr, siam) are available from the Rochester style collection. If you have an old style that you'd like to update, it's best to start with the new version of a style close to yours (make sure it's for BibTeX 0.99a), and then modify that. The document `BibTeXing', in file btxdoc.tex on the standard distribution area, describes the new features of both BibTeX and the standard styles, and gives some useful BibTeX tips that the LaTeX book couldn't include. The document `Designing BibTeX Styles', in file btxhak.tex on the standard distribution area, describes BibTeX's style language. Here, briefly, are BibTeX's main new features: (1) With a single command, you can now include in the reference list every entry in the database files, without having to explicitly \cite or \nocite each entry. (2) You can now have as a field value (or an @STRING definition) the concatenation of several strings. For example if you've defined @STRING( WGA = " World Gnus Almanac" ) then it's easy to have similar `title' fields for different entries: TITLE = 1966 # WGA, TITLE = 1967 # WGA, and so on. Or, you could have a field like MONTH = "1~" # jan, which would come out something like `1~January' or `1~Jan.', depending on how your bibliography style defines the `jan' abbreviation. (3) There is now a cross-referencing feature, which allows one entry to cross reference another. For example if you \cite a paper from a conference proceedings, and if that paper has in its database entry a special cross reference to the whole proceedings' entry, then two things happen: (i) the paper's entry automatically inherits from the cross-referenced entry any fields that the paper's entry is missing (thus, if you have in your database several papers from the same conference, you need to include the conference information only once, in the proceedings' entry); and (ii) BibTeX automatically puts the cross-referenced entry into the reference list if it's cross referenced by two or more entires that you \cite or \nocite, even if you don't \cite or \nocite the cross-referenced entry itself. Furthermore, the standard styles will output certain information only once, for the cross-referenced entry. (4) BibTeX now handles accented characters. For example if you have an entry with the two fields AUTHOR = "Kurt G{\"o}del", YEAR = 1931, and if you're using the `alpha' bibliography style, then BibTeX will construct the label [G{\"o}d31] for this entry, which is what you'd want. To get this feature to work you must place the entire accented character in braces; in this case either {\"o} or {\"{o}} will do. (5) It also handles hyphenated names. For example if you have an entry with AUTHOR = "Jean-Paul Sartre", and if you're using the `abbrv' style, then the name will come out as `J.-P. Sartre' (6) There's a new database-file command, @PREAMBLE. The standard styles output whatever information you give this command (LaTeX macros most likely) directly to the .BBL file. Among other uses, if BibTeX sorts an entry into a different spot from where you want it, this command gives you a mechanism for telling BibTeX where to stick it. (7) BibTeX's sorting algorithm is now stable. This means that if two entries have identical sort keys (the bibliography styles construct these sort keys) those two entries will appear in citation order. (8) BibTeX no longer does case conversion for file names; this will make BibTeX easier to install on Unix systems, for example. (9) It's now easier to add code for processing a command-line {\tt aux}-file name. And here are a few of the changes to the standard styles that affect ordinary users (as opposed to style designers): (1) In general, sorting is now by author, then year, then title--- the old versions didn't use the year field. (2) Many unnecessary ties (~) have been removed. (3) Emphasizing ({\em ...}) has replaced italicizing ({\it ...}). (4) The MASTERSTHESIS and PHDTHESIS entry types now take an optional `type' field; this allows you to call it a `Ph.D. dissertation', for example, instead of the default `PhD thesis'. (5) The `alpha' style now uses a superscripted `+' instead of a `*' to represent names omitted in constructing the label. (Furthermore it's possible to override this character without modifying the style file.) Please report bugs in the new versions of BibTeX, or the standard styles, or the documentation, to me. Final note: Many people have asked me whether BibTeX works with TeX as well as LaTeX, and I've usually said that it was really designed for LaTeX; however, it's not that much work to write some TeX macros that would make BibTeX work with TeX. I invite someone to do this. --Oren Patashnik (patashnik@SCORE.STANFORD.EDU) ------------------------------ End of TeXhax Digest ************************** -------