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 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 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}{\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 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 % 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 ************************** -------