TeXhax Digest Friday, February 24, 1989 Volume 89 : Issue 15 Moderators: Tiina Modisett and Pierre MacKay %%% The TeXhax digest is brought to you as a service of the TeX Users Group %%% %%% in cooperation with the UnixTeX distribution service at the %%% %%% University of Washington %%% Today's Topics: GF-to-PK change file for VMS wanted... Big version of sqcap symbol? Format vs. macro file-- a problem LaTeX bug in \left and \right? Margins in LaTex--a query BiBTeX journal abbreviations Line breaking within a citation Re: TeXhax Digest V89 #8 (Long line macros) Computer Graphics and TeX -- A Challenge (a response) Graphics in TeX [TeXhax Digest V89 #8] Graphics in TeX--a response Re: Graphics in TeX Announcing OzTeX, a public domain TeX for the Mac Turkish TeX ---------------------------------------------------------------------------- Date: 14 Feb 89 16:17:32 EDT From: "Stefanos P. Manganaris" Subject: GF-to-PK change file for VMS wanted... Keywords: GF to PK change file, VMS TeX friends, I'm looking for the change file of GFtoPK utility for VAX/VMS. I would greatly appreciate it, if someone could send it to me. Use mail if possible, or sendfile if you are on BITNET... Many thanks, Stef. | Stefanos MANGANARIS | BITNET: SMANG@GRPATVX1 | | (System Programmer) | UUCP: ...!mcvax!ermhs!stefanos | | Computer Technology Institute, Greece | | ------------------------------------------------------------------------------- Date: Tue, 14 Feb 89 20:20:54 EST From: jeremy@wheaties.ai.mit.edu (Jeremy M. Wertheimer) Subject: Big version of sqcap symbol? Keywords: subscript Is there any way that I can get a "big" version of the sqcap symbol (i.e. a version where subscripts are placed underneath the symbol)? ---------------------------------------------------------------------------- Date: Wed, 15 Feb 89 09:42:46 AST From: Jim Diamond Subject: Format vs. macro file-- a problem Keywords: TeX, macro file, format file Using C Version 2.9 of TeX on an Iris 3130 workstation, I encountered the following problem: I was using PiCTeX and getting tired of the amount of time necessary to read in the macros every time, so I created a format which contained plain.tex, pictex.tex and some of my own macros. I removed the appropriate \input's from my source file and TeXed it again. To my disappointment, TeX now ran out of space processing my file. Does anyone know why things should work when macros are \input and not when they are included in the format? Does anyone have any suggestions? (The guy who built the TeX claims that it is as big as it can get, so I can't just increase it's size.) Thanks. Jim Diamond zsd@pig.drea.dnd.ca ------------------------------------------------------------------------------ Date: Thu, 16 Feb 89 18:37:02 -0500 From: Amitabh Shah Subject: LaTeX bug in \left and \right? Keywords: LaTeX, bug I believe this is a bug in the latex implementation of \left and \right commands for delimiters. I have the following multi-line equation that I would like to enclose within large enough left and right square brackets. My first (obvious) attempt was: \begin{eqnarray} {\em foo} & \leq & \frac{1}{\bar} \left[ \sum_{\forall i} \glarch{i} \nonumber \\ & & \mbox{} + ... \nonumber \\ ... several lines ... & & \mbox{} + ... \right] \label{eq:junk} \end{eqnarray} Latex would barf at this, apparently at not being able to find a matching \right at the first line of the equation. So I tried putting an invisible matching \right at the end of the first line and a matching \left at the beginning of the last: \begin{eqnarray} {\em foo} & \leq & \frac{1}{\bar} \left[ ... \right. \nonumber \\ ... & & \mbox{} + \left. ... \right] \label{eq:junk} \end{eqnarray} Latex now ran smoothly, but the sizes of the \left[ and \right] were now different! This is perhaps explained by the fact that the size of the bracket is chosen according to the amount of mathematics on that line. The solution would be fix latex so that the first attempt runs without any glitches --- that the occurrences of \left and \right can be separated by more than one line. I apologize if this has been pointed out before. -amitabh _______________________________________________________________________________ Amitabh Shah shah@cs.cornell.edu .(INTERNET) Dept. of Computer Science shah@cornell ...........(CSNET) Upson Hall -- Cornell University { ... }!cornell!shah ....(UUCP) Ithaca NY 14853-7501 (607) 255-8597 .........(VOICE) Date: Thu, 16 Feb 89 15:12 EST From: "Thomas G. Abernathy" Subject: Margins in LaTex--a query Keywords: margins, LaTeX I have been trying to adjust the margins of documents. Below you will see a section of code that works for the BOOK document style, but not for the ARTICLE. Does anyone know why? \documentstyle{book} \renewcommand{\textwidth}{6.5in} \renewcommand{\oddsidemargin}{0.25in} \renewcommand{\evensidemargin}{0.25in} \renewcommand{\marginparwidth}{0in} \renewcommand{\marginparsep}{0in} \title{Standard Operating Procedures} \begin{document} \input{sop} \input{organization} \end{document} ------------------------------------------------------------------------------ Date: Wed, 15 Feb 89 11:56 EDT From: Paul Davis Subject: BiBTeX journal abbreviations Keywords: BiBTeX, abbreviations Does anyone know anything about some kind of a standard set of journal abbrevs. for use with BiBTeX ? It may be rumour, or ir may be real ... thanks, Paul Paul Davis at Schlumberger Cambridge Research "to shatter tradition makes us feel free ..." -------------------------------------------------------------------------- Date: Mon, 13 Feb 89 11:50 EST From: Subject: Line breaking within a citation Keywords: LaTeX, bibliographies, citations I have a (possibly naive) question about bibliographies and citations in LaTeX. I have \bibitems of the form \bibitem[Smith and Jones 1989]{Smith89} Smith, J. and Jones, B. {\em J. Random Musings}, 140, 153. If, in the text of my paper, I have a number of citations in a row: \cite{Smith87} \cite{Smith88} \cite{Smith89} or whatever, then I get (frequently) overful lines because LaTeX is unwilling to break lines WITHIN a citation. I've the local 'gurus', and have played about with inserting \protect\linebreak[n] within the citation labels, but so far no dice. Is there a simple way to permit line breaking within a citation? Rick Pim bitnet: rick@qucdnast -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Think I'll stay in bed Rick Pim, Physics Department Dream all day Queen's University, Kingston World outside bugs me anyway. rick@qucdnast.bitnet ---------------------------------------------------------------------------- Date: Tue, 14 Feb 89 16:27:55 PST From: lamport@src.dec.com (Leslie Lamport) Subject: Re: TeXhax Digest V89 #8 (Long line macros) Keywords: macros Wayne G. Sullivan writes Can anyone explain to me why LaTeX macros must write such long lines? TeX itself is careful not to write too long lines to the terminal or log file when it is in control. I think he will find the explanation fairly obvious if he tries to write a TeX macro \foo such that \foo{TEXT} writes TEXT on a file foo.tex, guaranteeing that (1) there are never more than 73 characters on each output line, and (2) \input{foo} produces the identical output as TEXT. Leslie Lamport --------------------------------------------------------------------------- Date: Wed, 15 Feb 89 16:17:58 -0800 From: Tomas G. Rokicki Subject: Computer Graphics and TeX -- A Challenge (a response) Keywords: graphics, TeX > Computer Graphics and TeX -- A Challenge > by David F. Rogers (dfr@usna.mil) XeT dna scihparG retupmoC --- A Rebuttal by Tomas Rokicki (rokicki@polya.stanford.edu) > Graphics can be incorporated into TeX documents most efficiently by importing > the output of graphics programs directly into the TeX document in the form > of Plain TeX commands. This has got to be the most inefficient means for including graphics. Even the `huge' versions of TeX have memory limits. Graphics are device dependent. If I draw a spline, I want that spline rendered with the maximum resolution of the output device. TeX doesn't know, or care, about this resolution. Including resolution-dependent code in the TeX source, by drawing the spline with individual characters, both defeats the device-independence of TeX and guarantees memory limit exhaustion at some point. We can divide graphics into the following categories: - Sampled graphics (bitmaps, halftones) - Line art (with curves, arcs, etc) Sampled graphics in general and halftoning in particular is not as trivial as portrayed in the original article. Various methods of simulating grey levels with a bilevel device can be used, including ordered dither, halftoning, and generalizations of the F-S algorithm. Different techniques are appropriate for different devices; I would not use a conventional ordered dither on a Canon laser printer; the engine does not support isolated dots or white spaces. I would prefer to use F-S with some amount of threshold noise on synthesized images, but standard halftone techniques would probably work fine on the noisier sampled images. Compensation must be made for nonlinearities in marking engines and Moire patterns when doing color. Line art *must* include the following features: - Bezier splines (ellipses would be nice too) (lines are a generalization of splines) - Arbitrary patterns and thicknesses of splines - Arbitrary color/grey-level specification - Arbitrary filled regions - Text at all orientations and sizes. By *must*, I mean that this is the minimum set for the variety of real illustrations you encounter in real publishing. Trying to accomplish this with TeX macros gives new meaning to the term `inefficient'. For both of these classes of graphics, we can divide the world further into PostScript and non-PostScript. For the PostScript world, which is getting more and more prevalent, the problem is solved. There is no problem. Every PostScript driver worth its salt can easily and conveniently incorporate graphics completely conforming to the above specifications. For the non-PostScript world, still a very large set, provisions must be made. Essentially, a program must be written that will translate whatever graphics are required into the appropriate raster image. Other than text, and given the above primitives, this is not an extremely difficult proposition. Adapting the current device drivers to accept these raster images is, for most devices, a fairly painless modification. I have been designing such a system for a while, and plan to start coding over spring break. The initial implementation environment will be the Amiga microcomputer, for output on a wide variety of dot-matrix and laser printers. My primary goal is quality and speed Work smart, not hard. -tom Date: Wed, 15 Feb 89 17:56:06 GMT From: alien%VULCAN.ESE.ESSEX.AC.UK@uwavm.acs.washington.edu (Adrian F. Clark) Subject: Graphics in TeX [TeXhax Digest V89 #8] David Rogers' challenge makes excellent sense. However, I'd like to make two contributions to this discussion: 1. On the subject of halftones, Don Knuth's halftone font, and variations thereon, are all that's required to produce satisfactory (monochrome) pictures for most purposes. Indeed, the output one gets from a Linotronic at 1270dpi is more or less publishable; at full resolution, it almost definitely is (for my sort of images, anyway). 2. It should be possible to make a graphic extension to TeX (gTeX, say), along the same lines as TeX-XeT, which had the capability to draw simple vectors (and, of course, there'd have to be a corresponding `opcode' in the DVI files it generated); that would improve the speed of setting line graphics---using dot-drawing, like PiCTeX, is very slow. However, I'm not volunteering! Adrian F. Clark JANET: alien@uk.ac.essex.ese ARPA: alien%uk.ac.essex.ese@nss.cs.ucl.ac.uk BITNET: alien%uk.ac.essex.ese@ac.uk Smail: Dept. of Electronic Systems Engineering, Essex University, Wivenhoe Park, Colchester, Essex C04 3SQ, U. K. Phone: (+44) 206-872432 (direct) ---------------------------------------------------------------------------- Date: Thu, 16 Feb 89 09:50 EDT From: "Rick Caldwell, Data Services Division, 214-980-7924" Subject: Graphics in TeX--a response Keywords: graphics, TeX Great Idea! I believe that your primitives should be defined as .dvi commands similar to the existing dvi primitives that TeX uses now. That way the line drawing routines can be implemented by the dvi program writer in an effecient manner. I'm not sure if this is what you were asking for or if you were looking for the primitives to be implemented in TeX macro's? Put the primitives in the dvi program as TeX runs slow enought as it is. I would add one more primitive, a raster import primitive. This would allow input of existing rasters such as scanner input, paint program files, and other graphic program outputs. You would probably have to define a standard raster graphic format (or use an existing one such as the one being used on Compuserve as a standard raster interchange format between various brands of PC's). Otherwise you would have to have a program to read the existing raster file and convert it to short vectors and pixels which is very inefficient. The primitive might look something like: \rasindwn#1#2#3#4 raster input, raster lines going downward #1 raster format - to allow for different formats (packing schemes). If a standard format was required then this option wouldn't exist, otherwise if people would like a more flexible approach where several standard formats were allowed this would specify the format. #2 filename of the raster file #3 pixels per line, or bytes per line depending upon the graphic format. #4 number of pixels or bytes to actually include in the TeX file (may be less than or equal #3) #4 number of raster lines to include (may be less than the number actually in the file). \rasinup#1#2#3#4 raster input, raster lines going upward parameters same as \rasindwn Before issuing the raster input command you would use one of the positioning commands to set the origin of where the raster would start. Rick Caldwell Date: Thu, 16 Feb 89 13:47:13 EST From: beck@cs.cornell.edu (Micah Beck) Subject: Re: Graphics in TeX Keywords: graphics, TeX I applaud David Rogers' efforts towards defining a minimal graphics interface in the form of TeX macros. Unfortunately, the implementation he suggests may suffer from some of the same difficulties found in existing solutions. In his article, David notes that although PiCTeX is "portable" in the sense of being built on the standard TeX interface, not everyone can conveniently use it. This is because of the huge TeX memory array and the long processing time need to generate figures. What is needed from a TeX graphics standard is to be truly universal, in the sense that any TeX installation can conveniently handle it with no special configuration. One wants this level of compatibility for any conference paper which is submitted electronically, for example. The reason that PiCTeX uses a large memory array is not just that the macro package is large. It is rather that the technique of drawing lines using the period character as a pen generates a huge amount of "text" in a single TeX box, all of which must be held in memory at once. The implementation which David suggests will almost certainly suffer from the same limitations, and thus could not be universal. Without some extension to standard TeX, I doubt that any universal graphics solution is possible. One can however approach a universal solution by allowing the user a choice of output mechanisms. I'd suggest this approach for the implementation of David's minimal graphics interface. These means allowing the user to specify whether the graphics should be drawn PiCTeX-style; in PostScript; or using tpic \special commands. That way, the TeX macros become nearly universal by allowing users to choose the output mechanism which is most convenient to them. However, some users will still have no convenient option available. No graphics interface will be universally accepted if it does not allow the user to take advantage of the best graphics mechanism at their disposal. No no wants to use PiCTeX if they have a PostScript printer or can support tpic \specials. PiCTeX-style solutions never look as good as these lower level mechanisms, and are much more cumbersome to use. A word about the Standard Display File Format, and about TransFig. David's note gives the false impression that TransFig is somehow dependent on the Sun workstation. TransFig is a package which translates files from the Fig Display File Format (I call it Fig code) used by the Fig graphics editor, to many TeX-compatible graphics interfaces. While some versions of Fig are Sun-dependent, XFig, which is based on the X windowing system, is not. The use of Fig code need not be limited to the Fig graphics editor. For instance, the pic2fig program compiles the PIC graphics language into Fig code, and I am currently developing an application to produce numerical plots. Although Fig code is not as primitive nor as elegant as the Standard Display File Format David suggests, it can serve the function quite well. It is easy to translate to many graphics interfaces, and is easily extended. And because it has higher level object definitions like circles, it can be used as the intermediate form for an object-oriented editor like Fig. Most importantly: Fig is in widespread use, and by using Fig code as a Standard Display File Format, the imbedded base of Fig users can immediately benefit from compatibilty. I'm afraid we must support a selection of graphics mechanisms to achieve a universal graphics solution until TeX is somehow extended. Perhaps the easiest TeX standard graphics extension to adopt would be the tpic \special commands. And rather than introducing a new Display File Format, consider using Fig code. For more information on graphics mechanisms for TeX, TransFig, and Fig code, see the TransFig manual. It can be anonymously FTPed from svax.cs.cornell.edu as file ~ftp/pub/fig/transfig-man.dvi, and is also available as Cornell Technical Report #89-967. Micah Beck beck@cs.cornell.edu Dept of Computer Science Cornell University -------------------------------------------------------------------------- Date: Wed, 15 Feb 89 16:15 CST From: munnari!g.ua.oz.au!ATREVORROW@uunet.UU.NET Subject: Announcing OzTeX, a public domain TeX for the Mac Keywords: TeX, Macintosh I'm nearing completion of OzTeX, a public domain version of TeX for the Mac. I don't want to spend the rest of my life copying disks, so I'd like to hear from people willing to act as regional distributors. Any volunteers? I'd also like to hear from altruistic Macintosh programmers interested in helping with future development. Some info about OzTeX. The good news first: - Source code will be supplied. Everything is written in TML Modula-2 (which requires MPW). There is about 35,000 lines of code. - The application includes a DVI previewer, a PostScript driver, and of course TeX (actually IniTeX so users can create their own formats, although Plain and LaTeX will be supplied). The TeX module passes Knuth's trip test (for version 2.0 at least). - OzTeX is designed to be an open and expandable TeX system. It reads font information from standard TFM and PK files, and creates standard DVI files. If you have access to a Unix or VMS mainframe then you'll be able to Kermit such files to and fro without any extra processing. A basic set of TFM files and 300dpi PK files will be supplied. PostScript printer fonts are also supported. - I've seen TeXtures 1.0 and MacTeX 1.1 and I'd currently rate OzTeX below both in terms of features, somewhere between them in speed of typesetting/previewing/printing, but way ahead in terms of cost! Now the bad news: - There is currently NO integrated text editor (and I'm not sure that one is really necessary, what with MultiFinder and good DA editors available). - Support for inclusion of graphics is currently minimal. The previewer ignores \special commands and the PostScript driver only allows inclusion of a file, along with optional PostScript code. - The documentation (which I haven't even started yet) will assume some familiarity with TeX. OzTeX is NOT aimed at beginners, but at people who have used TeX, probably on a mainframe, and would like to use it on a Macintosh without paying $$$. Please do NOT send me requests for OzTeX. At this stage I only want to hear from people willing to act as distributors or interested in helping with the programming. Andrew Trevorrow ACSnet: atrevorrow@g.ua.oz Phone: (08) 267 1060 --------------------------------------------------------------------------- Date: Mon, 6 Mar 89 6:15:22 PST From: mackay@cs.washington.edu Subject: Turkish TeX Keywords: TeX, Fonts The interest in Turkish TeX seems to be growing, and I would like to collect addresses into a collective mailing list so that announcements of interest only for Turkish language document preparation can be sent out through that. At present the work centers around fonts, hyphenation, a turkicized tplain.tex, Turkish hyphenation patterns, and an editor based on PC-write for direct input in Turkish to a PC with EGA or VGA. This is hacker's stuff as yet. If you get the Turkish fonts, you get them in mf source format, and the rest is up to you, but the project is growing, and is enlisting cooperation most especially from Turkish universities. If you are interested, reply to mackay@cs.washington.edu DO NOT reply to the TeXhax list for this. For further information about the Turkish PC-write, (which feeds directly into Turkish TeX through the PR mechanism) get in touch with walter@UWAV1 (BITNET) or walter@UWAV1.ACS.WASHINGTON.EDU (Internet) selamlarimizla Pierre MacKay mackay@cs.washington.edu --------------------------------------------------------------------------- %%% The TeXhax digest is brought to you as a service of the TeX Users Group %%% in cooperation with the UnixTeX distribution service at the %%% University of Washington %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% BITNET: send a one-line mail message to LISTSERV@UWAVM %%% SUBSCRIBE TEXHAX % to subscribe %%% or UNSUBSCRIBE TEXHAX %%% %%% All others: send a similar one line mail message to %%% TeXhax-request@cs.washington.edu %%% Please be sure you send a valid internet address!! %%% in the form name@domain or name%routing@domain %%% and use the style of the Bitnet one-line message, so that %%% we can find your subscription request easily. %%% %%% All submissions to: TeXhax@cs.washington.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% JUNE.CS.WASHINGTON.EDU TeXhax/TeXhaxyy.nn %%% yy = last two digits of current year %%% nn = issue number %%% %%% For further information about TeX Users Group services and publications %%% contact Karen at KLB@SEED.AMS.COM or write to TUG at %%% TeX Users Group %%% P.O. Box 9506 %%% Providence, R.I. 02940-9506 %%% Telephone (401) 751-7760 %%% %%% Current versions of the software now in general distribution: %%% TeX 2.95 metafont 1.7 %%% plain.tex 2.94 plain.mf 1.0 %%% LaTeX 2.09 ( 8/10/88) cmbase.mf see cm85.bug %%% SliTeX 2.09 gftodvi 1.7 %%% tangle 2.9 gftopk 1.4 %%% weave 2.9 gftype 2.2 %%% dvitype 2.9 pktype 2.2 %%% pltotf 2.3 pktogf 1.0 %%% tftopl 2.5 mft 0.3 %%% BibTeX 0.99c dvipage 3.0 %%% AmSTeX 1.1d %%%\bye %%% End of TeXhax Digest ************************** -------