TeXhax@cs.washington.edu (TeXhax Digest) (05/24/89)
TeXhax Digest Friday, May 5, 1989 Volume 89 : Issue 46
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:
Second report from the TUG DVI Driver standards committee
Announcement: A Maple Users Group
\topnewpage not in LaTeX 2.09?
Latex slanted line jaggies
-------------------------------------------------------------------------------
Date: Wed, 03 May 89 14:31:26 CDT
From: Don Hosek <U33297%UICVM.UIC.EDU@UWAVM.ACS.WASHINGTON.EDU>
Subject: Second report from the TUG DVI Driver standards committee
Keywords: dviware
**********************************************************************
* Report from the DVI Driver standards Committee *
**********************************************************************
By Tom Reid <X066TR@TAMVM1.BITNET>
and Don Hosek <U33297@UICVM.UIC.EDU>
The first few months of 1989 have shown a healthy increase in the
discussion in the DVI driver standards discussion. For those people
with network access, much has been done to provide for the
dissemination of the information which has come through our hands.
The group has a LISTSERV discussion group, DRIV-L, which is the
primary means of communication between its members. The list is set up
so that anyone who wants to contribute ideas may do so by sending mail
to DRIV-L@TAMVM1 (Bitnet) or DRIV-L@TAMVM1.TAMU.EDU (Internet). These
notes will be automatically be distributed to the membership of the
group.
Archives of past discussions as well as papers on the topic and the
current versions of standards documentation, programs, and macros are
stored on the Clarkson archive in the dvi-standard group. Individuals
with FTP access may obtain the files from sun.soe.clarkson.edu in the
directory pub/dvi-standard. Those without FTP access may still obtain
the files via e-mail using the same mechanism as is used by the LaTeX
style collection, substituting dvi-standard for latex-style where
appropriate. For example, to obtain the file driv-l.log8809 and a list
of other files, one might send a message to
archive-server@sun.soe.clarkson.edu which looks like:
path fschwartz%hmcvax.bitnet@clvm.clarkson.edu
get dvi-standard driv-l.log8809
index dvi-standard
By the TUG meeting in August, we hope to have much of the proposed
standard documented and available from the archive.
Bitnet users may also obtain log files from Listserv@tamvm1 by sending
the command
get driv-l log{\it yymm}
to Listserv@tamvm1 where yy is the last two digits of the year and mm
is the month, expressed as a two digit number. For example, to obtain
the log from September, 1988, one would send the command get driv-l
log8809 to Listserv. Listserv commands should be sent either as the
first line of a single-line mail message or as an interactive message
(TELL on CMS, SEND on VMS).
The remainder of this article outlines some preliminary results of
the committee's work. Persons interested in implementing portions
of this standard should contact check the Clarkson archive or contact
Robert McGaffey <McGaffey@ORN.MFEnet> to obtain the most recent
information on the standard.
1. \special commands
The committee has decided that the \special commands defined to date
will be labeled as "experimental" and later classified as
"production" after they've undergone sufficient testing to justify
the reclassification. Experimental \special commands are distinguished
by the prefix X_.
Further work on the precise syntactical rules for \special are under
development.
1.1 Interface
One of the early decisions of the committee was that \special will be
treated as a primitive command which the end user should never need
to type. Instead, \special should be accessed through a high level
macro set. This has the additional advantage that users at beta test
sites will usually not be affected by changes to the syntax or names
of \special commands. This is important since when a \special changes
status from "experimental" to "production," its name will change as
noted above.
The committee is developing macros for both plain TeX and LaTeX to
interface with the developing standard. At the present time, only
preliminary versions of these macros have been written, but a full
macro set for both plain TeX and LaTeX should be be available by the
publication time of this article.
1.2 Scope
\special commands have been broken down into six classes depending
on what portion of the DVI output they would affect.
Global: These \special commands affect the entire document. Examples
of this class of \special include commands for selecting duplex
printing or setting the printing orientation (portrait, landscape,
etc.).
Page: These \special commands affect only the page on which they are
printed. Examples of this class include requests for feeding of
special paper from an auxiliary tray ({\it e.g.,\/} for a cover
sheet) or a single-page change in orientation.
Box: These \special commands affect a block of output that is
enclosed in a TeX box (and thus is, by necessity on a single
page). For example, a command to rotate a block of text would fall
under this class.
Delimited: These \special commands are those that affect a block of
output which is not necessarily enclosed by a TeX box or contained
entirely on a single page. For example, a \special command to set
color would fall into this class.
Output generating: These \special commands are those which generate
self-contained output of some sort. For example, the X_vec
\special of Section 1.3 falls into this class.
Attribute setting: These \special commands modify the next output
generating command which appears on the current page. If no output
generating command follows an attribute setting command, the
command is ignored and the DVI driver program should issue a
warning. An example of this class of commands would be the
X_linewidth \special described in Section 1.3.
The remainder of this section will consist of additional notes on
those classes of \special commands which need additional comment.
Global specials
Global specials, it has been decided, will be required to appear on
the first page of the document. They will either be identified with
a prefix (X_global:), delimited by a pair of \special commands
(X_begin_globals ... X_end_globals) or some similar scheme.
One issue that has not been decided is whether the first page
containing the global \special commands should be the first page of
text or a special page on its own. Having global options specified as
part of the actual first page of text minimizes the impact on existing
drivers. However, it does present some problems with existing macro
packages in regard to ensuring that the options are output at the
right place. This problem stems from the fact that the \special
commands used to convey the options to the drivers are normally placed
in the body of the document. Macro packages which place headline text
or entirely separate title pages prior to writing the first part of
the "body" of the document will cause text to appear in the DVI file
before the global options. Headline text may or may not have any
impact upon the global options, but separate title pages will prevent
the global options from being on the first page of the DVI file. To
get around this problem, the mechanism used for passing global
information will need to "cooperate" with the output routine within
the macro package.
Requiring an entirely separate page at the start of the DVI file
avoids the need for special interaction with the output routines of
various macro packages. Instead of placing \special commands in the
body of the first page, a separate macro is used which issues a
separate \shipout containing the \special commands. This approach
makes things easier for programs which sort or otherwise reorganize a
DVI file since no culling of global options from the first text page
is necessary. However, the separate page technique has an undesired
effect: it produces a blank page on existing drivers which do not
understand the options page.
Box specials
A box \special command, since it will always be entirely typeset on a
single page, will be enclosed in a TeX box (\hbox or \vbox). In the
DVI output, box structure is reflected by surrounding push and pop
commands. For example, the TeX commands:
normal
\hbox{\special{abc} special}
text
generate the following DVI code:
"normal"
push
right
xxx "abc"
"special"
pop
right
"text"
A DVI driver can exploit this for a command such as X_rotate by
maintaining on the DVI stack, values for items such as rotation_angle.
Delimited specials
The committee has not found an effective way to deal with open block
\special commands yet. They will probably need to be issued in
cooperation with the output routine, to insure that every delimited
command is broken down into matching pairs of \special commands on
each page within its bounds.
This approach is necessary for two reasons:
o If pages are reordered for any reason (e.g., reverse ordering for
laser printers which stack output face up) the driver should not
need to have to scan the entire file to insure that it does not
inadvertently break up a pair of \special commands producing a
delimited command.
o Without special care being taken, an delimited command which spans
pages may inadvertently affect page headers and footers which are
typeset between the beginning and ending blocks.
1.3 Graphics commands
Three techniques for including graphics have been discussed. These
are:
1. Make graphics entirely with TeX primitives.
2. Use METAFONT to build a graphic as a font.
3. Allow the driver to include a device-specific graphic.
Graphics by TeX
Handling graphics entirely with TeX macros and primitives which use
dots or characters from a special graphics font is a technique which
has been in use for some time. The LaTeX picture environment and
PiCTeX work in this way with the former assembling characters from a
graphic font and the latter using closely spaced dots.
In TUGboat 10(1), (This article also appeared in TeXhax.89.007) David
F. Rogers proposed a series of TeX macros to provide plotting
primitives; these macros would generally be used by TeX input
generated by some graphics package. The macros which were proposed
created graphics by closely spacing dots along each line in the same
manner as PiCTeX.
The problem posed by creating graphics in this manner is that TeX must
store all of the graphic elements in memory at once for an entire page
quickly exceeding TeX's capacity.
To calculate the memory needs, the technique for positioning each dot
was defined. This is:
\kern\DX \raise\Y \hbox{\DOT}%
where \DX is a dimension register giving the displacement in the "x"
direction from the previous point and \Y is a dimension register
giving the displacement in the "y" direction from the reference point
of the graph. \DOT defines the plotting symbol and \DX accounts for
the width of this symbol.
In memory, TeX saves \kern\DX in a kern node, the raised hbox in an
hlist node, and the plotting symbol in a char_node. These take two
words, seven words, and one word of memory, respectively, for a total
of ten words per dot. A normal-size implementation of TeX with
64k-words of memory allows about 6000 dots to be positioned before it
runs out of memory (assuming that no other macros are loaded and
neglecting other text on the page). Spacing the dots at 100 per inch,
this gives about 60 inches which is not sufficient for many graphs.
To enhance the capacity of this graphics technique, we decided to use
a \special to add a vector drawing capability to TeX and DVI drivers
and use the \special instead of closely-spaced dots. This changes the
TeX command sequence to:
\kern\DX \raise\Y \hbox{%
\special{X_vec \number\XC \space
\number\YC}%
where \XC and \YC are dimension registers giving the components of the
vector. Component values in scaled points are likely to be six-digit
numbers with an additional minus sign for negative numbers. Thus, an
average length for the \special string is likely to be around 18
characters. In memory, a \special is saved in a two-word whatsit node
which points to the \special string. Thus the total memory needs,
counting the kern and hlist nodes, will average 29 words per vector
which allows roughly 2000 vectors. This may be sufficient for many
graphs, but falls somewhat short for complex three-dimensional surface
plots. (One sample 3D surface plot consisted of 13,000 vectors.)
Two \special commands have been defined for graphics of this sort (and
specialized commands for more complicated graphic elements will be
defined in the future). The commands defined are:
X\_linewidth n: Specify that the following vector is to be drawn with
a line width of n DVI units (scaled points for TeX). Vectors are
normally 1 point in width. If no vector follows the X_linewidth
\special on this page, the command is ignored and the DVI driver
program should issue a warning.
X\_vec Dx, Dy: Draw a diagonal line from the current point to the
point which is offset by Dx and Dy from the current point. Dx and
Dy are specified in terms of DVI units.
Graphics by METAFONT
A different approach to graphics inclusion is to use METAFONT to
produce the graphic as a character of a font and position it using
TeX's normal character positioning capabilities. The advantage of this
technique is that the graphic is in a format which many drivers will
already accept.
METAPLOT by Pat Wilcox (See the AmigaTeX notes of March 12, 1989 or
TeXMaG V3N3 for information about this package.) is one example of a
package which takes this approach.
However, the technique has a number of drawbacks: Graphic fonts are
resolution-dependent; a separate graphic font is needed for different
resolution devices. METAFONT records changes in pixel values across a
scan line when it builds a character. Thus, the memory needs depend
upon the complexity of the graphic in addition to the size and
resolution of the device. To circumvent this limitation, it is
necessary to break the whole graphic into smaller pieces. It is
important to ensure that the heights and widths of each piece are
integral numbers of pixels to allow them to be reassembled without the
alignment problems which occur for letters within words.
Including device-dependent files
With this approach, the DVI driver processes a special Graphics
Description File (GDF) which, among other things, indicates the names
and formats of separate graphic files in device-dependent format. A
driver searches this list to find a file in a format appropriate for
the device it supports. This allows a greatly simplified graphic files
to be defined for previewing purposes while a detailed, higher
resolution version is used when the DVI file is printed.
GDF files are processed both by TeX and by the DVI driver. TeX \inputs
the file and executes code at the start of the file. This code sets
some dimension and box registers giving the size of the graphic then
terminates with an \endinput to return control to the macro which did
the \input. The portion of the GDF file following the \endinput is
processed by the driver.
The driver section of the file consists of a series of keywords which
identify lines that apply to a particular graphics format, rotation,
etc. The driver scans these lines searching for a format which it
understands. Depending on the driver and the graphics format,
additional lines may have to be searched for other attributes such as
rotation. Eventually, the name of the graphics file to be included
will be found and the driver will incorporate it into the output file.
In TUGboat 10(1), Bart Childs, Alan Stolleis, and Don Berryman
suggested another scheme for using \special for inclusion of
device-dependent graphics files in "A portable graphics inclusion."
2. Additional reference material
In addition to the works mentioned in the Editor's note at the end
of our last report, the following may also be of interest:
Guntermann, Klaus and Joachim Schrod. "High quality DVI drivers"
Available from the Clarkson archive as the file
schrod-guntermann1.tex
Hosek, Don. "Proposed DVI \special command standard" Available from
the Clarkson archive as the file hosek1.tex.
In addition, anyone interested in implementing any portion of the
developing standard should read the logs available from the Clarkson
archive or Listserv@tamvm1.
Don Hosek Internet: U33297@UICVM.UIC.EDU
3916 Elmwood Bitnet: U33297@UICVM.BITNET
Stickney, IL 60402 DHOSEK@YMIR.BITNET
Work: 312-996-2981 UUNet: dhosek@jarthur.claremont.edu
JANET: U33297%UICVM.UIC.EDU@UK.AC.EARN-RELAY
-----------------------------------------------------------------------------
Date: Thu, 4 May 89 08:48:13 EDT
From: George Labahn <glabahn@watmum.waterloo.edu>
Subject: Announcement: A Maple Users Group
Keywords: Maple programming language
Announcement: A Maple Users Group
-------------------
The people involved with the development of the Maple
programming language would like to announce the creation of
a Maple Users Group information service. This service will
deal with issues that are important to users of Maple, and
will include
- reports of new features to be added to the system,
- bug reports
- user requests for help with the system
- user complaints (compliments) about system
- anything that Maple users will find of interest
- etc
The messages appearing on this information network will
come from the developers of Maple and anyone else from the
users group who would like to post an article or query to
the group.
If you would like to be part of this users group please
send an email request to
glabahn@watmum.waterloo.edu
We will then put your email address on our mailing list and
send you information on how to post messages to the group, etc.
George Labahn
Maple Group
University of Waterloo
----------------------------------------------------------------------------
Date: Thu, 4 May 89 15:24:13 met
From: Bo Thide' <bt@irfu.se>
Subject: \topnewpage not in LaTeX 2.09?
Keywords: LaTeX, \topnewpage
In the "COMMAND LIST" and "USER COMMANDS THAT CALL OR AFFECT THE OUTPUT
ROUTINE" portions of the latex.tex file (LaTeX 2.09) \topnewpage is
mentioned. However, this command is not defined anywhere. I had hoped
that this command could have been used to modify \section so that
the section title would span the full page also in two-column output.
Now, my section titles span only one column.
Is there any other solution to my problem?
--Bo
^ Bo Thide'--------------------------------------------------------------
| | Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
|I| [In Swedish: Institutet f|r RymdFysik, Uppsalaavdelningen (IRFU)]
|R| Phone: (+46) 18-403000. Telex: 76036 (IRFUPP S). Fax: (+46) 18-403100
/|F|\ INTERNET: bt@irfu.se UUCP: ...!mcvax!sunic!irfu!bt
~~U~~ -----------------------------------------------------------------sm5dfw
---------------------------------------------------------------------------
Date: Thu, 4 May 89 15:06:59 -0500
From: "J.D. McDonald " <mcdonald@uxe.cso.uiuc.edu>
Subject: Latex slanted line jaggies
Keywords: LaTeX, slanted lines
Latex users who have tried to use the Latex picture environment to
draw slanted lines like \put(0.,0.){\line{3,-1}{5.}}
on 300 d.p.i. laser printers are aware of the jaggies problem.
I have finally found a rather bothersome but mostly effective cure.
I make no guarantees that this won't break something else, and
sending it beyond your own site is probably a no-no - but,
here it is:
The problem arises from two sources: the max-drift problem in .dvi
drivers, and the intrinsic roundoff error when trying to lay
to characters touching end-to-end with lengths that are
incommensurate with the naturla dot pitch of the output device.
It appears that the only solution is a device-dependent one.
What I did is as follows:
I got into the files line10.mf and linew10.mf and changed the lengths
and heights of from 10pt# to 8.6724pt#. That is a magic length that
is almost exactly 36 pixels at 300 d.p.i.. I also increased the
size of the arrowheads, which are defined in terms of the character
sizes to compensate. I left the linewidths alone. I then remade
all the line fonts with Metafont (without preloaded cm, as mentioned
by Tomas Rokicki in a recent TeXhax.) Finally, I generated a new
lplain.fmt using Initex with the line10.tfm and linew10.tfm files.
This makes the roundoff error disappear for all \line{x,y}{something}
where neither x nor y is 5. A corresponding change to 30 instead
of 36 pixels fixes all but x or y == 4, and a change to 60 fixes
all, but at a big cost: the minimum line length grows.
This does not completely fix the problem if you are using Nelson
Beebe's device drivers as I do: the drift problem rears its ugly head.
I SEEM to have fixed it by removing the 5* part of one of the
if statements, making the correction occurs for vertical movements
just like for horizontal ones. Whether this occurs for other drivers I
have no idea.
You are warned that this is a kludge. The correct way would be to
call your new font line9 or linew9 and copy the \line macro into
your header using the 9 points fonts.
It MIGHT be possible to use 30 (or 35) instead of 30 just for the
"5" lines. I haven't tried it.
Of course this only works for 300 or 600 or 900 or 1200 d.p.i. printers.
For 1270 or more d.p.i. I doubt that it will hurt much.
Doug McDonald
------------------------------------------------------------------------------
%%% 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@xxx
%%% where xxx is the nearest geographical site in the
%%% tree shown below
%%% SUBSCRIBE TEX-L <your name> % to subscribe
%%% or UNSUBSCRIBE TEX-L
%%% Here is the BITNET re-distribution tree as shown in a recent
%%% REVIEW (The geography is guessed at from the subscription list)
%%%
%%% CLVM TAMVM1 FINHUTC
%%% | | (Finland, UK, Scand, CERN)
%%% | | |
%%% TeXhax ----> UWAVM ----- MARIST ----- EB0UB011 ----- BNANDP11
%%% | (France,Italy,Spain) (Belgium)
%%% | |
%%% UBVM HEARN --- DEARN
%%% (Netherlands) (Germany)
%%%
%%% Internet: 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 (2.98 coming) metafont 1.7
%%% plain.tex 2.94 plain.mf 1.7
%%% 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
%%% AmSTeX 1.1d
%%%\bye
%%%
End of TeXhax Digest
**************************
-------