UKTeX V89 #17 Friday 5 May 1989
IMPORTANT - Changes in the format of the Aston Archive.
3rd UKTUG Meeting
UniTeX Systems' address
\everypage (as it were)
indexes to UKTeX and TeXhax
FAO Dunstan Vavasour, re. TeX-Unmoderated
(lack of) Subject lines in UKTeX leads to exclusion from synopsis !
"saving" points in MF
European TeX courses at Exeter 1989
concrete fonts in LaTeX
Second report from the TUG DVI Driver standards committee
APPENDICES AT THE END OF CHAPTERS
EPSON LQ Compatible
dvi to PS programs
Linotronic 300 mode_def
Editor Peter Abbott
Some systems were 'off' over Easter so the first two items from #16 are
repeated.
Latest TeXhax in the Archive is #32
Latest TeXmag in the Archive is V3N2
---------------------------------
Subject: IMPORTANT - Changes in the format of the Aston Archive.
Aston Archive Format
During May there will be a number of changes in the way information is
stored in the Aston Archive. The top level will be labelled
TEX-ARCHIVE
and the last 30 days files etc will refer to this structure. Access to
files via
PUBLIC
will be available for a limited period. Files will disappear from PUBLIC
during MAY. Not all files are currently available in the new archive but
they will be moved during May.
Also note the address for the mail server is now
texserver@uk.ac.aston.tex (UK format)
or
texserver@tex.aston.ac.uk (rest of the world)
As a reminder to get help on using the mail server please send a message to
texserver@uk.ac.aston.tex (UK format)
and include in the message the following lines all starting in column 1
---
return address in UK format
help
Peter Abbott
(on behalf of the Archivists)
---------------------------------
Subject: 3rd UKTUG Meeting
UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG
The 3rd UKTUG meeting is scheduled for
Wednesday July 5 1989 at Aston University, Birmingham
The proposed theme is
`Fonts, Design and Use'
(4th meeting early october in London)
UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG
---------------------------------
Date: Mon, 01 May 89 15:45:38
From: CS1CWM @ SHEFFIELD.PRIMEA
Subject: UniTeX Systems' address
Peter:
Ewart's address and the address of UniTex Systems remain the same for the
time being: they are (it is?)
UniTeX Systems
12 Daleview Road
Sheffield S8 0EJ
England
Tel: +44 742 351489
Tlx: 547938 for UniTeX
Ewart has moved to Bristol University and can be reached there by phone. At
present he cannot be reached by email but if anybody wants to send messages
through me I will pass them on when he's back in Sheffield at weekends.
Chris Martin (CS1CWM@SHEF.PA)
---------------------------------
Received: from caxton.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Mon, 1 May 89 17:39:50 BST
From: spqr@uk.ac.soton.ecs
Date: Mon, 1 May 89 17:42:43 BST
Message-Id: <21642.8905011642@caxton.ecs.soton.ac.uk>
Cc: lac@uk.ac.soton.ecs
Subject: \everypage (as it were)
Today I wanted to add a \special to every page (it rotates the page
through 90 degrees), and I ended up with
\special{dvitops:landscape}%
\edef\@PlainOutput{\the\output}%
\def\@LandScapeOutput{\@PlainOutput%
\ifnum\outputpenalty<-'1000000000\else\special{dvitops:landscape}\fi%
% the conditional seems necessary, for otherwise you never leave the document,
% as the final list never gets empty
effectively redefining the output routine, and it seems to do what I
want. But is there a more general way of doing what I want, which is
to output some special each time I vomit a page, without worrying
about whether some internal macro has reset \output temporarily?
I'm pretty ignorant of output routines, so I may not know something obvious.
The philosophical answer I may get back is that if I want to affect
every page, I should have an option on the dvi driver. But I have to
have a style file anyway, and it seems a pity to make users remember
to use specific options with some style files.
---------------------------------
Received: from robin.cs.nott.ac.uk by much.Cs.Nott.AC.UK id aa28494;
2 May 89 9:02 BST
Received: from clan by Robin.Cs.Nott.AC.UK id aa20880; 2 May 89 9:02 BST
Date: Tue, 2 May 89 9:02:15 BST
From: David Osborne <cczdao@uk.ac.nott.clan>
Subject: indexes to UKTeX and TeXhax
Message-ID: <8905020902.aa06247@clan.nott.ac.uk>
i have created keyword-in-context (kwic) indexes for UKTeX and TeXhax
for 1987, 1988 and 1989 (issues 01--15 for UKTeX, issues 01--25 for TeXhax).
the files are in the new [TEX-ARCHIVE] tree, in the directory
[TEX-ARCHIVE.DIGESTS.INDEXES] with filenames UKTEXyy.IDX and TEXHAXyy.IDX
where yy is the year.
i hope to keep the 1989 indexes reasonably up to date as new issues
of the digests appear; it can be automated once i get full communications
on my Unix system.
dave osborne
(on behalf of TeX Archive maintainers' group)
- --
David Osborne | JANET: d.osborne@uk.ac.nott.clan
Cripps Computing Centre | BITNET: d.osborne%uk.ac.nott.clan@ukacrl.bitnet
University of Nottingham |Internet: d.osborne%uk.ac.nott.clan@nsfnet-relay.ac.uk
Nottingham NG7 2RD, UK | (Phone: +44 602 484848 x2064)
---------------------------------
Date: Tue, 2 MAY 89 12:29:34 BST
From: CHAA006@UK.AC.RHBNC.VAXB
Subject: FAO Dunstan Vavasour, re. TeX-Unmoderated
Sender: JANET"CHAA006@UK.AC.RHBNC.VAXB" <CHAA006@UK.AC.RHBNC.VAXB>
Reply-to: Philip Taylor (RHBNC) <P.Taylor@Uk.Ac.Rhbnc.Vaxb>
Originally-to: $UK-TEX
Mailer: Janet_Mailshr V3.3a (02-Feb-1989)
Dunstan --- my attempts to acknowledge your request to join TeX-Unmoderated
resulted in failure. As your mail header contains conflicting information,
would you please advise me in the text of a mail message what the preferred
route is from Janet to your system ?
Philip Taylor (TeX Unmoderator)
Royal Holloway and Bedford New College.
Via: [000008010080.FTP.MAIL]; Sat, 29 Apr 89 18:55 BST
Date: Sat, 29 Apr 89 18:55:14 BST
From: mmdf@uk.ac.cam.cl
Subject: Mail Delivery Failure to uk.ac.rl.gm - Timeout
Sender: root@uk.ac.cam.cl
Message-ID: <8904291855.aa27947@scaup.cl.Cam.AC.UK>
The NIFTP process was unable to
deliver your mail to host uk.ac.rl.gm
over janet.
The reason given by the local host was:
The NIFTP process gave up after 43 attempts over 103 hours
Your message was not delivered to the following addresses:
Dunstan_Vavasour%uk.co.gec-epl@uk.ac.rl.gm
---------------------------------
Date: Tue, 2 May 89 16:09 BST
From: Harry Fearnley <HARRYF@UK.AC.OXFORD.VAX>
Subject: (lack of) Subject lines in UKTeX leads to exclusion from synopsis !
Peter
A minor quibble - it would be nice if a one-line synopsis appeared for *all*
contributions - in UKTeX V89 #16, there were at least 2 messages which
did not simply because the contributors failed to supply one. Could you
**strongly** encourage contributors to do so - their contribution/question
may be missed because it does not appear in the table of contents.
Thanks
Harry
+++Editor - The favourite culprits are contributors using VAX VMS systems.
It only requires the /opt option to allow you to include a subject line.
There are the others who also simply use the reply which gives the subject
RE: UKTeX V?? #?? +++
---------------------------------
Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 2683; Tue, 02
May 89 21:55:07 BS
Received: from UICVM by UKACRL.BITNET (Mailer X1.25) with BSMTP id 5378; Tue,
02 May 89 21:55:06 B
Received: by UICVM (Mailer R2.02) id 3136; Tue, 02 May 89 15:53:10 CDT
Date: Tue, 02 May 89 15:51:53 CDT
From: Don Hosek <U33297@EDU.UIC.UICVM>
Subject: "saving" points in MF
I figured out how to solve my problem with points the other night while
I was asleep (!)...
The reason I couldn't use save x,y was that I needed to keep the x and y
points that were passed to the radical; BUT if I did something like:
def beginradical(text t) =
begingroup;
save a,b;
forsuffixes $ = t: a$:=x$; b$:=y$; endfor
save x,y;
forsuffixes $ = t: x$:=a$; y$:=b$; a$:=whatever; b$:=whatever; endfor
enddef;
def endradical = endgroup enddef;
and then defined each radical to do something like:
def futatsu(suffix @,$) =
beginradical(@,$); % This used to be |beginradical(101,102,103,104)|
x101=x@+thick; y101=y102=y$-thick; x102=x$-thick;
x103=x@; y103=y104=y@+thin; x104=x$;
horiz(101,102); horiz(103,104);
endradical;
enddef;
The big difference in this approach is that rather than getting rid of the
points I want to destroy, I keep the points I want to save.
There's something wrong with TeX and MF... I wrote my best TeX macro while
drunk and solved my hardest MF problem while asleep :-)
- -dh
------------------------------------------------------------------
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: Wed, 03 May 89 15:24:31 BST
From: BOOTH.CM@UK.AC.EXETER
Subject: European TeX courses at Exeter 1989
Message-ID: <BOOTH.CM.PUHP@UK.AC.EXETER>
ADVANCE NOTICE
EUROPEAN TeX COURSES on behalf of TUG
Beginning/Intermediate TeX 10th--14th July 1989
Advanced TeX/Macro Writing 18th--22nd September 1989
Beginning METAFONT 26th--29th September 1989
These three courses are all taking place at Exeter University,
using networked IBM-PC compatibles etc etc. Note the new METAFONT
course (being given by Doug Henderson of PC METAFONT fame).
Watch this space for more details, or contact me on:
BOOTH.CM@EXETER
Cathy Booth, University of Exeter Computer Unit, Maths & Geology Building,
North Park Road, Exeter, EX4 4QE, Devon, U.K.
Tel: Exeter (0392) 263945
---------------------------------
Received: by vulcan. (4.0/SMI-4.0)
id AA05408; Wed, 3 May 89 17:41:41 BST
Date: Wed, 3 May 89 17:41:41 BST
From: alien@uk.ac.essex.ese.vulcan (Adrian F. Clark)
Message-Id: <8905031641.AA05408@vulcan.>
Subject: concrete fonts in LaTeX
Sender: JANET"alien@uk.ac.essex.ese" (Adrian Clark) <alien@uk.ac.essex.ese>
Has anyone out there yet written a "concrete LaTeX" :-) i.e., a style
file to make Knuth's concrete fonts available to LaTeX users?
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)
"The great tragedy of Science--the slaying of a beautiful
hypothesis by an ugly fact." -- T H Huxley (1825-95)
---------------------------------
Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 1601; Wed, 03
May 89 22:27:05 BS
Received: from UICVM by UKACRL.BITNET (Mailer X1.25) with BSMTP id 6879; Wed,
03 May 89 22:19:54 B
Received: by UICVM (Mailer R2.02) id 8996; Wed, 03 May 89 14:31:39 CDT
Date: Wed, 03 May 89 14:31:26 CDT
From: Don Hosek <U33297@EDU.UIC.UICVM>
Subject: Second report from the TUG DVI Driver standards committee
**********************************************************************
* 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, 04 May 89 12:27:39
From: PM1MJP @ SHEFFIELD.PRIMEA
Subject: APPENDICES AT THE END OF CHAPTERS
From +-------------------------------------+
| Dr M J Piff, |
| Department of Pure Mathematics, |
| University of Sheffield, |
| The Hicks Building, |
| Hounsfield Road, |
| SHEFFIELD S3 7RH, |
| England. |
| Tel. SHEFFIELD(0742)768555 Ext 4431 |
| JANET address: PM1MJP@UK.AC.SHEF.PA |
+-------------------------------------+
Subject: Dave Cook's request for a way of putting appendices in chapters.
% Dear Dave,
% The following seems to work, by setting up chapters locally. It is set
% up to only do a \clearpage with each appendix, rather than a \cleardoublepage.
% The problem with the table of contents marking is that there is a fixed
% width box for each sectional number, and you can easily overflow this width
% by having too many chapters. The l@part and l@chapter set \@tempdima,
% and the other l@ commands use the third parameter to \l@dottedtocline to
% set the width of the boxes. Thus, if your manual has a lot of chapters,
% and appendices up to M say, I suggest you set these values pretty large.
% The following should work for up to 99 chapters, and 26 appendices to each!
% Mike.
\documentstyle{book}
\newcounter{SavedChapter}
\makeatletter
\def\l@chapter#1#2{\pagebreak[3]
\vskip 1.0em plus 1pt % space above chapter line
\@tempdima 2.6em % width of box holding chapter number
\begingroup
\parindent \z@ \rightskip \@pnumwidth
\parfillskip -\@pnumwidth
\bf % Boldface.
\leavevmode % TeX command to enter horizontal mode.
#1\hfil \hbox to\@pnumwidth{\hss #2}\par
\endgroup}
\def\l@section{\@dottedtocline{1}{1.5em}{3.4em}}
\def\l@subsection{\@dottedtocline{2}{3.8em}{4.3em}}
\def\l@subsubsection{\@dottedtocline{3}{7.0em}{5.2em}}
\def\l@paragraph{\@dottedtocline{4}{10em}{6.1em}}
\def\l@subparagraph{\@dottedtocline{5}{12em}{7.1em}}
\newenvironment{Appendix}{%
\setcounter{SavedChapter}{\arabic{chapter}}
\setcounter{chapter}{0}
\def\thechapter{\arabic{SavedChapter}.\Alph{chapter}}
\def\@chapapp{Appendix}
\def\chapter{\clearpage \thispagestyle{plain} \global\@topnum\z@
\@afterindentfalse \secdef\@chapter\@schapter}
\def\@chapter[##1]##2{\ifnum \c@secnumdepth >\m@ne
\advance\c@chapter 1 \edef\@currentlabel{\p@chapter \thechapter}
\typeout{Appendix\space\thechapter.}
\addcontentsline{toc}{chapter}{\protect
\numberline{\thechapter}##1}\else
\addcontentsline{toc}{chapter}{##1}\fi
\chaptermark{##1}
\addtocontents{lof}{\protect\addvspace{10pt}}
\addtocontents{lot}{\protect\addvspace{10pt}} \if@twocolumn
\@topnewpage[\@makechapterhead{##2}]
\else \@makechapterhead{##2}
\@afterheading \fi}
}{\setcounter{chapter}{\arabic{SavedChapter}}}
\makeatother
\begin{document}
\tableofcontents
\setcounter{chapter}{55}
\chapter{one}\null
\begin{Appendix}
\setcounter{chapter}{12}
\chapter{Appendix 1.A}\null
\chapter{Appendix 1.B}\null
\end{Appendix}
\chapter{two}\null
\end{document}
---------------------------------
Date: Thu, 4 May 89 12:49 GMT
From: DR. JOHN CARROLL, NIHE, DUBLIN 9 <75003678@VAX1.NIHED.IE>
Subject: EPSON LQ Compatible
Hello Peter,
We have am EPSON LQ 1500 compatible printer in NIHE (the model is in
fact a STAR NB 24-15 which I understand is quite popular in the UK).
Do you know if a TeX driver exists for such printers (in the Archive
or elsewhere).
Your advice will be appreciated.
Best wishes,
John Carroll
~~~~~~~~~~~~
---------------------------------
From: Sebastian Rahtz <spqr@uk.ac.soton.ecs>
Date: Thu, 4 May 89 19:35:12 BST
Message-Id: <26177.8905041835@hilliard.ecs.soton.ac.uk>
Subject: dvi to PS programs
There is considerable confusion over public domain dvi to PostScript drivers.
The Aston archive contains a number of different offerings, and it
might be helpful to list them here, in a rearranged setup which I hope
Archive users will find useful. The drivers are all to be found in
[TEX-ARCHIVE.DRIVERS.DVI2PS]
There are other systems in [TEX-ARCHIVE.DRIVERS] which create
PostScript, but these are the obvious ones commonly in use:
[.CARLETON] The original Unix Carleton/MIT version (Neil Holtz etc), now
more or less redundant. No support for PS fonts.
[.OOSTRUM] A much newer and improved version of Carleton by Piet van
Oostrum, which uses PostScript fonts etc (as recently posted
on eeunet).
[.DVI-TO-PS] An update of Carleton, done in parallel with Oostrum,
from Washington. Does not use PS fonts (I think).
[.PSDVI] A PS fonts *only* program, presumably of limited use!
[.DVITOPS] A completely new program by James Clark, supporting
PS fonts, figures etc.
If you want to include PS figures, you need the `psfig' macros for all
but dvitops, which includes builtin support for EPSF files.
Stephan Bechtolsheim's "yet another dvi2ps", called dvitps, is being
obtained at the moment. The other obvious ones to try, if none of
these have what you need, are Trevorrow's PSPRINT (but that is Vax
specific, I believe), and the commercial offerings of Arbortext and
Personal TeX.
What to do, if you are just entering the field? My advice would be as follows:
a) are you a VMS Vax? get Trevorrow's software. well-tested and in
widespread use
b) are you a fairly standard Unix site? get Clark's dvitops or
Oostrum's dvi2ps. If you want a choice of TeX or Adobe encoding,
Clark or Bechtolsheim offer specific support.
c) MSDOS? Dominik Wujastyk reports success with dvitops.
d) do you want some LaTeX font setups and style files? you'll find
offerings of amended lplain.tex & lfonts.tex and/or style files in:
[TEX-ARCHIVE.DRIVERS.DVI2PS.OOSTRUM]
[TEX-ARCHIVE.DRIVERS.DVI2PS.DVITOPS]
[TEX-ARCHIVE.FONTS.ADOBE.PSLATEX.WOLCSKO]
[TEX-ARCHIVE.FONTS.ADOBE.PSLATEX.TAYLOR]
Its not obvious which are "best". I'll leave recommendations to others!
Would anyone care to comment on the above, and flesh out this catalogue?
Where do all those DEC printers called LN0* fit into this?
Sebastian Rahtz
---------------------------------
Date: 4-MAY-1989 22:08:31 GMT
From: EFIA4580@UK.AC.QUEENS-BELFAST.CENTRE.VAX1
From : S.Gilmore@uk.ac.qub.v1
Stephen Gilmore
Department of Computer Science
The Queen's University of Belfast
University Road
Belfast BT7 1NN
Northern Ireland
Dear Mr. Abbott,
I'd like to get the AMS symbol founts for our VAX/VMS implementation
of LaTeX. I was able to get the 10 point PXL files from
[PUBLIC.TEX.AMSFONTS.PXL300] but I cannot find 11 or 12 point
versions. I tried to make them from the 329 and 360 PL files but
without success - in particular DVItoVDU crashes when using the PXL
files (which I generated using PKtoPXL). Do 11 and 12 point versions
exist for the VAX? If so, could you get them for the archive?
I'm not a TeXnician: just a Formal Methodist seduced into computer
typesetting. It may be possible to make the larger point files
with the tools available but I don't know how.
Thank you.
Yours sincerely,
Stephen Gilmore
---------------------------------
Date: Fri, 5 May 89 9:43 GMT + 1200
From: TeXnician <GRAEME@NZ.AC.OTAGO>
Subject: Linotronic 300 mode_def
Mode Def for Linotronic 300.
Could somebody please supply me with the appropriate METAFONT mode_def for a
Linotronic L300 PostScript imagesetter. I would like to produce camera-ready of
a LaTeX document that uses the Times Family of fonts (PostScript version) but
also the CM Symbol (10pt only) and the CM Uppercase Greek (10pt) which I have
hacked out of the CMR10 font. Only these 2 CM fonts are used in this document
and the Greek font only consists of 12 (or 14?) characters.
Also, what resolution is it best to produce them (i.e., the CM fonts used)
at---1270 or the full 2540dpi?
Why I am on the subject---the new Compugraphic 9600P PostScript image setter
looks pretty good (and reasonably priced albeit too expensiove for us at this
stage). Has anybody had any experience with it yet? What about the new
Varityper 4300P PostScript Imagesetter? Both of them look superior (and
cheaper---at least in New Zealand) than the comparable Linotronic L200.
Graeme McKinstry
Computing Services Centre,
University of Otago,
Dunedin,
NEW ZEALAND.
E-mail: graeme%otago.ac.nz@relay.cs.net
---------------------------------
!!
!! Files of interest
!! [public]000aston.readme [public]000directory.list
!! [public]000directory_dates.list [public]000directory.size
!! [public]000last30days.files
!!
!! Editor - I have a tape labelled TeX 2.95 LaTeX 2.09 Metafont 1.7
!! Unix 4.2/3BSD & System V. Tar 1600 bpi blocked 20 1 file dated
!! 30 January 1989 (from washington.edu).
!!
!! FTP access site uk.ac.aston.tex
!! username public
!! password public
!!
!! I have the facility to copy this tape for anyone who sends the following
!! 1 2400 tape with return labels AND RETURN postage. (2.50 pounds sterling
!! for UK users, payable to `Aston University') Outside UK please ask me.
!! UK users send 4.25 for two tapes or 6.60 for three tapes.
!! Send to
!!
!! P Abbott
!! Computing Service
!! Aston University
!! Aston Triangle
!! Birmingham B4 7ET
!!
!! A VMS backup of the archive requires 2 (two ) 2400' tapes at 6250bpi.
!! Remaining details as above.
!!
!! Exabyte tape drive with Video 8 cassettes.
!!
!! Same formats available as 1/2in tapes. We use the following tapes
!! SONY Video 8 cassette P5 90MP, MAXCELL Video 8 cassette P5-90
!! TDK Video 8 cassette P5-90MPB
!! Postage 35p UK (stamp please), 1 pound sterling Europe, other areas 2 pounds
!!
!! Replies/submissions to info-tex@uk.ac.aston please
!! distribution changes to info-tex-request@uk.ac.aston please
!!
!! end of issue