TeXhax@cs.washington.edu (TeXhax Digest) (03/11/89)
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" <MANGANAR%GRPATVX1.BITNET@Forsythe.Stanford.EDU>
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 <zsd@PIG.DREA.DND.CA>
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 <shah@svax.cs.cornell.edu>
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" <TOM%MSRCVAX.BITNET@uwavm.acs.washington.edu>
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 <davis%scrsu1.sdr.slb.com@RELAY.CS.NET>
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
<davis%scrsu1%sdr.slb.com@relay.cs.net>
"to shatter tradition makes us feel free ..."
--------------------------------------------------------------------------
Date: Mon, 13 Feb 89 11:50 EST
From: <RICK%QUCDNAST.BITNET@Forsythe.Stanford.EDU>
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 <rokicki@polya.Stanford.EDU>
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" <RICK@usland.sdr.slb.com>
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 <your name> % to subscribe
%%% or UNSUBSCRIBE TEXHAX <your name>
%%%
%%% 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
**************************
-------