[comp.text.tex] UKTeX Digest V90 #24

uktex@uk.ac.aston (07/28/90)

-----------------------------------------------------------------------------
UKTeX V90 #24                                             Friday 27 July 1990
-----------------------------------------------------------------------------

Today's topics:
		       RE: placement of figures
		    RE: DVI Driver for HP DeskJet+
			    RE: For UKTeX
		   Re: 24 pin Epson printer driver
	      RE: Landscape mode for HP Laserjet driver?
		   Re: funnies in the Aston archive
			RE: New Version of TeX
     The Level 0 Draft standard (v 0.03) -- Request for comments
  Specification of algorithim for handling rounding to device units
			      Notes on:
		    mode_def for IBM 4216 printer?
		   further funnies in the Archive.
			   LaTeX book style
		TeXserver gains reverse-address sanity
		 \errorcontextlines setting in LaTeX
		     HP DeskJet driver (dvidjp.c)
		       Problems with TFM files
	      PostScript previewer for VAXstation 3100?
     Seeking Questionnaires from the TUG '90 Meeting in TeXas...
				bibtex
		       OzTeX hash size increase
				\pmod

-----------------------------------------------------------------------------
Moderator:       Peter Abbott
This issue edited by:
                 David Osborne (University of Nottingham)
                   <d.osborne@uk.ac.nott.clan>
Submissions:     uktex@uk.ac.aston
Administration:  uktex-request@uk.ac.aston

Back Issues:     These are stored in the Aston archive, in the directory
                 DISK$TEX:[TEX-ARCHIVE.DIGESTS.UKTEX.90]
Latest TeXhax:    #51
Back Issues:     These are stored in the Aston archive, in the directory
                 DISK$TEX:[TEX-ARCHIVE.DIGESTS.TEXHAX.90]
Latest TeXmag:    V4 N2 
Back Issues:     These are stored in the Aston archive, in the directory
                 DISK$TEX:[TEX-ARCHIVE.DIGESTS.TEX-MAG]

-----------------------------------------------------------------------------

Subject:        RE: placement of figures
Date: Mon, 16 JUL 90 12:05:43 BST
Originally-from:P.TAYLOR@UK.AC.RHBNC.VAX

Sebastian ---

>anyone out there having a rainy weekend and wants something to think
>about? I am preparing a longish book with LaTeX (200 pages) with a lot
>of floating tables and figures. the publisher complains, rightly, that
>there are occasions when I refer to a table/figure on a right hand
>page, and the object itself comes on the following left-hand page,
>forcing the reader to keep turning the page (as opposed to flicking).
>The figure is inserted in the text at the same place as the reference.
> 
>SO, anyone got any suggestions about how to fix this up? it strikes me
>as almost impossible to do algorithmically, even if LaTeX understood
>about forcing tables/figures onto odd-numbered pages.

Ian Gibson and I spent a lot of time investigating this problem in the
preparation of "The Principles of Nutrional Assessment", and ended up
fine-tuning the TeX source to achieve the desired end.  

	`while' there are still figures in the wrong place
	`do' `begin'
	     `edit' the TeX source, adjusting the positions of figures and refs;
	     `TeX' the resulting file;
	     `Preview' the resulting DVI file
	     'end

	[An algorithm if ever I saw one ..... !]

						** Phil.
------------------------------

Subject:        RE: DVI Driver for HP DeskJet+
Date: Mon, 16 JUL 90 15:32:53 BST
Originally-from:P.TAYLOR@UK.AC.RHBNC.VAX

Ben ---

>Does anyone know of a good DVI driver (for MSDOS) for an HP DeskJet of
>DeskJet Plus?

RUMDJET.  A copy has been distributed to the Archive group, and a copy
will probably appear in the UK TeX archive in the near future.  ** Phil.

------------------------------

Subject:        RE: For UKTeX
Date: Wed, 18 JUL 90 11:56:06 BST
Originally-from:P.TAYLOR@UK.AC.RHBNC.VAX

>13 July 1990
>Your reference
>Our reference IC/SAS/0090Z/15
>Extension 2640
> 
>Dear peter,
> 
>Further to our telephone conversation today, I confirm that I would be 
>interested in anywhere that Lloyd's of London could acquire .pk files for 
>the following TeX fonts (I have the .trm's):
> 
>Palatino
>New Century Schoolbook
>Times
>Zapf Chancery
>Zapf Dingbats
>Bookman
>Courier
>Helvetica

The gentleman should be advised to contact Richard Kinch, of the Kinch
Computer Company, 501 S. Meadow St., Ithaca, New York 14850,
who will be pleased to supply these fonts in all canonical sizes
for a mere $200-00.  ** Phil.

------------------------------

Subject:        Re: 24 pin Epson printer driver
Date: Wed, 18 Jul 90 16:37:19 bst
Originally-from:SPQR@UK.AC.SOUTHAMPTON.ECS

NDN@UK.CO.NATIONAL-PHYSICAL-LAB.SEG writes:
 > The title says it all really - does anyone know of a DVI driver
 > giving output for 24 pin Epson printers?

the emTeX package offers these; god knows if any of them have 24 pins.

        dvifx   Epson FX-80/100 (horizontal resolution 240dpi, 216dpi vertical)
        dvip6l  NEC P6/P7 (180dpi)
        dvip6m  NEC P6/P7 (horizontal resolution 360dpi, 180dpi vertical)
        dvip6l  NEC P6/P7 (360dpi)
        dviitoh C.Itoh 8510A
        dviaiw  Apple Imagewriter


sebastian

------------------------------

Subject:        RE: Landscape mode for HP Laserjet driver?
Date: Wed, 18 JUL 90 18:20:35 BST
Originally-from:P.TAYLOR@UK.AC.RHBNC.VAX

Nick ---

>Is there available a driver for the HP Laserjet which supports
>landscape mode? There is some correspondence in the Beebe collection
>which suggests that one exists but there is no code for it. Any help
>gratefully received,

I think you will find that one of the EM-TeX drivers will do landscape
(and considerably more besides).  ** Phil.

------------------------------

Subject:        Re: funnies in the Aston archive
Date: Thu, 19 Jul 90 16:31:06 bst
Originally-from:SPQR@UK.AC.SOUTHAMPTON.ECS

CUDAT@UK.AC.WARWICK.CU writes:
 > While looking through the Aston archive a week or two ago I
 > found the following things:-
thanks for taking the trouble to look!


 > The file [TEX-ARCHIVE.LANGS.XETTEX]00README.TEX doesn't seem to say
 > an awful lot.
 deleted

 > The file [TEX-ARCHIVE.FONTS.CMFONTS.PK.PK300]CMR10.300PK
 > seems to contain a bad fount.  (I did remember not to copy it as a
 > text file, and several other founts in the same directory
 > seem fine.)
I have sent a fresh copy.

 > The file [TEX-ARCHIVE.TEX.MS-DOS.EMTEX]DVIDRV.ENG seems to differ
 > substantially from the file called DVIDRV.ENG in the archive
 > in ENGDOC.BOO .
hmm. odd. I have sent a fresh copy anyway

 > The file [TEX-ARCHIVE.DOC]ARCHIVE.TEX doesn't mention the
 > [TEX-ARCHIVE.TEX.MS-DOS....] directory.
that file is way out of date; I have deleted it

 > Many thanks to the archivists for looking after all the goodies,
 > and I hope the above remarks help to make things even better.
keep 'em coming!

sebastian

------------------------------

Subject: RE: New Version of TeX
Date: Fri, 20 JUL 90 16:34:02 BST
From: TEX@UK.AC.CRANFIELD.RMCS

                               TeX V3 for VAX/VMS
                               ~~~~~~~~~~~~~~~~~~
			       
In response to popular demand from those who don't have the resources
and/or inclination to build TeX v3 from sources, I have installed the
following VAX/VMS .OBJ files at Aston, together with other files required
to run TeX.  They are provided as object files to permit you to link them
under your current version of VMS, since some users are still on v5.0 (or
earlier) whilst others are more up-to-date.

This version of TeX requires that you SET COMMAND TEX, using the TEX.CLD
file to be found in [TEX-ARCHIVE.TEX.V3.VMS] at Aston.  Don't forget to
move the .FMT files, and TEX.POOL, into TEX$FORMATS:  The distributed
version of TEX.CLD expects the .EXE files to reside in TEX$EXE, but this
can be changed with an editor.  But TeX itself ONLY looks in TEX$FORMATS
for its pool file.

[TEX-ARCHIVE.BINARY.VMS]BIGINITEX.OBJ
[TEX-ARCHIVE.BINARY.VMS]BIGTEX.OBJ
[TEX-ARCHIVE.BINARY.VMS]BIG_TRIP.OBJ
[TEX-ARCHIVE.BINARY.VMS]DVITYPE.OBJ
[TEX-ARCHIVE.BINARY.VMS]INITEX.OBJ
[TEX-ARCHIVE.BINARY.VMS]LPLAIN.FMT
[TEX-ARCHIVE.BINARY.VMS]PLAIN.FMT
[TEX-ARCHIVE.BINARY.VMS]PLTOTF.OBJ
[TEX-ARCHIVE.BINARY.VMS]POOLTYPE.OBJ
[TEX-ARCHIVE.BINARY.VMS]SPLAIN.FMT
[TEX-ARCHIVE.BINARY.VMS]TANGLE.OBJ
[TEX-ARCHIVE.BINARY.VMS]TEX.OBJ
[TEX-ARCHIVE.BINARY.VMS]TEX.POOL
[TEX-ARCHIVE.BINARY.VMS]TFTOPL.OBJ
[TEX-ARCHIVE.BINARY.VMS]TRIP_INITEX.OBJ
[TEX-ARCHIVE.BINARY.VMS]WEAVE.OBJ

                               Brian {Hamilton Kelly}

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ JANET:     tex@uk.ac.cranfield.rmcs                                     +
+ BITNET:    tex%uk.ac.cranfield.rmcs@ac.uk                               +
+ INTERNET:  tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk                  +
+ UUCP:      ...!mcvax!rmcs.cranfield.ac.uk!tex                           +
+         OR ...!ukc!rmcs.cranfield.ac.uk!tex                             +
+ Smail:     School of Electrical Engineering & Science, Royal Military   +
+            College of Science, Shrivenham, SWINDON SN6 8LA, U.K.        +
+ Phone:     Swindon (0793) 785252 (UK), +44-793-785252 (International)   +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

------------------------------

Subject: The Level 0 Draft standard (v 0.03) -- Request for comments
From: Don Hosek <DHOSEK%EDU.CLAREMONT.HMCVAX@UK.AC.NSFNET-RELAY>
Date: Sat, 21 Jul 1990 20:05 PDT
Originally-To:  texhax@edu.washington.cs.june, infotex@uk.ac.aston,
                tex-euro@bitnet.dhdurz1

Below is the Level 0 standard (draft 0.03) which will be in its final 
form for publication in the last regular issue of TUGboat for 1990.

In the last month before the standard is being put in its final form, 
the TUG DVI standards committee is soliciting opinions from the TUG 
membership. If you have any comments about the specifications listed 
below, please send them to dhosek@ymir.claremont.edu, or, if that does 
not work, dhosek@ymir.bitnet.

The appendices referenced are taken more-or-less directly from the 
descriptions of the file formats in DVItype, GFtype, PKtype and TFtoPL. 
The rounding error appendix will be sent separately.

-----------------------------------------------------------------------

\documentstyle[ltugboat]{article}
\title{A Draft Proposal for the ``Level~0'' {\tt DVI} Driver Standard}
\author{Don Hosek\thanks{On behalf of the TUG {\tt DVI} Driver Standards
   Committee}}

\makeatletter
\newcounter{impnote}
\def\theimpnote{\alph{impnote}}
\def\impnote#1{{\def\@mpfn{impnote}%
  \let\thempfn=\theimpnote
  \footnote{#1}}}
\makeatother

\def\tensl{\sl}

\let\App=\appendix
\def\appendix{\App\small} % tighten up the ending pages of the standard.

\hbadness=9999 % Cut down the amount of annoying messages generated...

% For file format descriptions:
\def\res#1{{\bf #1}}
\def\sty#1{{\it #1}}

\begin{document}
\maketitle

\emergencystretch=\hsize
\divide\emergencystretch by 10 % I think this will encourage 10 
words/line


\begin{abstract}
The following represents a minimal standard (level~0) for {\tt
DVI}
drivers. The complete standard will be presented as a series of
``tiers'' requiring increasingly stringent control over the
output of {\tt DVI} drivers. A trip test for {\tt DVI} drivers will be
created which will allow developers of {\tt DVI} drivers to insure that
their drivers meet the standards developed here. The
specifications here should be considered minimal and driver
developers are encouraged to write drivers whose capabilities are
beyond these specifications.

This version of the Level~0 Standard presented here is
draft~0.03. It has been reviewed by the TUG Driver Standards
Committee and is now being presented to the TUG membership at
large for review. This will form one portion of the TUG {\tt DVI}
Driver Standard. 
\end{abstract}

\section{Purpose of the Level~0 standard}

The Level~0 Standard is meant to be a base standard to which all 
drivers should adhere. It is intended to allow all reasonable
applications to be printed on all drivers.

The basis for many of the specifications in this standard is the
possible output of \TeX82; functions which can be implemented via
a pre-processor are generally omitted ({\em e.g.,\/} page
selection and sorting).

Footnotes beginning with a letter are implementation notes and are
hints on handling difficult circumstances for printers.



\section{The {\tt DVI} file}

As a rule, {\tt DVI} drivers should be able to interpret any {\tt
DVI} file which falls within the following limits. These
specifications are a {\em minimum\/}; good drivers will probably
be able to handle {\tt DVI} files exceeding these limits ({\tt
DVI} files which exceed the limits are likely  to be rare, but
might still occur).

\subsection{{\tt DVI} commands}

The driver should be able to interpret every {\tt DVI} command
listed in appendix~\ref{dvi-format}. % See file dvi.tex

\subsection{Characters}
\subsubsection{Number of characters in a {\tt DVI} font}

The driver should be able to handle fonts which have characters
at any code in the range $0\le c<256$.\impnote{Some output devices will
require {\tt DVI} fonts with more than a given number of
characters to be broken into two or more device fonts when
downloaded to the printer.}

\subsubsection[{\tt DVI} character size]{{\tt DVI} character
size\footnote{The values presented here and in the following
sections are preliminary and
subject to modification.}}

The driver should be able to print any character up to a  size of
600pt (horizontal) by 800pt (vertical).\impnote{Note that some
output devices will require breaking down such a character into
smaller  pieces or drawing the character in graphics mode.}

\subsubsection{Number of {\tt DVI} characters per page}

The driver should be able to print a page containing as many as
20,000 {\tt DVI} characters.

\subsubsection{Unusual characters}

The driver should correctly handle (a)~characters with empty
bitmaps ({\em e.g.,\/} the \SliTeX\ fonts) including characters
whose horizontal escapement is~0, (b)~characters whose
printable image is wider than its horizontal escapement, and
(c)~characters with a negative horizontal escapement.

\subsection {Rules}
\subsubsection{Rule size}

The driver should be able to print rules of any size up to 600pt
(horizontal) by 800pt (vertical).

\subsection{Number of rules per page}

The driver should be able to print a page containing as many as
1000~rules.

\subsection{Stack}

The driver should have, as a minimum, a stack depth of 100 for
{\tt DVI} {\it push\/} and {\it pop\/} commands.

\subsection{Positioning on the page}

\subsubsection{Location of the origin}

The point $(0,0)$ in {\tt DVI} co\"{o}rdinates should be located
at a point one inch from the top of the page and one inch from
the left side of the page. 

\subsubsection{Changes in position due to characters and rules}

The driver should accurately track movement using the pixel width
from the font raster file and the {\tt TFM} width from either the
font raster file or {\tt TFM} file with the {\tt TFM} width from
the font raster file taking priority. This is described in
appendix~\ref{rounding-algorithim}.

Positioning of rules is handled similarly with the rounding done
using the algorithim in appendix~\ref{rounding-algorithim}.

The {\tt TFM} format is described in
appendix~\ref{tfm-format}.

\subsubsection{Range of movement}

The driver should be able to handle movements in the {\tt DVI}
file up to a total of $2^{31}$ {\tt DVI} units in any direction
from the  origin.

\subsubsection{Objects off of the page}

Any printable object which would lie entirely off the physical 
page should not be printed but any changes to positioning should
still be taken into consideration. Any printable object which
would lie partially off the physical page should either be
clipped so that portion of the object that lies off the page is
not printed or omitted entirely.

\subsection{Fonts}

\subsubsection{Font numbers}

The driver should be able to accept font numbers (the  parameter
$k$ given by the {\it fnt\_def\/} command) in the range  $0\le
k<256$.

\subsubsection{Distinct {\tt DVI} fonts}

The driver should be able to handle any document containing 64 or fewer
distinct {\tt DVI} fonts.

\subsection{Specials}

The Level~0 Standard requires no support for specials. Specials
not officially defined by the {\tt DVI} driver standards
committee should be flagged with a warning when read from the
{\tt DVI} file. If any specials are ignored by the driver, the
driver must issue a warning message.

\section{Configuration}

It should be possible for the installer of a driver to
configure such things as the location and naming scheme of fonts,
default paper size, etc.\ without having to recompile the driver.

\section{Font files}

\subsection{Font formats}

The driver should be able to read {\tt PK} fonts with the
location specifiable at run time. The {\tt PK}
format is given in appendix~\ref{pk-format}. {\tt GF} support is
optional. The {\tt GF} format is given in
appendix~\ref{gf-format}.

\subsection{The scaling number}

The magnification and resolution of a font are incorporated into
a scaling number of one of two types:
\begin{description}
\item[Magnification number]
The magnification number is given by $5\times {\it resolution}
\times {\it magnification\/}$ where the resolution is given in
dots per inch (on devices with a non-unit aspect ratio, the
horizontal resolution should be used) and a magnification of 1
indicates no magnification. This is an old naming scheme derived
from the old 200~dpi 

\item[Resolution number]
The resolution number is given by ${\it resolution} \times {\it
magnification}$ where both values are as above. This is the
preferred specification for {\tt GF} and {\tt PK} files.
\end{description}

\subsection{Magnifications}

\subsubsection{Minimum set of magnifications}

At the minimum, the driver should be able to load fonts at the
following magnifications of its target resolution: 1.0
(magstep0), 1.095 (magstephalf), 1.2 (magstep1), 1.44 (magstep2),
1.728 (magstep3), 2.074 (magstep4), 2.488 (magstep5), 2.986
(magstep6), 3.583 (magstep7), 4.300 (magstep8), and 5.160
(magstep9). However, driver authors are encouraged to support all
possible magnifications.

\subsubsection{Margin of error}

If a {\tt DVI} file requests a magnification within 2\,\% of a
supported magnification, the driver should use that font without
warning.

\subsection{Missing fonts}

If a font is missing the driver should continue processing and
deal with the missing font in one of three ways:
\begin{enumerate}
\item Insert appropriate white space where the font would
           appear,
\item Insert black rectangles of the size of the font given in
           the {\tt TFM} file,
\item Print the characters from that font at a different size or
           from another font at the same size after issuing a
           warning.
\end{enumerate}
If methods 1 or 2 are used and the driver is unable to locate
size information for the font in question, then the driver may
simply ignore any {\it set\_char\/} or {\it put\_char\/} commands
that occur while the current font is that font.

Under no circumstances should a missing font cause a fatal error.

\appendix

% All appendices ommitted... for this distribution. The complete
% standard can be obtained from ymir.claremont.edu in 
% [anonymous.tex.dvi-standard]
% Mailserv users should send the command
%  SEND [TEX.DVI-STANDARD]00README.TXT
% to find out what files are needed.
%\input{dvi.tex}
%\input{gf.tex}
%\input{pk.tex}
%\input{tfm.tex}
% \input{vf.tex} %Since VF files are not referenced in level 0,
% this is omitted for brevity's sake.
\end{document}

------------------------------

Subject: Specification of algorithim for handling rounding to device units
         (v0.01) -- Request for Comments
From: Don Hosek <DHOSEK%EDU.CLAREMONT.HMCVAX@UK.AC.NSFNET-RELAY>
Date: Sun, 22 Jul 1990 14:37 PDT
Originally-To:  driv-l@bitnet.tamvm1, texhax@edu.washington.cs.june,
                infotex@uk.ac.aston, tex-euro@bitnet.dhdurz1

\documentstyle{article}
\begin{document}
\def\abs{{\rm abs}}
\def\DVI{{\tt DVI}}

\section{Handling rounding to device units---modified {\tt
   DVItype} algorithim}

The algorithims presented here are adapted from {\tt DVItype};
they represent the base algorithim for handling rounding of
co\"ordinates and widths of objects to device units. 

\subsection{Rounding \DVI\ units to device units}

Whenever it is necessary to round some dimension given in \DVI\
units to the corresponding quantity in device units\footnote{For
raster-oriented devices, this would be the distance between spots
in the output. For other devices, this refers to the minimum
addressable distance change, {\em e.g.,\/} on a pen-plotter, it
would be the minimum pen step. Device units do not necessarily
correspond to dot size and this distinction should be respected
in writing a \DVI\ driver.} the conversion should be done as
$\lceil Kn\rceil$ where $n$ is the dimension in \DVI\ units and
$K$ is a constant which converts from \DVI\ units to device
units.\footnote{Devices with non-unit aspect ratios will need to
maintain separate constants for vertical and horizontal
dimensions.} This description will use ${\it pixel\_round}(n)$
to refer to $\lceil Kn\rceil$.

\subsection{Keeping track of the current horizontal and vertical
   position}

The definition of \DVI\ files refers to six registers,
$(h,v,w,x,y,z)$, which hold integer values in \DVI\ units.  In
practice, we also need registers ${\it hh}$ and ${\it vv}$, the
pixel analogs of $h$ and $v$, since it is not always true that
${\it hh}={\it pixel\_round}(h)$ or ${\it vv}={\it
pixel\_round}(v)$.

Whenever the \DVI-reading program encounters an instruction that
changes the current position, it should update $h$ and $v$ using
pure \DVI\ units. If the change in position is due to a {\it
set\_char} command, the driver should add the x-escapement
value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the
new value for $hh$.

For a horizontal movement from any other command, ${\it hh}$
should be set to be ${\it hh}+{\it pixel\_round}(x)$ if
$x<0.2{\it quad}$ for a horizontal movement to the right or if
$x>-0.9{\it quad}$ for a horizontal movement to the left. $\it
quad$ is defined to be the design size of the current font in the
\DVI\ file (after all necessary magnifications have been
applied). If $x$ exceeds the bounds outlined above, ${\it hh}$ is
set to be ${\it pixel\_round}(h+x)$. In this way, rounding
errors are absorbed by interword spaces.

For a vertical movement, ${\it vv}$ is set similarly except that
$\it vv$ is set to ${\it vv}+{\it pixel\_round}(y)$ if $-0.8{\it
quad}<y<0.8{\it quad}$ and set to ${\it pixel\_round}(v+y)$
otherwise. This allows vertical rounding errors to be absorbed in
the interline spacing while still allowing fractions and super-
and subscripts to be printed consistently.

After any horizontal movement, a final check is made as to
whether $\abs(Kh-{\it hh})>{\it max\_drift}$. If it is, then $\it
max\_drift$ is added or subtracted to $hh$ to bring it closer to
$Kh$. A similar check is made with $\it vv$ and $v$. $\it
max\_drift$ should be set to $2$ for output devices with device
units smaller than or equal to $1/200$ inches and $1$ for output
devices with device units with device units greater than $1/200$
inches.
\end{document}

------------------------------

Subject: Notes on:
From: Don Hosek <DHOSEK%EDU.CLAREMONT.HMCVAX@UK.AC.NSFNET-RELAY>
Date: Sun, 22 Jul 1990 14:43 PDT
Originally-To:  driv-l@bitnet.tamvm1, texhax@edu.washington.cs.june,
                infotex@uk.ac.aston, tex-euro@bitnet.dhdurz1

Specification of algorithim for handling rounding to device units (v0.01) --
 Request for Comments

Under separate cover has been sent the outline of the algorithim for 
handling rounding to device units for the Level 0 DVI driver standard. 
It differs from the DVItype algorithim in three significant ways:

(1) the distances where hh and vv are set to pixel_round(h) and 
pixel_round(v) have been changed slightly;

(2) the check for whether maxdrift correction should be applied has been 
modified slightly to give slightly better results in some cases 
(suggestion courtesy John Hobby).

(3) max_drift has been given a more specific value.

Again, comments are requested, please send them to 
dhosek@ymir.claremont.edu

-dh

------------------------------

Subject: mode_def for IBM 4216 printer?
From: Martin Ward <MARTIN@UK.AC.DURHAM.EASBY>
Date: Mon, 23 Jul 90 09:48:32 BST

Does anyone have a Metafont "mode def" for an IBM 4216 020 Personal
Pageprinter (write-white engine)? The only write-white mode def I have is for
a Rioch and it doesn't look right!

		Martin.

My ARPANET address is:  martin%EASBY.DUR.AC.UK@CUNYVM.CUNY.EDU
OR: martin%uk.ac.dur.easby@nfsnet-relay.ac.uk  UUCP:...!mcvax!ukc!easby!martin
JANET: martin@uk.ac.dur.easby    BITNET: IN%"MARTIN@EASBY.DURHAM.AC.UK"

------------------------------

Subject: further funnies in the Archive.
Date: Mon,23 Jul 90 15:06:01 BST
From: R.A.Reese@uk.ac.hull

There is a directory of chapters of a manual on TeX for TROFF users,
[.doc.textroff] and I successfully downloaded and decoded every
chapter except TABLES.TEX_Z . This file looks similar to the others
as received but uncompress doesn't produce anything like an ascii file.

------------------------------

Subject: LaTeX book style
From: Peter King <PJBK@UK.AC.HERIOT-WATT.CS>
Date: Mon, 23 Jul 90 16:52:54 BST

Does anyone know how to make the right hand header correspond to the
last section header on the page rather than the first one.  The problem
only arise if there are more than one section starts on the same page.
My publishers style asks for the last section header as the running
head, whereas LaTeX uses the first.  ( I believe the rationale is that
the header should indicate which section is 'current' when you turn to
the next page. )

-- 
Peter King, Computer Science Department	JANET:	pjbk@uk.ac.hw.cs
  Heriot-Watt University		ARPA:	pjbk@cs.hw.ac.uk
  79 Grassmarket, Edinburgh EH1 2HJ	or	pjbk%cs.hw.ac.uk@ucl-cs
Phone: (+44) 31 225 6465 Ext. 555	UUCP:	..!ukc!cs.hw.ac.uk!pjbk

------------------------------

Subject: TeXserver gains reverse-address sanity
Date: 		Tue, 24 JUL 90 15:40:31 BST
From: Brian {Hamilton Kelly} <TeX@Uk.Ac.Cranfield.RMCS>

     New facilities available at the UK TeX Archive mail server
     ==========================================================
     
One of the  commonest errors made by users of the  Aston University  TeX
archive mail server, <TeXserver@Uk.Ac.Aston.TeX> is to fail to provide a
correct return address in requests.  Very often, users forget to mention
the appropriate gateway  through which  the traffic  should be routed to
depart  from  the  UK.   As seen by  the user,  they aren't  getting the
service required:  from  TeXserver's viewpoint,  the message is sloshing
around somewhere under the computer room floorboards.

To avoid this problem,  and generally make TeXserver more friendly, I've
now   provided   preprocessing,   in   the  code   which  despatches  an
acknowledgement of the request back to the requestor.  This also removes
the requirement  to delimit  the  actual request  by means of  a line of
three hyphens.

Therefore,  you may now mail <TeXserver@Uk.Ac.Aston.TeX>  with a message
which starts  with a valid  TeXserver command (HELP,  DIRECTORY,  FILES,
WHEREIS  or SEARCH);  however,  this MUST be the first non-blank line of
the body  of your message  (TeXserver removes valid RFC-822 headers, but
see PS below).

If you prefer,  you may continue  to use  the old format  for  TeXserver
requests,  wherein  everything  is ignored  before the first line  which
commences with three hyphens: in this format, the following line must be
your return address as seen from  Aston,  and the TeXserver command then
appears on the line after that.

With the new format for requests,  if you wish to use a different return
address for  the information to be mailed back to you  (perhaps avoiding
certain gateways which mangle ASCII during a conversion to/from EBCDIC),
then  you  may  specify  the  return  address  (including  the necessary
gateway)  on the line  preceding the TeXserver command;  prefix any such
alternate address with the directive PATH, followed by a space.

If you  fail to get  any response  from  TeXserver  (neither receipt nor
requested  information)   it   may   be   that  your  address  is  being
misinterpreted by the incoming mailer, CBS_MAILSHR.   DEC are aware of a
bug in this,  in that it  always  upcases  usernames,  so if you're on a
system in which the case of letters in usernames is significant, you may
always  wish to provide a PATH directive,  and thereby get the mail sent
to your true username.

Just to clarify things, assume that A.User@machine.univ.edu wants to get
help from the server:  under the  old scheme  he/she would have sent the
following message (using ============== to delimit this from the rest of
this announcement):

===============================
any number of lines
of rubbish that he/she cared
to put in (although why they bothered,
when there's no human to see, I
wouldn't understand!)

--- Here's the three hyphens, followed by return address
A.User%edu.univ.machine@uk.ac.nsfnet-relay
help
===============================
Note  that the  little-endian address on the Internet has been reordered
to  Janet  big-endian format, which is what  UK gateways expect for mail
from within the UK: they reverse it before remailing  to the appropriate
network.

With the new format, this could reduce to just the command directive:
===============================
help
===============================

But  if  A.User's  machine  doesn't  recognize  A.USER  as  the  correct
individual, then he/she would have to specify:
===============================
path A.User%edu.univ.machine@uk.ac.nsfnet-relay
help
===============================

Any difficulties should be reported to me at the address below: it would
be  useful  if you could  specify what operation you were  attempting to
perform (if possible, send me a copy of your request);  also send copies
of any response received from the TeXserver.

                               Brian {Hamilton Kelly}

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ JANET:     tex@uk.ac.cranfield.rmcs                                     +
+ BITNET:    tex%uk.ac.cranfield.rmcs@ac.uk                               +
+ INTERNET:  tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk                  +
+ UUCP:      ...!mcvax!rmcs.cranfield.ac.uk!tex                           +
+         OR ...!ukc!rmcs.cranfield.ac.uk!tex                             +
+ Smail:     School of Electrical Engineering & Science, Royal Military   +
+            College of Science, Shrivenham, SWINDON SN6 8LA, U.K.        +
+ Phone:     Swindon (0793) 785252 (UK), +44-793-785252 (International)   +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

P.S.  Some users have rogue mailers, which erroneously introduce a blank
line  between  the  various  fields  which   one  assumes  are  meant to
constitute  a single  RFC-822  header.  This is ILLEGAL;  RFC-822 states
that  the  first blank line  terminates  the headers and  introduces the
message  body:  if you fail  to get  ANY  response from  TeXserver,  try
sending yourself a message via some roundabout route and verify that the
headers are contiguous.  If they appear OK to you, please mail me at the 
above address.

------------------------------

Subject: \errorcontextlines setting in LaTeX
From: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX>
Date: Tue, 24 Jul 90 13:59:20 BST

In UKTeX #23, Rainer Sch\"opf and Sebastian Rahtz describe versions
of lplain.tex and splain.tex that can be used with TeX 3.0. These
versions set \errorcontextlines=5 (as plain.tex does). Perhaps this
point ought to be reconsidered. Karl Berry's release notes for Unix
TeX 3.0 say

> (The other new parameter in TeX 3.0 that formats might want to set is
> \errorcontextlines, but leaving it at zero does not seem inappropriate
> for LaTeX.)
{`other' in addition to \lefthyphenmin and \righthyphenmin, that is}

which seemed very plausible to some of us here, especially given
Donald Knuth's original description:

> There's a new integer parameter called \errorcontextlines that
> specifies the maximum number of two-line pairs of context displayed
> with TeX's error messages (in addition to the top and bottom lines,
> which always appear). Plain TeX now sets \errorcontextlines=5, but
> higher level format packages might prefer \errorcontextlines=1 or
> even \errorcontextlines=0.

LaTeX would seem to be just such a `higher level format package'.

Chris Thompson
Cambridge University Computing Service
JANET: cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk

------------------------------

Subject: HP DeskJet driver (dvidjp.c)
From: Ben Bacarisse <B.BACARISSE@UK.AC.UCL.CS>
Date: Tue, 24 Jul 90 13:58:12 +0100

I built the DeskJet varient of Nelson Beebe's dvi familiy on my PC
yesterday.  Unfortunately I have only 640K memory and the driver tries to
allocate a full 8"x11" bitmap at 300 dpi!

The RUMJET driver may overcome this restriction, but as it is "a hack of
Beebe's dvi code" it may be very similar.  Does anyone know?  I am happy to
help out by trying to get it running on my PC.

In the meantime, I have been using Eberhard Mattes' excellent dvidot
driver.  This is designed for dot-matrix printers, but I have written a
parameter file for it and a simple post-processor that does the required
transfromation to raster scan format, as needed by the DeskJet.  This works,
but it requires that the whole document be stored on disc, as a bit image
(3/4 to 1 Mbyte per page) before it can be twiddled and sent to the
printer.  Dvidot can't, it seems, send its output to a pipe.

If anyone wants the configuration file and the bit-twiddling program, I
would be happy to provide them.

Ben.

------------------------------

Subject: Problems with TFM files
From: Mark Manning <MRM1@UK.AC.CAMBRIDGE.PHOENIX>
Date: Wed, 25 Jul 90 10:49:50 BST

     I am currently trying to transfer the Euler fonts from the archive to
our Suns (we do have the Euler fonts from the UNIX distribution tape, but
not at all the magnifications we need).
     I have managed to transfer the PK files successfully (albeit with a
spurious zero byte at the end of each file), but get the message
     Invalid value in command: - filename
     "[tex-archive.fonts.amsfonts.tfm]eufb10.tfm"
     record format incompatible with transfer code.'
when I try to fetch the corresponding TFM files with exactly the same file
transfer parameters.  (We need to get the TFM files as well, because the
archive's PK files have a different checksum from our TFM files.)  I am sure
this is a silly problem which everyone gets, and am sorry to trouble you; but
your help in sorting this out would be much appreciated!
     I'd also be interested to know the date of the Euler fonts on the archive
(to find out whether they are more up-to-date than ours).
     Thanks in advance for your help!
     Mark

------------------------------

Subject: PostScript previewer for VAXstation 3100?
From: Hit-Man <HEARNS@UK.AC.GLASGOW.PHYSICS.V1>
Date: Thu, 26 Jul 90 9:45 BST

Hi, I wonder if any VAX/VMS gurus out there can help?
  
I have recently started using DECwindows on a VAXstation 3100 / VMS 5.3
  
In their publication 'Overview of VMS DEC Windows' DEC mention
briefly a PostScript previewer for DEC windows.
However, this manual is for VMS 5.1, and I cannot find any more
mention of a PostScript previewer.
Has this ever been made available, or has it vanished in VMS 5.3
  
John Hearns , University of Glasgow

------------------------------

Subject: Seeking Questionnaires from the TUG '90 Meeting in TeXas...
Date: Wed, 25 Jul 90 16:10:09 EST
From: CHRISTINA_THIELE%CA.CARLETON@UK.AC.EARN-RELAY

This is a reminder to all those who attended the 1990 TeX Users
Group meeting in College Station, June 18--20. If you haven't
already done so, would you please return your completed
questionnaires to me. I have only received 47 so far, but I'm sure
there are many more still out there -- we had over 150 people in
attendance ;-))
 
Please send your questionnaires to the address below, or e-mail
the answers to me at the address shown above (Subject = TAM
Questionnaire). Or you can even FAX your questionnaire...
 
The more questionnaires I have, the better we can plan next year's
12th Annual Meeting, in Providence, Rhode Island.
 
Many thanks in advance...
 
 
Snail: Christina Thiele        E-mail: Christina_Thiele@carleton.ca
        Journal Production Centre
        DT 1711
        Carleton University     FAX: 613/788-2340
        Ottawa, Ontario
        K1S 5B6  Canada
 
Christina Thiele <Christina_Thiele@CARLETON.CA>

------------------------------

Subject: bibtex
Date: Thu, 26 Jul 90 17:07:38 +0100
Originally-from:N.CHAPMAN@UK.AC.UCL.CS

i've always assumed that bibtex only works with latex, because that's
what the documentation says, but thinking about it i can't see why it
isn't possible to put together some suitable macros that will make it
work with plain.  am i being naive here, or, on the other hand, has
someone else who doesn't like latex already done this?

(i know about, and indeed use, tib, but i sometimes find the refer
database format more restrictive than i'd like so i was interested in
investigating something a bit more sophix.)

------------------------------

Subject: OzTeX hash size increase
Date: Thu, 26 JUL 90 09:36:51 BST
From: VDM@UK.AC.LEICESTER

Does anyone have a version of OzTeX which has been generated
with a hash size of > 5,000?

At Leicester we have three projects which require the use of a large
macro library which we would rather do on Macintoshes than on UNIX?

Please contact


Derek Andrews

ajd@uk.ac.le.vax (JANET)

______________________

Many thanks for your help

Regards

Derek Andrews

------------------------------

Subject: \pmod
Date: Fri, 27 Jul 90 10:26:28
From: PM1MJP@UK.AC.SHEFFIELD.PRIMEA

------------------------------------------------------------------------------
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 Extension 4431.
JANET  MPiff@UK.AC.SHEF.PA  or MPiff@UK.AC.SHEF.IBM
------------------------------------------------------------------------------


On p164 of The TeXBook it states that ``\pmod is to be used when `mod' occurs
parenthetically at the end of a formula.''

Just how literally this is to be taken is shown when it is not  placed  at  the
end  of  a  formula but at the beginning.  To see why this should be necessary,
suppose I wish to say that some values are taken (mod n), and wish the  spacing
to  agree  exactly with what is obtained in \pmod.  Then it would seem perverse
to have to type $({\rm mod}\,\,n)$ to achieve this, and more  natural  to  type
$\pmod n$.

OK, but now see what happens if TeX decides to break the line just before  math
on.  The previous line is not right justified.

Did DEK mean the above quotation  to  be  a  description  of  the  mathematical
circumstances in which \pmod is generally used, or as a warning that it  should
not  be  used  at  the  beginning  of  a  formula?   \pmod  is, of course, safe
mid-formula.

Do any other maths control words in Plain TeX start with \allowbreak?

Is this a bug or an annoying feature?

Mike Piff

-----------------------------------------------------------------------------
!! UK TeX ARCHIVE at ASTON UNIVERSITY:
!!
!!  Files of interest 
!!      [tex-archive]000aston.readme           [tex-archive]000directory.list
!!      [tex-archive]000directory_dates.list   [tex-archive]000directory.size
!!      [tex-archive]000last30days.files
!!
!!  FTP access: site               uk.ac.aston.tex
!!              username           public
!!              password           public
!!
!!
!! I have a tape labelled TeX 2.993(==3.0) LaTeX 2.09 Metafont 1.9 (2.0)
!! Unix 4.2/3BSD & System V. Tar 1600 bpi blocked 20 1 file dated 
!! 28 March 1990 (from washington.edu)
!!
!! 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.
!!  
!! A VMS backup of TeX 2.991 plus PSprint is available; one tape is needed.
!!
!! 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
!!
!! OzTeX - Send 10 UNFORMATTED (800k) disks with return postage.
!!
!! ---Peter Abbott.
!!
!!   end of issue
David Osborne