TeXhax Digest Tuesday, January 27, 1987 Volume 87 : Issue 06 TEXHAX06.87 Editor: Malcolm Brown Today's Topics: LaTeX and double space Metafont command line. Re: more BibTeX (non)features it happened Re: BibTeX (non)features Two replies and a comment on TeX vs. Postscript Using CM fonts on Apple LaserWriter IBM Utilities ---------------------------------------------------------------------- Date: Tue, 20 Jan 87 14:56 O From: (Benjamin Pashkoff) Subject: LaTeX and double space To: texhax@su-score.arpa This is my first request fromm this list, so I hope it is going to the right places.\ We are running Tex, LaTeX and metafont on a VAX 11/780 VMS with a LN03 laser printer and Flavio Rose's LN03 interface. All has been running smoothly except for two items: 1) What is the full list of pixel file names that should be used from the GF type file names? Example: xx.300gf --> xx.1500pxl Specifically the 209% and 107% do not translate correctly and the 'good font file cannot be found' 2) Is there a simple and easy way to produce double spaced Roman font files in LaTeX? the baselinestretch qualifiers do not seem to make an affect. Thank you, Ben Pashkoff BEN@TECHMAX.BITNET System Engineer Biomedical Engineering Technion, IIT Haifa, Israel ------------------------------ Date: Sat, 24 Jan 87 15:10:01 EST From: Karl Berry To: texhax%score.stanford.edu@RELAY.CS.NET Subject: Metafont command line. In the last texhax, Donald Blais sent in a question about command lines in Metafont. I think that he has uncovered a bug in the TOPS-20 change file; a command line like `mf ; ...' should (I think) be interpreted as an empty filename. Therefore, MF should respond with ``Sorry, I can't find file `.mf','' or some such message. (This is what happens on Unix; I think the MFbook does specify this behavior.) Karl kbb@cs.brown.edu (CSnet) ------------------------------ Date: Sat, 24 Jan 87 16:32:41 CST From: William LeFebvre Subject: Re: more BibTeX (non)features To: TeXhax@score.stanford.edu Perhaps this is asking too much, but I would really like to see some sort of parameterized string expansion. Currently, you can only predefine a string with the @STRING command Maybe an example will make what I want clearer. I have citations to several different years of the "Proceedings of the 19?? ACM Conference on Lisp and Functional Programming", where "??" could be 80, 82, 84, 86, etc. References to papers from the POPL conferences suffer a similar fate. It soure would be nice to define a string, or macro, or whatever you want to call it, say "LFP(year)" so I could say BOOKTITLE = LFP(1986). Sure, I could define one string for every year, but this would even be better. Add it to the wish list. Or is this too extreme an idea? Creeping featureism? William LeFebvre Department of Computer Science Rice University ------------------------------ Date: 26 Jan 87 0155 PST From: Don Knuth Subject: it happened To: texhax@SCORE.STANFORD.EDU After 14 months with no bug reports, I was getting pretty confident that we could declare TeX to be bug-free. But Saturday night I tried something different (for me) and guess what: There will be a version 2.1. If you have a tendency to type a space after a hyphen or a dash, you might not have been getting optimum line breaks, since TeX didn't compute the correct `badness' of the line following such a break. The incorrect badnesses tended to be masked off because they were associated with an extra penalty; but they could give strange behavior. I'm so sorry. The reward for the next bug will be $40.96. ------------------------------ Mail-From: PATASHNIK created at 26-Jan-87 07:28:14 Date: Mon 26 Jan 87 07:28:14-PST From: Oren Patashnik Subject: Re: BibTeX (non)features To: texhax@Score.Stanford.EDU Jean-Francois Lamy has two requests: > This is a request for a capability to retrieve BibTeX database entries by key > and be able to use their fields when formatting the current entry (i.e. after > all the entries have been hash-coded and sorting has been done) Unfortunately, this would be much more work to implement than would be worthwhile, especially since a good text editor and BibTeX's @STRING command provide a very reasonable alternative (details upon request). > As a final note, does anyone have a .bst file for the "Harvard" Format, e.g. > Hayes, P.J. (1984a) The second naive physics manifesto, ... > In this format the cite command would produce the year with the appropriate > suffix. There exists a style called APALIKE (APA is the American Psychological Association, or something like that) that does something fairly close to what you want---the in-text citations come out something like (Jones, 1984a) and the entries in the reference list come out with (1984a) after the author's name. Details upon request. --Oren Patashnik (BibTeX implementor) ------------------------------ Date: Sat, 24 Jan 87 11:22:01 pst From: lamport@decwrl.DEC.COM (Leslie Lamport) To: texhax-request@score.stanford.edu Subject: Two replies and a comment on TeX vs. Postscript In this message: * Reply to Stephen Page's request for a Unix indexing package. * Reply to Rusty Wright's request for a LaTeX "proof" environment. * General comment on TeX vs Postscript. * Peehong Chen's C version fits into a 66K byte shar file. The LaTeX documentation and style file are about another 20K bytes. If you have an immediate need for the stuff, send me a message at lamport@src.dec.com and I'll mail it out. (Please include info on the appropriate Unix commands for mashing a bunch of files together into a single file; I'm not a Unix wizard.) If you have no immediate need, please wait a month or so until things stabilize. * Rusty Wright wants a LaTeX `proof' environment--the difficult problem being to have the \end{proof} put a `QED' on the last line of the proof, even if the user leaves a blank line right before the \end{proof} command. I'll answer this question because it provides a potentially useful lesson in TeX hacking. However, my advice is not to bother and to require the user not to leave a blank line before the \end{proof}. The hacking outlined below represents a few hours effort for something that works most of the time, and probably a couple of days effort to get something that doesn't screw up any other LaTeX feature. With this restriction, the appropriate LaTeX command is \newenvironment{proof}{...}{\unskip ~QED...} where the \unskip removes a space following the last word of the proof, and the ~ makes sure that the `QED' doesn't fall on a line by itself. The `...'s should probably involve the `list' or `trivlist' environment. Now, for a lesson in TeX hacking. In TeX, a blank line is equivalent to a \par command, which ends the current paragraph and causes it to be processed into a sequence of \hbox's that get added to the output list. (There's also a \parskip space that's added at some point--I don't remember when.) As near as I can tell, once that has happened, there's no reasonable way to add anything to that paragraph. (You can intercept the text in the \output routine and unscramble it there, but no one in their right mind wants to rewrite the LaTeX output routine. [I'm not sure anyone in his right mind wrote it in the first place.]) So, you have to intercept the text of the paragraph before it makes its way to the output list. This requires redefining \par and \everypar as follows. The \begin{proof} command must expand essentially to something like \setbox97 = \vbox{ (Note: literal box numbers are used to make things easy to see; they shouldn't be used in any real macros.) In LaTeX, you can get an unmatched left brace with an \lbrace command and an unmatched right brace with \rbrace. \begin{proof} should also redefine \par to expand to something like } \setbox98 = \vbox{ This saves the current paragraph in box 97 and starts saving the next paragraph in box 98. The next \par command should expand to } \unvbox97 \setbox97 = \vbox{ where the \unvbox97 command puts the contents of box 97 on the output list. Subsequent \par commands should alternately complete the saving of the current paragraph, output the previous paragraph, and start saving the next paragraph. Finally, if the final paragraph of the proof winds up in box 97, then the \end{proof} command should expand to something like } \setbox99=\vbox{\unvbox97 \setbox100=\lastbox} \unvbox99 \vbox{\unhbox100 \unskip ~QED} This is just the barest outline. You'll have to futz around with \parindent and stuff in the final \vbox command, and make sure that you get the right vertical spacing between the final line of the last paragraph and the preceding lines, which are output by the \unvbox99 command. Once you've got this working, you now have to realize that redefining \par in this way has the potential to mess up every other LaTeX environment that may contain paragraphs inside it. This means checking that they all still work, and redefining ones that are broken. This isn't as hard as it might seem, since the only ones I can think of off hand that need checking are list, trivlist, tabbing, minipage, and the \parbox command. Chances are that they redefine \par themselves and should work, but I can't promise that. * Now for a general remark about TeX vs PostScript. It seems clear that dvi files are a TeX idiosynchracy, and the rest of the world is going to adopt PostScript as the standard device-independent output format. TeX will be a lot more useful, and reach a much wider set of users, if it could produce PostScript instead of dvi output. This would also permit the development of standards for incorporating figures drawn with other systems into TeX documents. What are the problems involved in doing this? The existence of dvi -> PostScript converters indicates that there is no serious problem at the back end. Allowing the incorporation of other PostScript figures into a TeX document simply requires implementers of these converters to agree on a convention for the \special commands. Since I gather that there are now just two such dvi -> PostScript programs, I urge their authors to get agree on some standard that the rest of the world can use. The more serious problem lies at the front end, with the fonts. A PostScript font comes with an .afm file to specify font metrics. TeX requires a .tfm file that has additional parameters needed to use the font in math mode. Consequently, as I understand the situation, one can use only CMR fonts in math mode. (I suspect that the .amr file also lacks parameters for the proper placement of accents.) It is my understanding that there are no PostScript versions of the CMR fonts; they must be printed by converting each character to a set of pixels, and drawing each pixel individually--a time-consuming operation. A first solution to this problem might be a method of getting Metafont to produce PostSript fonts with .tfm files. If Metafont becomes the wave of the future, with lots of fonts being drawn with it, this will be a satisfactory solution. If, as I suspect will be the situation, Metafont is ignored by most of the world, one will ultimately, want a method for producing .tfm files for fonts not produced by Metafont. The problem of converting TeX to the PostScript world is important to anyone who wants to see TeX survive. It seems to me that the current dvi -> PostScript drivers are not a viable long-term solution. I haven't the expertise or the time to contribute much to a solution. However, I'd be happy to do what I can to act as a catalyst. There are a number of people out there who have a financial stake in the survival of TeX; I urge them to start cooperating now on solving this problem. Leslie Lamport ------------------------------ Date: Mon, 26 Jan 87 05:32:04 PST From: Reply-To: JMC%NOCMI.BITNET@forsythe.stanford.edu To: TEX@score.stanford.edu Subject: Using CM fonts on Apple LaserWriter For many months now I've been happily using the CM resident fonts on the Apple LaserWriter in place of the am fonts supplied with PCTeX. Just recently I discovered that I overlooked the fact that the CM fonts are not complete and that CMTimeR does not contain the ligatures ff, ffi and ffl along with the uppercase greek ^Gamma, ^Delta, ^Theta ... The lack of ligatures is not too much of a problem since TeX is clever enough to use f f, f fi and f fl where the missing ligatures occur. More serious is the problem of missing Greeks. Looking through the available fonts I find that SYMBOL (resident on the LaserWriter) has the relevant Greek characters and that I should be able to get TeX to use the characters from this font if I modify the relevant ^mathchardef statements in PLAIN. My question is has anyone done this before and can let me know of any pitfalls/give any more guidelines. I also note that SYMBOL contains the rest of the characters normally found in amsyXX but they are indexed above '179 in the encoding. If I could reach these symbols in SYMBOL I could use all resident printer fonts throughout my documents instead of the hybrid version that I use now. The resident fonts not only look nicer and scale better, the file sent to the printer is consideraby smaller. Can PCTeX reach the characters other TeX's can't reach? Maybe it can using the -k commandline option but as anybody else tried? -- Jeremy Cook Acknowledge-To: % Regarding ligatures, note that the standard character set for Adobe's % fonts include only two ligatures, the "fi" and "fl" (at 256 and 257 octal % using Adobe standard encoding). TeX cannot, therefore, produce the other % ligatures involving the letter f when setting type using Adobe's fonts, % since they simply aren't there. I don't know why Adobe doesn't include % the other ligatures; perhaps someone can explain this? % % Malcolm ------------------------------ Date: Mon, 26 Jan 87 10:44:44 PST From: Reply-To: GUENTHER%WSUVM1.BITNET@forsythe.stanford.edu To: TeX@score.stanford.edu Subject: IBM Utilities Received: by WSUVM1 (Mailer X1.23) id 7285; Mon, 26 Jan 87 09:19:23 PLT Date: Mon, 26 Jan 87 09:15:37 PLT From: Dean Guenther 509-335-0411 Subject: IBM Utilities To: Malcolm Brown In issue #5, O'Boyle at MIT asks about the availability of the current IBM utilities. Since I am on BITNET they aren't available FTP. You can get them via tape from Maria Code, or if you want a specific program send me a note and I can send it to you. Dean Guenther BITNET: GUENTHER@WSUVM1 ------------------------------ % %\bye % End of TeXhax Digest ************************** -------