TeXhax@cs.washington.edu (TeXhax Digest) (02/16/89)
TeXhax Digest Thursday, January 19, 1989 Volume 89 : Issue 8
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:
Public Domain Version of TeX Needed for SUN 3
Bug in SBTEX
Graphics in TeX
-------------------------------------------------------------------------------
Date: Mon, 16 Jan 89 10:03:54 EST
From: nirc!gareth@hombre.masa.com (Gareth Gaston)
Subject: Public Domain Version of TeX Needed for SUN 3
Keywords:
If anyone could tell me where I could get a version of TeX that I can
compile on my SUN 3, I would be most appreciative. I am only connected
to the net via uucp and a 2400 baud modem. I don't mind spending a long
time down-loading it or I could order a tape from somewhere if need be.
Thanks Much,
Gareth Gaston, NYNEX Information Resources Company, (212) 608-8651
...!{sun|cmcl2|rutgers|uunet}!hombre!nirc!gareth
%%% Editors' note. The version you want is the TeX distribution for
%%% Unix systems. Send your requests to elisabet@max.acs.washington.edu
%%% or to mackay@cs.washington.edu
%%% General information about distributions is available in the
%%% pages of TUGboat.
-----------------------------------------------------------------
Date: Mon, 16 Jan 89 18:58:04 GMT
From: "Wayne G. Sullivan" <WSULIVAN%IRLEARN.BITNET@uwavm.acs.washington.edu>
Subject: Bug in SBTEX
Keywords: Bug, SBTEX
Several people have noted that SBTEX ignores characters beyond 255 if there
are more than 255 in one line. Future versions will give an error message
and halt with lines longer than 254 characters. 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.
-----------------------------------------------------------------------
Date: Mon, 16 Jan 89 15:56:05 EST
From: "David F. Rogers" <dfr@USNA.MIL>
Subject: Graphics in TeX
Keywords: TeX, graphics
The following will appear in TUGboat. It is presented here with
Barbara Beeton's permission in the hope that it will generate enough
interest to yield the suggested macros.
David F. Rogers
Computer Graphics and TeX -- A Challenge
by
David F. Rogers
dfr@usna.mil
Of late there has been considerable interest in the inclusion of graphics
output within a TeX document. Programs such as PiCTeX, gnuTeX, Fig, and
TransFig seek to provide a mechanism for the inclusion of graphics within a
TeX document. Each of these programs seeks to provide a nearly complete
environment for the design and generation of line art or halftones for
inclusion in TeX. All are worthwhile efforts. However, each suffers from a
serious problem -- device dependence. For example, the PiCTeX macro pachage
is too large to run on a Microcomputer or in fact many workstations -- it
really requires a special large implementation of TeX, Fig and TransFig are
graphics device dependent (Sun workstations), gnuTeX only generates LaTeX
compatible output, etc. Yet one of the strong attractions of TeX is its
device independence. TeX itself runs on literally dozens of different
machines from Crays, through the latest Silicon Graphics, Ardent, and Stellar
superminicomputer engineering/scientific workstations, to a lowly PC XT
running MS-DOS.
Systems such as PiCTeX, Fig, Transfig and gnuTeX basically require the user
to {\it recreate the graphical output}. This is rather inefficient.
There are literally dozens of graphics programs that produce
better graphical output more efficiently than any of these systems.
A SUGGESTED MINIMAL SET OF TeX GRAPHICS MACROS
An alternate technique for importing graphics into TeX is to use the \special
command. Unfortunately, this requires giving up device independence.
Further, not all dvi drivers support all \special commands.
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. The important question is how to do this easily and
efficiently. Fortunately, only passive graphics is contained in a
publishable document. Consequently, the functional requirements for graphics
is quite limited (see Refs. 1 and 2). Specifically, these are the ability to
move the writing instrument both invisibly and visibly about the writing
surface to create thin lines and small dots (points), to `plot' finite sized
areas called pixels in various colors or monochrome and to generate text at
specified size, orientation and location. It is convenient to be able to
specify movements and locations in either absolute or relative coordinates.
Additionally, it is convenient to be able to initialize the graphics system,
to explicitly exit the graphics system and to specify the size and location
of the writing surface. Finally, it is convenient to be able to specify the
thickness of thin lines.
A small suite of less than a dozen and a half Plain TeX macros can provide
this functionality. Only two of these functional requirements create
difficulties. Specifically, character generation at arbitrary orientations
is bothersome. Initially, character generation orientations should be limited
to horizontal and a 90 degree rotation counter-clockwise from the horizontal.
The latter can be accomplished by using Metafont to generate a rotated font.
The rotated font is positioned and displayed by stacking the character boxes
vertically.
Currently color is not normally incorporated into TeX documents. However,
with technological advances this is not far off. Hence, it must be provided
for.
THE MACROS
The macros and their calling arguments necessary to implement this
functionality are briefly described below. Unless otherwise specified
units are any acceptable TeX values.
\beginpicture (Begin picture)
Sets any required initial parameters. Saves all current
parameters.
\endpicture (End picture)
Resets all parameters to the saved values.
\viewport#1#2 (Viewport)
#1 The horizontal size of the area for the graphics.
#2 The vertical size of the area for the graphics.
Default size is \hsize by \vsize
The origin is in the lower left corner positive upward
and to the right.
Viewport is the common computer graphics name for this function.
\linethickness#1 (Line thickness)
#1 The thickness of a thin line. Default is 1pt.
\setrsl#1#2 (Set resolution)
#1 The number of pixels in the horizontal direction within the viewport.
#2 The number of pixels in the vertical direction within the viewport.
Set resolution applies only to the setpxl command given
below. It should be called only once within a picture.
\ma#1#2 (Move absolute)
#1 The distance to be moved invisibly in a horizontal direction
(x-direction) in absolute coordinates, i.e. from the origin
set by the viewport command.
#2 The distance to be moved invisibly in a vertical direction
(y-direction) in absolute coordinates, i.e. from the origin
set by the viewport command.
Moves the cursor from the current cursor position to that
specified by #1,#2 in absolute coordinates.
\mr#1#2 (Move relative)
#1 The distance to be moved invisibly in a horizontal direction
(x-direction) in relative coordinates, i.e. from the current
location of the cursor.
#2 The distance to be moved invisibly in a vertical direction
(y-direction) in relative coordinates, i.e. from the current
location of the cursor.
Moves the cursor from the current cursor position to that
specified by #1,#2 in relative coordinates.
\da#1#2 (Draw absolute)
#1 The distance to be moved visibly in a horizontal direction
(x-direction) in absolute coordinates, i.e. from the origin
set by the viewport command.
#2 The distance to be moved visibly in a vertical direction
(y-direction) in absolute coordinates, i.e. from the origin
set by the viewport command.
Draws a line from the current cursor position to that specified by
#1,#2 in absolute coordinates.
\dr#1#2 (Draw relative)
#1 The distance to be moved visibly in a horizontal direction
(x-direction) in relative coordinates, i.e. from the current
location of the cursor.
#2 The distance to be moved visibly in a vertical direction
(y-direction) in relative coordinates, i.e. from the current
location of the cursor.
Draws a line from the current cursor position to that specified by
#1,#2 in relative coordinates.
\pa#1#2 (Point absolute)
#1 The distance to be moved visibly in a horizontal direction
(x-direction) in absolute coordinates, i.e. from the origin
set by the viewport command.
#2 The distance to be moved visibly in a vertical direction
(y-direction) in absolute coordinates, i.e. from the origin
set by the viewport command.
Moves from the current cursor position to that specified by
#1,#2 in absolute coordinates and creates a dot at that point.
\pr#1#2 (Point relative)
#1 The distance to be moved visibly in a horizontal direction
(x-direction) in relative coordinates, i.e. from the current
location of the cursor.
#2 The distance to be moved visibly in a vertical direction
(y-direction) in relative coordinates, i.e. from the current
location of the cursor.
Moves from the current cursor position to that specified by
#1,#2 in relative coordinates and creates a dot at that point.
\text#1 (Text)
#1 The text string to be plotted.
The current font is used. Default is cmr10.
\tangle#1 (Text angle)
#1 The angle ccw in degrees from the horizontal at which text
is to be plotted. Initially only 0 and 90 degrees are allowed.
\setrgb#1#2#3 (Set rgp)
#1 The red component of the current drawing color.
#2 The green component of the current drawing color.
#3 The blue component of the current drawing color.
The red, green and blue components of the color are given as
decimal numbers in the range 0 to 1 with 0 representing no
intensity of the component and 1 full intensity.
Black is indicated by r = 0, g = 0, b = 0.
White is indicated by r = 1, g = 1, b = 1.
The default is black.
\setpxl#1#2#3#4#5 (Set pixel)
#1 The x-coordinate of the lower left corner of the pixel.
#2 The y-coordinate of the lower left corner of the pixel.
#3 The red component of the color of the pixel.
#4 The green component of the color of the pixel.
#5 The blue component of the color of the pixel.
A pixel is a finite area of the writing surface extending
to the right and upward from the location specified by the
coordinate given in #1 & #2.
The red, green and blue components of the color are given as
decimal numbers in the range 0 to 1 with 0 representing no
intensity of the component and 1 full intensity.
For monochrome (gray scale) images the monochrome value is
obtained by averaging the red, green and blue components.
\setgray#1#2 (Set gray levels)
#1 The number of gray levels available.
#2 Parameter that determines the gray level representation scheme.
p -- patterning (see Ref.~3 and below)
d -- dither (see Ref.~3)
Using patterning the maximum number of available gray levels
depends on the resolution of the output device.
With dither the specified maximum number of gray levels sets
the size of the dither matrix. It must be a power of 2.
\setlut#1#2#3 (Set look-up table)
#1 Number of red bits
#2 Number of green bits
#3 Number of blue bits
The number of shades or intensities of red, green, and blue
are 2^{#1}, 2^{#2}, and 2^{#3} respectively. The number of
colors is 2^{#1 + #2 + #3}.
IMPLEMENTATION CONSIDERATIONS
Since normal TeX output is ultimately onto raster scan devices, e.g.,
laser printers and digital phototypesetters, the line drawing macros must
implement Bresenham's line drawing algorithm (or a DDA) (see Ref.~3).
PiCTeX, in fact, does this using the period as the plotting character.
Although using the period as the plotting character achieves device
independence, if variable line thickness is required using only the period
as the plotting character is not sufficient.
Several alternate techniques suggest themselves. Two are mentioned here. The
first is to use Metafont to define graphic plotting characters, e.g. various
sized dots, squares or diamonds from which various thickness lines can be
constructed. The second is to directly define various size squares using
\hrule or \vrule (Ref.~4 page 64) to use in constructing the various
thickness lines. In either case the `symbols' should be overlapped to
decrease aliasing effects.
Inclusion of photographs or continuous tone images in TeX requires dealing
with pixels to digitally represent these pictures. Hence the \setpxl macro
above. Pixels have varying intensity. Printers use a photographic screen
process called halftoning to print continuous tone images. There are two
principal digital analogs of this process: patterning and dither (see
Refs.~3,5 or 6). Patterning gives up spacial resolution to achieve intensity
resolution. Dither introduces randomness into the digitized image to give
the impression of multiple intensity (gray) levels without losing spacial
resolution. Both, actually print only black `dots' on `white' paper. Both
are easily extended to color.
In patterning, elements of a small grid are either black or white. For
example a 2 x 2 grid using a single dot size yields 5 intensity levels as
shown here
.. .. . .
.. . .
The fifth intensity is, of course, no dots. Multiple dot sizes can be used.
Here, the number of intensity levels is (width x height of the grid )^(the
number of dot sizes + 1). From this it is easy to see that a 2 x 2 grid with
3 different dot sizes yields 256 different intensity (gray) levels. However,
not all these patterns necessarily yield unique intensity levels.
Monochrome images are quite adequately represented by 256 intensity (gray)
levels. Note also that 256 is precisely the number in a new TeX font. Thus,
one method of generating these intensity levels is to create a special
graphics font using Metafont. One word of caution is in order: the number of
2 x 2 patterns depends on the available spacial resolution. For example, For
a 2 x 2 pattern grid, an image digitized with 512 pixels acrossed its width
requires a minimum width on the page of a 300 dpi output device of 3.41
inches. This assumes that one physical output device dot is used for each
horizontal grid location. Thus, only 5 intensity levels are available. Higher
resolution output devices, e.g. phototypesetters yield more intensity levels.
Minimum acceptable output resolutions are 1000 -- 1200 dpi. Consequently,
300 dpi laser printers would be useful for proofing only. One additional
subtlety should be mentioned. Unless the patterns are carefully selected
patterned images moire as well as other undesirable patterns appear in the
output. These can be minimized by randomly rotating the patterns 90, 180
and 270 degrees. Unfortunately, unless a font rotation macro becomes
available, this feature requires four different graphics fonts.
Dither introduces controlled randomness into the digitized image to
produce the impression of multiple gray levels. Intensity resolution
is increased without loss of spacial resolution. The algorithm is
conceptually quite simple
for each scanline in the image
for each pixel along the scanline
determine the position in a dither matrix
i = (x Mod n) + 1p
j = (y Mod n) + 1
determine the pixel display value
if image pixel intensity(x,y) < dither matrix(i,j) then
write black pixel
else
write white pixel
end if
next pixel
next scanline
Details are given in Refs. 3 and 6. The number of apparent intensity levels
depends on the dither matrix. Dither matrices are square. Their sizes
typical increase by factors of 2, e.g. 2 x 2, 4 x 4 and 8 x 8. The
number of apparent intensity levels is the dither matrix size squared, e.g.
an 8 x 8 dither matrix yields 64 apparent intensity levels.
The optimal 2 x 2 dither matrix is
| 0 2 |
| 3 1 |
The 4 x 4 dither matrix, which can be derived from the 2 x 2 matrix, is
| 0 8 2 10 |
| 12 4 14 6 |
| 3 11 1 9 |
| 15 7 13 5 |
Additional intensity levels can be obtained using multiple dot sizes. TeX
has quite adequate facilities for implementing a dither algorithm.
USING THE MACROS
The set of TeX graphics macros described above can certainly be used
directly to create both line art and halftones. However, except for
touch-up work, that is not their intended use. Their intended use
is as the end product of a filter pipe (footnote pipe is used here in
the context of a UNIX or MS-DOS pipe) that can be processed by
TeX in a device independent way. Conceptually, the intended pipeline
is
The output of your favorite graphics program is saved into a file.
A program converts this format to a neutral file format here called the
standard display file format (.sdf).
A program converts the .sdf format to a TeX file containing only
the macro calls described above.
TeX processes this file in the normal fashion producing a .dvi file.
An output driver converts the .dvi file to some device dependent form,
e.g. Postscript, HP Laserjet+, phototypesetter, etc.
Assuming that the output of your favorite graphics program is already saved
in a file, then the UNIX pipe command line is
graf2sdf < graphicsfile | sdf2TeX > file.tex
STANDARD DISPLAY FILE FORMAT
The concept of storing a picture in a data file is part of current
international standards efforts. The applicable graphics standard is that
for the Computer Graphics Metafile (CGM) (see Refs.~7 and 8). However, the
CGM is somewhat more detailed and complex than required for the current
application. A simple alternative, here called the standard display file,
is given in Table 1. A similar concept has been in use at the authors' home
institute for more than a decade.
The first line of the standard display file contains an identification
string. Each subsequent line of the file begins with an operation code
number, followed by the appropriate information required by that operation.
All coordinate values are specified as floating point numbers in the range
$0\leq x\leq 1.0$, $0\leq y\leq 1.0$. All items are separated by commas.
A simple standard display file for a square is:
A square
0, 0.05, 0.05
2, 0.95, 0.05
2, 0.95, 0.95
2, 0.05, 0.95
2, 0.05, 0.05
Using the macros discussed above the corresponding TeX code is
\beginpicture
\viewport{2in}{2in}
\linethickness{2pt}
\ma{0.05}{0.05}
\da{0.95}{0.05}
\da{0.95}{0.95}
\da{0.05}{0.95}
\da{0.05}{0.05}
\endpicture
The format is simple enough that a picture can be generated or modified
using a text editor. The format also allows easy extension to include local
or additional functionality.
Table 1. Standard Display File (.sdf) Codes
Code Operation Parameters
0 Move Absolute x,y
1 Point Absolute x,y
2 Draw Absolute x,y
3 Move Relative Delta(x), Delta(y)
4 Point Relative Delta(x), Delta(y)
5 Draw Relative Delta(x), Delta(y)
6 Text Text string
7 Set color red, green, blue
8 Set look-up table red bits, green bits, blue bits
9 Set pixel x, y, red, green, blue
10 New frame
11 Pause
12 Set resolution xresolution, yresolution
99 Print message Message string
x,y are floating point numbers in NDC; i.e., in the range 0 <= x,y <= 1.0.
red, green, blue are floating point numbers in the range 0 <= red, green,
blue <= 1 with 0 = no intensity and 1 = full intensity. Red bits, green
bits, blue bits are powers of 2 (see Ref. 1 for a discussion of look-up
tables). This table is taken from Ref. 1.
CONCLUSIONS
The TeX graphics macros presented above provide all the capability
currently and for the near future required to include publication quality
line art within TeX source files. They also include all the required
capability to seriously begin experimenting with the direct inclusion of
halftone images within TeX source files. Including publication quality
halftone images within TeX source files requires both further development
of digital `halftoning' techniques and the general availability of higher
resolution output devices.
THE CHALLEGE
The Challenge is for the macro guru's to implement the above TeX graphics
macros and for the Metafont guru's to generated the required fonts.
I'll be happy to consult on the graphics aspects of the development, to test
the results and to implement the filter program from .sdf format files to
TeX.
REFERENCES
1. Rogers, David F. and Adams J. Alan, Mathematical Elements for
Computer Graphics, 2nd Edition McGraw-Hill Book Co., New York, 1989,
Appendix A.
2. Rogers, David F. and Rogers, Stephen D., A Raster Display Graphics
Package for Education, IEEE Computer Graphics & Application, Vol. 6, No. 4,
April 1986, pp 51-58.
3. Rogers, David F., Procedural Elements for Computer Graphics,
McGraw-Hill Book Co., New York, 1985.
4. Knuth, Donald E., The TeXbook, Addison-Wesley Publishing Co.,
Reading, MA, 1984.
5. Knuth, Donald E., Digital Halftones by Dot Diffusion,
ACM TOG Vol. 6, pp 245--273, 1987.
6. Jarvis, J. F., Judice, C. N., and Ninke, W. H., A survey of techniques
for the display of continuous tone pictures on bilevel displays. Comput.
Graph. Image Process., Vol. 5, pp 13-40, 1976.
7.``Computer Graphics Metafile for the Storage and Transfer of Picture
Description Information (CGM),'' ISO 8632-Parts 1 through 4: 1987;
also, ANSI/X3.122-1986.
8. Arnold, D.B., and Bono, P.R., CGM and CGI,
Springer-Verlag, Heidelberg, 1988.
-------------------------------------------------------------------------------
%%% 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.ACS.WASHINGTON.EDU
%%% 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
**************************
-------