TeXhax@cs.washington.edu (TeXhax Digest) (08/29/90)
TeXhax Digest Tuesday, August 28, 1990 Volume 90 : Issue 57
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:
Styles for lispcode and grammars wanted...
Customized form letters (how?)
Chicago Manual of Style Bibliography Style?
The Level 0 Draft standard (v 0.03) -- Request for comments
Specification of algorithim for handling rounding to device units
Notes on: Specification of algorithim
-----------------------------------------------------------------------
Date: 10 Jul 90 11:23:52 GMT
From: krey%gmdzi@Princeton.EDU (Juergen Krey)
Subject: Styles for lispcode and grammars wanted...
Keywords: TeX, LaTeX, style, lispcode, grammar
Does anyone have a style or environment-macro for TeX or LaTeX to
format lispcode, with boldfacing defun- and defvar-names, keyword-args,
etc. I found some hints in texinfo.tex, but it's to difficult for me to
adapt parts of it for my low demands.
Moreover i'm looking for a macro-set to pretty-print formal grammars like
(Extended) Backus-Naur Form with LaTeX/TeX.
Thanks for nay help/hints
HjK
------------------------------------------------------------------------------
Date: Thu, 19 Jul 90 18:52:52 EDT
From: csrobe@cs.wm.edu (Chip Roberson)
Subject: Customized form letters (how?)
Keywords: TeX, form letter
Greetings:
I am in the need of producing a lot of nearly identical form
letters but I don't think merge.sty will fit the bill. What I need
to do is be able to insert different words, phrases, sentences, and
maybe even a whole paragraph into each letter depending on to whom it
is addressed. It seems that this should be possible, but I don't
think I'm texpert enough to do it alone and it doesn't appear to be
such a unique situation that it hasn't been done before.
Can anybody help me out?
Many thanks,
-chip
-=- Charles S. Roberson ARPANET: csrobe@cs.wm.edu -=-
-=- VA Remote Sensing Study UUCP: ...!uunet!cs.wm.edu!csrobe -=-
-=- Dept of Comp. Sci. Compu$erve: 71500.2056@compuserve.com -=-
-=- College of William and Mary Ma Bell: (804) 221-3420 [W] -=-
-=- Williamsburg, VA 23185 (804) 229-5530 [H] -=-
Fur: The look that kills.
---------------------------------------------------------------------------
Date: Fri, 20 Jul 90 15:52:47 EDT
From: woo@woonext.dsrd.ornl.gov (John W. Wooten)
Subject: Chicago Manual of Style Bibliography Style?
Keywords: bibliography, Chicago Manual of Style
Has anyone developed a bibligraphy style for LaTeX that follows the Chicago
Manual of Style?
I am beginning to convert my btxbxt.doc to accomplish this, but would
appreciate hearing that it has been done and where I can get the
necessary alpha.bst, etc. files or else a btxbst.doc that has already
been hax'ed to accomplish this.
Thanks,
----------------------------------------------------------------------------
Date: Sat, 21 Jul 1990 20:05 PDT
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: The Level 0 Draft standard (v 0.03) -- Request for comments
Keywords: dviware
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}
------------------------------------------------------------------------
Date: Sun, 22 Jul 1990 14:37 PDT
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Specification of algorithim for handling rounding to device units
(v0.01) -- Request for Comments
Keywords: dviware
\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}
------------------------------------------------------------------------
Date: Sun, 22 Jul 1990 14:43 PDT
From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>
Subject: Notes on: Specification of algorithim for handling rounding to
device units (v0.01) -- Request for Comments
Keywords: dviware
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
-----------------------------------------------------------------------
%%% Further information about the TeXhax Digest, the TeX
%%% Users Group, and the latest software versions is available
%%% in every tenth issue of the TeXhax Digest.
%%%
%%% Concerning subscriptions, address changes, unsubscribing:
%%%
%%% BITNET: send a one-line mail message to LISTSERV@xxx
%%% SUBSCRIBE TEX-L <your name> % to subscribe
%%% or UNSUBSCRIBE TEX-L
%%%
%%% Internet: send a similar one line mail message to
%%% TeXhax-request@cs.washington.edu
%%% JANET users may choose to use
%%% texhax-request@uk.ac.nsf
%%% 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
%%%
%%%\bye
%%%
End of TeXhax Digest
**************************
-------