========================================================================= Date: Tue, 2 Oct 90 16:51:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: The standard again Sigh. OK, as most of you realize, we've missed the TUGboat deadline, but the report that I sent off for TUGboat promised that the full report would be available by the time that TUGboat is in people's hands. This gives us a bit more time, but let's try not to waste it. Amendment 8, the change to the maxdrift value passed, but I won't reproduce the text here since I will be incorporating all the passed amendments into the standard text and also doing some rewording to bring us more in line with "standardspeak" and incorporate the beginnings of the rationale portions of the document into the source. This will occupy the bulk of my "copious" spare time during the next few days and I hope to have it available by next Monday. Joachim and Tom have been doing a good job of getting on my case about this. I hope they keep it up, a little guilt never hurts one's motivation ;-). On a related note, I'll be out of town from October 14-28 and I'm unsure about what my e-mail access will be like (I'm going to be teaching a LaTeX class at a military site and they tend to be a little touchy about outsiders using their computers). -dh ========================================================================= Date: Sat, 6 Oct 90 23:21:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: DVI Driver Standard, v 0.04 \documentstyle[ltugboat,fileform,mf]{article} \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} \date{Version 0.04\\Last revised 6~October~1990} \font\tensl=cmsl10 \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... \parindent=10pt % I prefer the traditional 1em parindent. % For file format descriptions: \def\res#1{{\bf #1\/}} \def\sty#1{{\it #1\/}} % Some code to add standard and rationale environments if not already % present: \ifx\rationale\undefined \newenvironment{standard}{\ifvmode\else\par\fi}{} \newenvironment{explicate}{\ifvmode\else\endgraf\fi \leavevmode{\setbox0=\lastbox}\small {\bf Explication:}}{\par} \fi \def\percent{\,\%} \def\DVI{{\tt DVI}} \def\pt{\,pt} \def\KB{\,KB} \def\mm{\,mm} \def\in{\,in} \def\PK{{\tt PK}} \def\abs{\hbox{abs}} \begin{document} \maketitle \begin{abstract} The following represents a minimal standard (level~0) for {\tt DVI} processing programs. The complete standard will be presented as a series of ``tiers'' requiring increasingly stringent control over the output of \DVI\ processors. A trip test for \DVI\ drivers will be created which will allow developers of \DVI\ drivers to insure that their programs meet the standards developed here. The specifications here should be considered a minimum requirement; developers are encouraged to write \DVI\ processors whose capabilities are beyond these specifications. This version of the Level~0 Standard presented here is draft~0.04. It has been presented to the TUG membership at large and is in its final round of revisions. This will form one portion of the TUG \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 \DVI-processing programs should adhere. It provides a base level of support for both \DVI-to-output-device translators and \DVI-to-\DVI\ preprocessors ({\em e.g.,\/} {\tt dviselect}). The basis for many of the specifications in this standard is the possible output of \TeX82\ although some requirements are based on assumptions that cannot occur with \TeX82-based output; functions which can be implemented via a pre-processor are generally omitted ({\em e.g.,\/} page selection and sorting). \section{The \DVI\ file} \begin{standard} As a rule, \DVI\ processors must be able to interpret any {\tt DVI} file which falls within the following limits. If these requirements cannot be met due to limitations of the output device they should be fulfilled as completely as possible and the limitations documented. \label{escape-clause} Aside from this exception, these specifications are a {\em minimum\/}; good processors will probably be able to handle \DVI\ files exceeding these limits ({\tt DVI} files which exceed the limits are likely to be rare, but might still occur). \end{standard} \begin{explicate} Because certain popular output devices have varying capacity depending on the amount of on-board memory or similar conditions. For example, an HP LaserJet Plus with 512\KB\ of memory is capable of holding in memory only 3056 distinct downloaded characters, a full page bitmap is also not possible with this configuration. \end{explicate} \subsection{\DVI\ commands} \begin{standard} The \DVI\ processor must be able to interpret every \DVI\ command listed in Appendix~\ref{dvi-format}. \end{standard} \begin{explicate} Note that some commands, {\em e.g.,\/} \sty{put4} are generally used for conditions outside those enumerated below: despite this, \DVI-translating programs are expected to accurately interpret these commands and execute them if they do specify an action within the specified minimum limits. \end{explicate} \subsection{Characters} \subsubsection{Number of characters in a \DVI\ font} \begin{standard} The \DVI\ processor must be able to handle fonts which have characters at any code in the range $0\le c<256$. \end{standard} \begin{explicate} Some output devices will require \DVI\ fonts with more than a given number of characters to be broken into two or more device fonts when downloaded to the printer. Please note that this requirement is not subject to the exception of Section~\ref{escape-clause}. \end{explicate} \subsubsection{\DVI\ character size} \begin{standard} The \DVI\ processor must be able to render any character up to a size of 600\pt\ (horizontal) by 800\pt\ (vertical) unless this is not possible due to device constraints as outlined in Section~\ref{escape-clause}. \end{standard} \begin{explicate} Note that on many output devices, rendering of very large characters is possible by breaking down such a character into smaller characters or drawing the character in graphics mode. \end{explicate} \subsubsection{Number of \DVI\ characters per page} \begin{standard} The \DVI\ processor must be able to render a page containing as many as 20,000 \DVI\ characters unless this is not possible due to device constraints as outlined in Section~\ref{escape-clause}. \end{standard} \subsubsection{Unusual characters} \begin{standard} The \DVI\ processor must correctly render (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. \end{standard} \subsection {Rules} \subsubsection{Rule size} \begin{standard} The \DVI\ processor must be able to render rules of any size up to 600\pt\ (horizontal) by 800\pt\ (vertical) unless this is not possible due to device constraints as outlined in Section~\ref{escape-clause}. \end{standard} \subsubsection{Placement of rules on the page} \begin{standard} The lower left corner of a rule is to be placed on the page at the location given by rounding the current \DVI\ co\"ordinates as indicated in Section~\ref{rounding-algorithim}. The height and width of the rule should be given by the formula $\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.} \end{standard} \subsection{Number of rules per page} \begin{standard} The \DVI\ processor must be able to render a page containing as many as 1000~rules unless this is not possible due to device constraints as outlined in Section~\ref{escape-clause}. \end{standard} \subsection{Stack} \begin{standard} The \DVI\ processor must be able to handle \DVI\ files whose {\it push\/}\slash{\it pop\/} stack is up to 100 levels deep. \end{standard} \subsection{Positioning on the page} \subsubsection{Location of the origin} \begin{standard} The point $(0,0)$ in \DVI\ co\"{o}rdinates is to be located at a point one inch (2.54\mm) from the top of the page and one inch (2.54\mm) from the left side of the page. \end{standard} \begin{explicate} While the default margin given in this circumstance is somewhat inconvenient for users of non-U.S.-sized paper, the advantage of having a universally standard default location of $(0,0)$ and the widespread assumption of the given default margin in most macro packages outweighs the inconveniences. Note that for some \DVI\ processors, this specification \end{explicate} \subsubsection{Changes in position due to characters and rules} \label{rounding-algorithim} \begin{standard} 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 round}(h)$ or ${\it vv}={\it 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 round}(x)$ if $x < {\it word\_space}$ for a horizontal movement to the right or if $x > -{\it back\_space}$ for a horizontal movement to the left. {\it word\_space\/} is defined as $\it space - space_shrink$, and {\it back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design size of the current font in the {\tt DVI} file (after all necessary magnifications have been applied) may be used for a {\it quad}, and {\it word\_space\/} may be approximated by $\it 0.2 quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is set to be ${\it 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 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 0.005\in\ (0.127\mm), $1$~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and $0$~for output devices with device units greater than 0.01\in\ (0.254\mm). inches. \end{standard} \subsubsection{Range of movement} \begin{standard} The processor should be able to handle movements in the {\tt DVI} file up to a total of $2^{31}$ \DVI\ units in any direction from the origin. \end{standard} \subsubsection{Objects off of the page} \begin{standard} Any printable object which would lie entirely off the physical page should not be rendered 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. \end{standard} \begin{explicate} Because some output devices do unpredictable things when objects are rendered partially or completely off the edge of the page, it is up to the \DVI-processor writer to make sure that objects printed partially off the page are handled correctly. \end{explicate} \subsection{Fonts} \subsubsection{Font numbers} \begin{standard} The processor must be able to accept font numbers (the parameter $k$ given by the {\it fnt\_def\/} command) in the range $0\le k<256$. \end{standard} \subsubsection{Distinct \DVI\ fonts} \begin{standard} The processor must be able to handle any document containing 64 or fewer distinct \DVI\ fonts. \end{standard} \subsection{Specials} \begin{standard} The Level~0 Standard requires no support for specials. Specials not officially defined by the \DVI\ processor standards committee should be flagged with a warning when read from the \DVI\ file. If any specials are ignored by the processor, the processor must issue a warning message. These warning messages may optionally be turned off at run time. \end{standard} \section{Configuration} \begin{standard} It must be possible for the installer of a processor to configure such things as the location and naming scheme of fonts, default paper size, etc.\ without having to recompile the processor. \end{standard} \section{Font files} \subsection{Font formats} \begin{standard} The processor must 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}. \end{standard} \begin{explicate} The \PK\ format is the preferred format for bitmap fonts because (a)~it is the most compact format in the \TeX\ world and (b)~included in the \PK\ format are pieces of information about the font ({\em e.g.,\/} the horizontal escapement in pixels for each character) which are essential for fulfilling the typesetting requirements of Section~\ref{rounding-algorithim}. \end{explicate} \subsection{The scaling number} \begin{standard} 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} \end{standard} \subsection{Magnifications} \subsubsection{Minimum set of magnifications} \begin{standard} At the minimum, the processor must 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, \DVI\ processor authors are encouraged to support all possible magnifications. \end{standard} \subsubsection{Margin of error} \begin{standard} If a \DVI\ file requests a font at a size that does not exist, but the requested size is within 0.2\percent of a supported magnification with the font at that size existing, the processor shall use the latter font without warning. \end{standard} \begin{explicate} \TeX\ and \MF\ compute font magnifications with different precisions. Further, caluclations done by \TeX\ and/or a \DVI\ processor are subject to roundoff errors. The margin prescribed is sufficient for accomodating these errors. It is {\em not\/} intended to compensate for fonts requested at an incorrect size. \end{explicate} \subsection{Missing fonts} \begin{standard} If a font is missing the processor must 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 processor is unable to locate size information for the font in question, then the processor 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. \end{standard} \end{document} \appendix \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: Sat, 6 Oct 90 23:37:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Miscellanea I've just sent version 0.04 of the driver standard to the list; it consists of 0,03 with some minor re-writes in places to accomodate the new structure (I decided to use the term explication rather than rationale to describe the explanatory passages since the contents include suggestions for dealing with output devices, as well as explanations of why things are the way they are). There are not explications for every section that should have them; those will have to be dealt with by amendment since I wanted to make sure Joachim would have something for the DAnTe meeting (He did ask nicely. Several times). The text also includes the changes dictated by amendments 1,5,6,7 and 8 as well as some re-wording to address some general concerns (e.g., must for should render for print) that were presented in the mail that I've received. The other substantial change is the rounding algorithim appendix has been moved into the main standard text and the error where I said pixel_round where I should have said round has been fixed. I have a note from John Gourlay proposing a couple of amendments which I have yet to act on. There are also numerous suggestions in Arthur Ogawa's letter of 6-September that should be examined. (Incidentally, Art, non-voting members can submit amendments, but they need the second of a voting member). I've put all relevant files up for remote access on ymir.claremont.edu; FTP users should go to the directory [anonymous.tex.dvi-standard], those without FTP access can get files from mailserv@ymir.claremont.edu by requesting files from the directory [tex.dvi-standard]. The first one you'll want to get is the file 00files.txt which has a list of the files in that directory. The mailserv command to get files is SEND, e.g., SEND [tex.dvi-standard]00files.txt Finally one more modification to the amendment procedure. Amendments should be sent to the list first. They cannot be deemed official any sooner than 10 days after their first appearance on the list. This will give members some opportunity to discuss resolutions and propose modifications before we begin the voting cycle on each amendment. And finally + 1, just a reminder that I will be gone October 14-28 and will most likely not be able to deal with mail during that time. -dh ========================================================================= Date: Sat, 6 Oct 90 23:38:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: Two amendment proposals Date: Wed, 29 Aug 90 15:24:34 EDT From: jsg@arbortext.com Subject: Two amendment proposals Proposals 6 and 7 raise a couple of questions in my mind. One is how the character placement algorithm will apply to commercial drivers whose source code is not available for inspection. The second is how drivers that satisfy higher tiers of the standard in terms of better character placement will also satisfy the lowest level. To clarify these issues I'd like to propose an ammendment to the effect that drivers should follow the character and rule placement algorithm given or they should produce printed results equivalent to such a driver on a standard set of test documents prescribed by the committee (the driver ``trip'' test that has been brought up now and then). This functional definition of positioning can resolve the tier problem if each of the tier specifications includes a larger set of test documents that require increasingly elaborate character positioning. Because the standard is in a state of flux, I'm not sure how to phrase this in the formal fashion of the other amendments. I'll trust you to do this. John Gourlay ========================================================================= Date: Wed, 17 Oct 90 17:51:54 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: minor errors in draft 0.04 Hello, I got a look on the draft 0.04, there are still some minor errors, typos, etc. The correction requires no ammendment, as there are no changes on the content. Below follows a context-diff to a revised document which covers the things detected by me. It may be used directly with patch; for those poor souls without patch: this (revised) text is available as DVISTD.TEX in the DRIVER filelist at the Listserver in Heidelberg (LISTSERV@DHDURZ1.Bitnet). IMPORTANT ERROR: There are two places were pieces of sentences are missing. Look for + $$\fbox{here is something missing}$$ TOPICS OF MINOR CHANGES: 1. Update of version number (0.04.1) and date (17 Oct 90) The version number should go back to 0.04, it's just for remembering that there are changes. 2. Some typos are corrected. (missing braces, `caluclations', \it in wrong place, etc.) 3. The baselineskip between the first line of the explicate and the last line of the standard environment should be the same as in the standard environment. A short-cut is a small vertical skip. 4. `abs' should be set as a \mathop. (Compare with the definition of \log in Plain.) 5. `round' the same. If abs() is set in Roman type then round() should be typeset in Roman, too. I have introduced a macro \round so that both definitions may be changed easily. 6. The term `x-escapement' does not exist. It's `horizontal escapement'. 7. $hh$ and $\it hh$ is different. If you look at the last line of the second paragraph of 2.6.2 you will see the difference between Text Italic and Math Italic. TOPICS WHICH I WAS NOT SURE ABOUT: 1. Shall abs() and round() really be typeset in Roman? 2. Should `quad' not be typeset in Roman? It's a dimension like `mm' etc. 3. (1) coordinates or (2) co\"ordinates? My dictionaries tell me (1) ... --- Greetings, Joachim *** dvistd4.tex Wed Oct 10 02:40:42 1990 --- dvistd4a.tex Wed Oct 17 16:36:08 1990 *************** *** 3,9 **** \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} ! \date{Version 0.04\\Last revised 6~October~1990} \font\tensl=cmsl10 --- 3,9 ---- \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} ! \date{Version 0.04.1\\Last revised 17~October~1990} \font\tensl=cmsl10 *************** *** 22,28 **** \ifx\rationale\undefined \newenvironment{standard}{\ifvmode\else\par\fi}{} \newenvironment{explicate}{\ifvmode\else\endgraf\fi ! \leavevmode{\setbox0=\lastbox}\small {\bf Explication:}}{\par} \fi --- 22,29 ---- \ifx\rationale\undefined \newenvironment{standard}{\ifvmode\else\par\fi}{} \newenvironment{explicate}{\ifvmode\else\endgraf\fi ! \vskip 1pt ! \noindent\small {\bf Explication:}}{\par} \fi *************** *** 33,39 **** \def\mm{\,mm} \def\in{\,in} \def\PK{{\tt PK}} ! \def\abs{\hbox{abs}} \begin{document} \maketitle --- 34,41 ---- \def\mm{\,mm} \def\in{\,in} \def\PK{{\tt PK}} ! \def\abs{\mathop{\rm abs}} ! \def\round{\mathop{\rm round}} \begin{document} \maketitle *************** *** 215,220 **** --- 217,223 ---- widespread assumption of the given default margin in most macro packages outweighs the inconveniences. Note that for some \DVI\ processors, this specification + $$\fbox{here is something missing}$$ \end{explicate} \subsubsection{Changes in position due to characters and rules} *************** *** 226,258 **** $(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 round}(h)$ or ${\it vv}={\it ! 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 round}(x)$ if $x < {\it word\_space}$ for a horizontal movement to the right or if $x > -{\it back\_space}$ for a horizontal movement to the left. {\it ! word\_space\/} is defined as $\it space - space_shrink$, and {\it ! back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design size of the current font in the {\tt DVI} file (after all necessary magnifications have been applied) may be used for a {\it quad}, and ! {\it word\_space\/} may be approximated by $\it 0.2 quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is ! set to be ${\it 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 round}(y)$ if $-0.8{\it ! quad} -{\it back\_space}$ for a horizontal movement to the left. {\it ! word\_space\/} is defined as $\it space - space\_shrink$, and {\it ! back\_space\/} is defined as $0.9 \it quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design size of the current font in the {\tt DVI} file (after all necessary magnifications have been applied) may be used for a {\it quad}, and ! {\it word\_space\/} may be approximated by $0.2 \it quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is ! set to be $\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}+\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 0.005\in\ (0.127\mm), $1$~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and ! $0$~for output devices with device units greater than 0.01\in\ (0.254\mm). - inches. \end{standard} \subsubsection{Range of movement} --- 261,274 ---- 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 $\it 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 0.005\in\ (0.127\mm), 1~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and ! 0~for output devices with device units greater than 0.01\in\ (0.254\mm). \end{standard} \subsubsection{Range of movement} *************** *** 274,280 **** \begin{standard} The processor should be able to handle movements in the {\tt DVI} ! file up to a total of $2^{31}$ \DVI\ units in any direction from the origin. \end{standard} --- 275,281 ---- \begin{standard} The processor should be able to handle movements in the {\tt DVI} ! file up to a total of $2^{31}$~\DVI\ units in any direction from the origin. \end{standard} *************** *** 366,371 **** --- 367,373 ---- 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 + $$\fbox{here is something missing}$$ \item[Resolution number] The resolution number is given by ${\it resolution} \times {\it *************** *** 392,404 **** \begin{standard} If a \DVI\ file requests a font at a size that does not ! exist, but the requested size is within 0.2\percent of a supported magnification with the font at that size existing, the processor shall use the latter font without warning. \end{standard} \begin{explicate} \TeX\ and \MF\ compute font magnifications with different ! precisions. Further, caluclations done by \TeX\ and/or a \DVI\ processor are subject to roundoff errors. The margin prescribed is sufficient for accomodating these errors. It is {\em not\/} --- 394,406 ---- \begin{standard} If a \DVI\ file requests a font at a size that does not ! exist, but the requested size is within 0.2\percent{} of a supported magnification with the font at that size existing, the processor shall use the latter font without warning. \end{standard} \begin{explicate} \TeX\ and \MF\ compute font magnifications with different ! precisions. Further, calculations done by \TeX\ and/or a \DVI\ processor are subject to roundoff errors. The margin prescribed is sufficient for accomodating these errors. It is {\em not\/} --- end of mail ========================================================================= Date: Wed, 17 Oct 90 17:51:54 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: minor errors in draft 0.04 Hello, I got a look on the draft 0.04, there are still some minor errors, typos, etc. The correction requires no ammendment, as there are no changes on the content. Below follows a context-diff to a revised document which covers the things detected by me. It may be used directly with patch; for those poor souls without patch: this (revised) text is available as DVISTD.TEX in the DRIVER filelist at the Listserver in Heidelberg (LISTSERV@DHDURZ1.Bitnet). IMPORTANT ERROR: There are two places were pieces of sentences are missing. Look for + $$\fbox{here is something missing}$$ TOPICS OF MINOR CHANGES: 1. Update of version number (0.04.1) and date (17 Oct 90) The version number should go back to 0.04, it's just for remembering that there are changes. 2. Some typos are corrected. (missing braces, `caluclations', \it in wrong place, etc.) 3. The baselineskip between the first line of the explicate and the last line of the standard environment should be the same as in the standard environment. A short-cut is a small vertical skip. 4. `abs' should be set as a \mathop. (Compare with the definition of \log in Plain.) 5. `round' the same. If abs() is set in Roman type then round() should be typeset in Roman, too. I have introduced a macro \round so that both definitions may be changed easily. 6. The term `x-escapement' does not exist. It's `horizontal escapement'. 7. $hh$ and $\it hh$ is different. If you look at the last line of the second paragraph of 2.6.2 you will see the difference between Text Italic and Math Italic. TOPICS WHICH I WAS NOT SURE ABOUT: 1. Shall abs() and round() really be typeset in Roman? 2. Should `quad' not be typeset in Roman? It's a dimension like `mm' etc. 3. (1) coordinates or (2) co\"ordinates? My dictionaries tell me (1) ... --- Greetings, Joachim *** dvistd4.tex Wed Oct 10 02:40:42 1990 --- dvistd4a.tex Wed Oct 17 16:36:08 1990 *************** *** 3,9 **** \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} ! \date{Version 0.04\\Last revised 6~October~1990} \font\tensl=cmsl10 --- 3,9 ---- \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} ! \date{Version 0.04.1\\Last revised 17~October~1990} \font\tensl=cmsl10 *************** *** 22,28 **** \ifx\rationale\undefined \newenvironment{standard}{\ifvmode\else\par\fi}{} \newenvironment{explicate}{\ifvmode\else\endgraf\fi ! \leavevmode{\setbox0=\lastbox}\small {\bf Explication:}}{\par} \fi --- 22,29 ---- \ifx\rationale\undefined \newenvironment{standard}{\ifvmode\else\par\fi}{} \newenvironment{explicate}{\ifvmode\else\endgraf\fi ! \vskip 1pt ! \noindent\small {\bf Explication:}}{\par} \fi *************** *** 33,39 **** \def\mm{\,mm} \def\in{\,in} \def\PK{{\tt PK}} ! \def\abs{\hbox{abs}} \begin{document} \maketitle --- 34,41 ---- \def\mm{\,mm} \def\in{\,in} \def\PK{{\tt PK}} ! \def\abs{\mathop{\rm abs}} ! \def\round{\mathop{\rm round}} \begin{document} \maketitle *************** *** 215,220 **** --- 217,223 ---- widespread assumption of the given default margin in most macro packages outweighs the inconveniences. Note that for some \DVI\ processors, this specification + $$\fbox{here is something missing}$$ \end{explicate} \subsubsection{Changes in position due to characters and rules} *************** *** 226,258 **** $(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 round}(h)$ or ${\it vv}={\it ! 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 round}(x)$ if $x < {\it word\_space}$ for a horizontal movement to the right or if $x > -{\it back\_space}$ for a horizontal movement to the left. {\it ! word\_space\/} is defined as $\it space - space_shrink$, and {\it ! back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design size of the current font in the {\tt DVI} file (after all necessary magnifications have been applied) may be used for a {\it quad}, and ! {\it word\_space\/} may be approximated by $\it 0.2 quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is ! set to be ${\it 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 round}(y)$ if $-0.8{\it ! quad} -{\it back\_space}$ for a horizontal movement to the left. {\it ! word\_space\/} is defined as $\it space - space\_shrink$, and {\it ! back\_space\/} is defined as $0.9 \it quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design size of the current font in the {\tt DVI} file (after all necessary magnifications have been applied) may be used for a {\it quad}, and ! {\it word\_space\/} may be approximated by $0.2 \it quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is ! set to be $\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}+\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 0.005\in\ (0.127\mm), $1$~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and ! $0$~for output devices with device units greater than 0.01\in\ (0.254\mm). - inches. \end{standard} \subsubsection{Range of movement} --- 261,274 ---- 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 $\it 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 0.005\in\ (0.127\mm), 1~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and ! 0~for output devices with device units greater than 0.01\in\ (0.254\mm). \end{standard} \subsubsection{Range of movement} *************** *** 274,280 **** \begin{standard} The processor should be able to handle movements in the {\tt DVI} ! file up to a total of $2^{31}$ \DVI\ units in any direction from the origin. \end{standard} --- 275,281 ---- \begin{standard} The processor should be able to handle movements in the {\tt DVI} ! file up to a total of $2^{31}$~\DVI\ units in any direction from the origin. \end{standard} *************** *** 366,371 **** --- 367,373 ---- 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 + $$\fbox{here is something missing}$$ \item[Resolution number] The resolution number is given by ${\it resolution} \times {\it *************** *** 392,404 **** \begin{standard} If a \DVI\ file requests a font at a size that does not ! exist, but the requested size is within 0.2\percent of a supported magnification with the font at that size existing, the processor shall use the latter font without warning. \end{standard} \begin{explicate} \TeX\ and \MF\ compute font magnifications with different ! precisions. Further, caluclations done by \TeX\ and/or a \DVI\ processor are subject to roundoff errors. The margin prescribed is sufficient for accomodating these errors. It is {\em not\/} --- 394,406 ---- \begin{standard} If a \DVI\ file requests a font at a size that does not ! exist, but the requested size is within 0.2\percent{} of a supported magnification with the font at that size existing, the processor shall use the latter font without warning. \end{standard} \begin{explicate} \TeX\ and \MF\ compute font magnifications with different ! precisions. Further, calculations done by \TeX\ and/or a \DVI\ processor are subject to roundoff errors. The margin prescribed is sufficient for accomodating these errors. It is {\em not\/} --- end of mail ========================================================================= Date: Wed, 17 Oct 90 18:30:48 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: draft 0.04 (again) Correction to my previous mail: The revised text is available as DVISTD0.TEX from Heidelberg. I.e., send a mail with the line GET DVISTD0 TEX DRIVER to LISTSERV@DHDURZ1.Bitnet Joachim ========================================================================= Date: Wed, 17 Oct 90 17:51:54 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: minor errors in draft 0.04 Hello, I got a look on the draft 0.04, there are still some minor errors, typos, etc. The correction requires no ammendment, as there are no changes on the content. Below follows a context-diff to a revised document which covers the things detected by me. It may be used directly with patch; for those poor souls without patch: this (revised) text is available as DVISTD.TEX in the DRIVER filelist at the Listserver in Heidelberg (LISTSERV@DHDURZ1.Bitnet). IMPORTANT ERROR: There are two places were pieces of sentences are missing. Look for + $$\fbox{here is something missing}$$ TOPICS OF MINOR CHANGES: 1. Update of version number (0.04.1) and date (17 Oct 90) The version number should go back to 0.04, it's just for remembering that there are changes. 2. Some typos are corrected. (missing braces, `caluclations', \it in wrong place, etc.) 3. The baselineskip between the first line of the explicate and the last line of the standard environment should be the same as in the standard environment. A short-cut is a small vertical skip. 4. `abs' should be set as a \mathop. (Compare with the definition of \log in Plain.) 5. `round' the same. If abs() is set in Roman type then round() should be typeset in Roman, too. I have introduced a macro \round so that both definitions may be changed easily. 6. The term `x-escapement' does not exist. It's `horizontal escapement'. 7. $hh$ and $\it hh$ is different. If you look at the last line of the second paragraph of 2.6.2 you will see the difference between Text Italic and Math Italic. TOPICS WHICH I WAS NOT SURE ABOUT: 1. Shall abs() and round() really be typeset in Roman? 2. Should `quad' not be typeset in Roman? It's a dimension like `mm' etc. 3. (1) coordinates or (2) co\"ordinates? My dictionaries tell me (1) ... --- Greetings, Joachim *** dvistd4.tex Wed Oct 10 02:40:42 1990 --- dvistd4a.tex Wed Oct 17 16:36:08 1990 *************** *** 3,9 **** \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} ! \date{Version 0.04\\Last revised 6~October~1990} \font\tensl=cmsl10 --- 3,9 ---- \title{The ``Level~0'' \DVI\ Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG \DVI\ Driver Standards Committee}} ! \date{Version 0.04.1\\Last revised 17~October~1990} \font\tensl=cmsl10 *************** *** 22,28 **** \ifx\rationale\undefined \newenvironment{standard}{\ifvmode\else\par\fi}{} \newenvironment{explicate}{\ifvmode\else\endgraf\fi ! \leavevmode{\setbox0=\lastbox}\small {\bf Explication:}}{\par} \fi --- 22,29 ---- \ifx\rationale\undefined \newenvironment{standard}{\ifvmode\else\par\fi}{} \newenvironment{explicate}{\ifvmode\else\endgraf\fi ! \vskip 1pt ! \noindent\small {\bf Explication:}}{\par} \fi *************** *** 33,39 **** \def\mm{\,mm} \def\in{\,in} \def\PK{{\tt PK}} ! \def\abs{\hbox{abs}} \begin{document} \maketitle --- 34,41 ---- \def\mm{\,mm} \def\in{\,in} \def\PK{{\tt PK}} ! \def\abs{\mathop{\rm abs}} ! \def\round{\mathop{\rm round}} \begin{document} \maketitle *************** *** 215,220 **** --- 217,223 ---- widespread assumption of the given default margin in most macro packages outweighs the inconveniences. Note that for some \DVI\ processors, this specification + $$\fbox{here is something missing}$$ \end{explicate} \subsubsection{Changes in position due to characters and rules} *************** *** 226,258 **** $(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 round}(h)$ or ${\it vv}={\it ! 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 round}(x)$ if $x < {\it word\_space}$ for a horizontal movement to the right or if $x > -{\it back\_space}$ for a horizontal movement to the left. {\it ! word\_space\/} is defined as $\it space - space_shrink$, and {\it ! back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design size of the current font in the {\tt DVI} file (after all necessary magnifications have been applied) may be used for a {\it quad}, and ! {\it word\_space\/} may be approximated by $\it 0.2 quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is ! set to be ${\it 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 round}(y)$ if $-0.8{\it ! quad} -{\it back\_space}$ for a horizontal movement to the left. {\it ! word\_space\/} is defined as $\it space - space\_shrink$, and {\it ! back\_space\/} is defined as $0.9 \it quad$ if the driver uses {\tt TFM} files. If the driver does not use {\tt TFM} files the design size of the current font in the {\tt DVI} file (after all necessary magnifications have been applied) may be used for a {\it quad}, and ! {\it word\_space\/} may be approximated by $0.2 \it quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is ! set to be $\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}+\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 0.005\in\ (0.127\mm), $1$~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and ! $0$~for output devices with device units greater than 0.01\in\ (0.254\mm). - inches. \end{standard} \subsubsection{Range of movement} --- 261,274 ---- 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 $\it 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 0.005\in\ (0.127\mm), 1~for output devices with device units greater than 0.005\in\ (0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and ! 0~for output devices with device units greater than 0.01\in\ (0.254\mm). \end{standard} \subsubsection{Range of movement} *************** *** 274,280 **** \begin{standard} The processor should be able to handle movements in the {\tt DVI} ! file up to a total of $2^{31}$ \DVI\ units in any direction from the origin. \end{standard} --- 275,281 ---- \begin{standard} The processor should be able to handle movements in the {\tt DVI} ! file up to a total of $2^{31}$~\DVI\ units in any direction from the origin. \end{standard} *************** *** 366,371 **** --- 367,373 ---- 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 + $$\fbox{here is something missing}$$ \item[Resolution number] The resolution number is given by ${\it resolution} \times {\it *************** *** 392,404 **** \begin{standard} If a \DVI\ file requests a font at a size that does not ! exist, but the requested size is within 0.2\percent of a supported magnification with the font at that size existing, the processor shall use the latter font without warning. \end{standard} \begin{explicate} \TeX\ and \MF\ compute font magnifications with different ! precisions. Further, caluclations done by \TeX\ and/or a \DVI\ processor are subject to roundoff errors. The margin prescribed is sufficient for accomodating these errors. It is {\em not\/} --- 394,406 ---- \begin{standard} If a \DVI\ file requests a font at a size that does not ! exist, but the requested size is within 0.2\percent{} of a supported magnification with the font at that size existing, the processor shall use the latter font without warning. \end{standard} \begin{explicate} \TeX\ and \MF\ compute font magnifications with different ! precisions. Further, calculations done by \TeX\ and/or a \DVI\ processor are subject to roundoff errors. The margin prescribed is sufficient for accomodating these errors. It is {\em not\/} --- end of mail ========================================================================= Date: Mon, 22 Oct 90 08:51:08 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Teresa A. Ehling" Subject: Letter re: ›special 22 October 1990 TO: Nelson Beebe Robert McGaffey Don Hosek and the Members of the DVI Driver Standards Committee Barbara Beeton/TUGboat TeXHAX We are writing to ask you, the members of the DVI Driver Standards Committee, to give your thoughtful and immediate attention to the still unresolved issue of a usage standard for ›special. The committee has made great strides in establishing standards for DVI processing programs and we applaud your efforts--the publication of a draft standard is a major milestone that will help guide the work of implementers. We hope that you will agree with us that a draft standard should soon be published that standardizes the use of ›special. We strongly recommend that a definite and unequivocal convention be established for writing ›special commands for simple figure inclusion (this with the understanding that the definition of ›special may be left open-ended for future extensions). Certainly it would be hard to anticipate all the possible uses for this powerful extension of the TeX language, and it is conceivable that it will take many years before the community is in full agreement on the details of just how such extensions are to be implemented. But, inspite of the obvious difficulty in achieving consensus in the near term, we believe that definitve action on this particular standard is needed now. Publishers, particularly those active in technical areas, are rapidly moving towards the use of author-supplied, machine- readable material, for both journal and book production. In mathematical and scientific areas, text material is often best communicated in the form of DVI files. Figures to be inserted are most commonly provided in Encapsulated PostScript (EPSF) form. A major stumbling block to completion of the transition to seamless electronic publishing is that every DVI processing program supports a different usage convention for the ›special command. This means that every book or journal project must be customized: instead of a smooth operation involving only the transfer of the authors DVI and EPS files, serious programming effort is often required to deal with the myriad variations in the ›special syntactical rules. Realistically, all that the author requires is a way of inserting an EPS-defined figure at a given place in the TeX document. Our experience with a large number of author-supplied DVI files indicates that the predominant use of ›special is for simple figure insertion. In a small number of cases, the figure also needs to be scaled. We have yet to encounter a case where a figure needs to be shifted, rotated, skewed, or clipped. More importantly, no use is ever made of the ability to insert verbatim PostScript commands, to call on PostScript functions native to a particular DVI processing program, or to produce overlays. While these transformations represent interesting and powerful extensions, they apparently are not vital to the production of even the most sophisticated texts. When the discussion of standards for DVI drivers first began, there was little urgency, since the routine need for these capabilities had not yet become apparent outside a small number of research laboratories. Progress in the field has been rapid, however, outpacing the deliberations of the standards committee, as journals rapidly switch to machine-readable formats. Similarly, books are now routinely produced from TeX output. It seems clear: now is the time for publication of a simple, efficient standard for figure insertion in papers and books. We assert that: * A standard for use of ›special in DVI files is urgently needed now by both authors and publishers. * Most user requirements can be met by a very simple scheme. * Hooks can be left for more sophisticated usage of ›special to be defined later, but debate over these extensions should not delay announcement of a standard for simple figure insertion. * Dependence on internal details of a particular DVI processing program, or the PostScript prolog it uses, is awkward and debilitating. * Exactly what standard is adopted is not as important as that some standard be adopted soon. * If a standard cannot be soon agreed upon, it is imperative that at least a working draft be circulated that can be used as a model by implementers. * In the absence of guidance from the TUG DVI driver standards committee, ad hoc, de facto "standards" are emerging because the need for a standard is pressing. These "standards" are neither extensible nor elegant. The members of the committee can perform an invaluable service to the community by swiftly moving ahead with the publication of a draft standard for the use of ›special for simple figure inclusion. The window of opportunity for influencing current and future developments in this area is open now, and we look foward to your bringing the long standing debate to closure. Sincerely, Teresa A. Ehling Acquisition Editor Computer Science and Engineering The MIT Press Cambridge, Massachusetts Berthold K.P. Horn (technical advisor) Professor MIT Artificial Intelligence Laboratory Cambridge, Massachusetts REFERENCES: Hosek, D. (1990) ``The `Level 0' DVI Driver Standard,'' Version 0.04, revised 1990 Oct 6. Reid, T. & D. Hosek (1990) ``Report from the DVI Driver Standards Committee,'' McGaffey, R.W. (1987) ``Developing TeX DVI driver standards,'' In TUG VIII Conference Proceedings, pp. 69--70. TUG User Group. Hosek, D. (1987) ``Proposed DVI \special command standard,'' Guntermann, K. & J. Schrod (1988) ``High Quality DVI drivers,'' Hosek, D (1987) ``Call for standardization of DVI specials,'' TeXMAG, Vol. 1, No. 5. Beebe, N.H.F. (1987) ``A TeX DVI driver family,'' In TUG VIII Conference Proceedings, pp. 71--113. TUG User Group. Beebe, N.H.F. (1989) ``DVIxxx - Display TeX DVI Files on Assorted Output Devices,'' Beebe, N.H.F. (1989) ``TeX DVI Driver Family Status,'' Second Edition. Bechtolsheim, S. v. (1989) ``A .dvi File Processing Program,'' TUGBoat, Vol. 10, No. 3. Roylance, G. (1987) ``Merging Illustrations and Printing on Big Paper,'' Working Paper 299A, MIT AI Laboratory. Spivak, M. (1987) ``PTI Laser/PS Manual,'' Personal TEX Inc. Anonymous (1988) ``DVILASER/PS User Manual,'' ArborText Inc. Anonymous ``DVI2PS - convert a DVI file to PostScript,'' Unix Programmer's Manual. ========================================================================= Date: Mon, 22 Oct 90 09:03:58 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: Letter re: \special for simple graphics inclusions In-Reply-To: "Teresa A. Ehling"'s message of Mon, 22 Oct 90 08:51:08 EDT <9010221310.AA08724@june.cs.washington.edu> How about simply adopting the PSfig conventions? PSfig seems to be the most popular game around at present. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.acs.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thompson Hall, Mail Stop DR05 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 ========================================================================= Date: Mon, 22 Oct 90 09:40:31 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: Letter re: ›special In-Reply-To: "Teresa A. Ehling"'s message of Mon, 22 Oct 90 08:51:08 EDT <9010221308.AA20798@Sunburn.Stanford.EDU> I've got a paper on specials that I've been writing for the past four or five months that I'd better get into shape and submit to this list. Stay tuned . . . -tom ========================================================================= Date: Mon, 22 Oct 90 11:59:31 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Bart Childs Subject: Specials Regardless, I think that we can and should make the TeX file device independent. The primary machines are the moment are PS and HP, but will they last forever? Bart ========================================================================= Date: Mon, 22 Oct 90 19:21:56 BST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: Short comment on call for quick \special{} standardization The DVI driver standards committee decided with good reason to delay standardization of the \special{} command; it truly is a bag of worms, and almost every driver has implemented it differently. I FEEL VERY STRONGLY that the syntax of the \special should be defined by a rigorous, extensible, grammar, and have previously offered to the committee members a description of the scheme I have implemented in my 3.0 DVI driver development. I will not repeat it here, but will merely observe that neither PSfig, nor any other driver \special{} I've seen so far, offers the power, or the generality, or the extensibility, of my proposal, and I would therefore strongly oppose standardization of, say the PSfig model, just on the grounds that `it happens to be there already.' ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@science.utah.edu ======================================================================== ========================================================================= Date: Tue, 23 Oct 90 13:15:01 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Short comment on call for quick \special{} standardization Nelson H.F. Beebe said: > The DVI driver standards committee decided with good reason to delay > standardization of the \special{} command; it truly is a bag of worms, > and almost every driver has implemented it differently. > > I FEEL VERY STRONGLY that the syntax of the \special should be defined > by a rigorous, extensible, grammar, and have previously offered to the > committee members a description of the scheme I have implemented in my > 3.0 DVI driver development. I will not repeat it here, but will > merely observe that neither PSfig, nor any other driver \special{} > I've seen so far, offers the power, or the generality, or the > extensibility, of my proposal, and I would therefore strongly oppose > standardization of, say the PSfig model, just on the grounds that `it > happens to be there already.' I fully support this. Let's first standardize all the other important points -- enhanced maxdrift algorithm, page selection, text placement, etc. For a list you may look at the article of Klaus Guntermann and me (`High Quality DVI Drivers')... Joachim ========================================================================= Date: Fri, 26 Oct 90 12:39:46 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: Specials In-Reply-To: Bart Childs's message of Mon, 22 Oct 90 11:59:31 CDT <9010221711.AA19534@june.cs.washington.edu> PS and HP are not quite the same. The HP convention, however clever, is a limited set of escape-coded instructions, not a fully formed graphics language. PS, though its typesetting quality is not as good as it thinks it is is a generalized graphics language with a clearly defined and extensible syntax. I find pure stack languages very hard to read and program in, but it is a clearly recognized class of languages. THe important thing is that PS is in no sense machine dependent. Unlike HP, PostScript code represents graphic pictures in a satisfactorily abstract way. Considered as a generalized graphics language, PostScript has essentially the same right to claim device independence as TeX. Individual Postscript interpreters and RIPs are device dependent, but PostScript as a language is not. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.acs.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thompson Hall, Mail Stop DR05 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 ========================================================================= Date: Mon, 29 Oct 90 15:43:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Short comment on call for quick \special{} standardization >From: "Nelson H.F. Beebe" >The DVI driver standards committee decided with good reason to delay >standardization of the \special{} command; it truly is a bag of worms, >and almost every driver has implemented it differently. >I FEEL VERY STRONGLY that the syntax of the \special should be defined >by a rigorous, extensible, grammar, and have previously offered to the >committee members a description of the scheme I have implemented in my >3.0 DVI driver development. I will not repeat it here, but will >merely observe that neither PSfig, nor any other driver \special{} >I've seen so far, offers the power, or the generality, or the >extensibility, of my proposal, and I would therefore strongly oppose >standardization of, say the PSfig model, just on the grounds that `it >happens to be there already.' I agree largely with Nelson's comments with one important addendum. It is essential that the most common case of an inclusion, where a file in the output format of the output device is to be included with no scaling and/or rotation should be very simple; there is no reason for such a command to be more complicated than, say, include file.ps or maybe include file.ps,format=postscript -dh ========================================================================= Date: Tue, 30 Oct 90 18:54:13 GMT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: Re: Short comment on call for quick \special{} standardization In-Reply-To: Your message of Mon, 29 Oct 90 15:43:00 PST Don Hosek comments: >> ... >> I agree largely with Nelson's comments with one important addendum. >> It is essential that the most common case of an inclusion, where a >> file in the output format of the output device is to be included with >> no scaling and/or rotation should be very simple; there is no reason >> for such a command to be more complicated than, say, >> include file.ps >> or maybe >> include file.ps,format=postscript >> ... I concur. In my 3.0 DVI drivers, the extensible grammar posted previously permits strings like include = file.ps include : file.ps include file.ps include = "file.ps" include : "file.ps" include "file.ps" include = 'file.ps' include : 'file.ps' include 'file.ps' and when the language (Don's `format') is specified, it can be language = PostScript language = 'PostScript' language = "PostScript" language = dvixxx language = 'dvixxx' language = "dvixxx" ... where dvixxx is the name of the driver that is to process it. This flexibility is important, because it allows an author to write output-device-language-specific specials, and DVI-driver-specific specials. Quoted values in the KEYWORD = VALUE pair syntax are recommended for generality and safety, but can be omitted when the string value can be parsed unambiguously. In summary, I tend to recommend something like \special{language = "postscript", include = "file.ps"} For further details, see my earlier posting. ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@science.utah.edu ======================================================================== ========================================================================= Date: Wed, 31 Oct 90 19:10:57 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Important: change in DVI definition Hi, Tom's mail of last week has triggered me to prepare four ammendments: 1. a small one with only minor changes (which I think is not worth an ammendment...) 2. one which defines round(). 3. one which corrects the max_drift correction 4. one which focuses on warnings on missing fonts. They are sent to the list for first remarks as Don has pointed out. Don, have you incorporated my changes of Oct, 18? There is another change: Don Knuth has changed the DVI definition in TeX 3.1!! Please note the following context diff to bring the appendix dvi.tex up to date: *************** *** 1,6 **** ! % dvi.tex 16 Jul 90 %------------------------------------------------------------ ! % taken from DVItype 3.2 % % definition of DVI format --- 1,6 ---- ! % dvi.tex 31 Oct 90 %------------------------------------------------------------ ! % taken from DVItype 3.4 % % definition of DVI format *************** *** 9,17 **** % ! % VERSION HISTORY (MSCF -- most signifcant change first) % % DATE WHO REMARKS % 90-07-16 js inserted \endinput and version history % 90-07-04 js (Joachim Schrod, xitijsch@ddathd21.bitnet) % first release --- 9,18 ---- % ! % VERSION HISTORY (MSCF -- most significant change first) % % DATE WHO REMARKS + % 90-10-31 js updated from DVItype 3.2 to 3.4. % 90-07-16 js inserted \endinput and version history % 90-07-04 js (Joachim Schrod, xitijsch@ddathd21.bitnet) % first release *************** *** 490,497 **** font number. Once font $k$ is defined, it must not be defined again; however, we shall see below that font definitions appear in the postamble as well as in the pages, so in this sense each font number ! is defined exactly twice, if at all. Like \id{nop} commands and ! \id{xxx} commands, font definitions can appear before the first \id{bop}, or between an \id{eop} and a \id{bop}. \bigbreak --- 491,498 ---- font number. Once font $k$ is defined, it must not be defined again; however, we shall see below that font definitions appear in the postamble as well as in the pages, so in this sense each font number ! is defined exactly twice, if at all. Like \id{nop} commands, ! font definitions can appear before the first \id{bop}, or between an \id{eop} and a \id{bop}. \bigbreak -- end of context diff As usual, the new file dvi.tex may be fetched from listserv@dhdurz1.bitnet (filelist DRIVER). Joachim ========================================================================= Date: Wed, 31 Oct 90 19:11:15 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Ammendment 09 Ammendment: clarify phrases in sections 2.6.2, 2.6.3, and 4.4 Ammendment number: 09 Submitted by: Joachim Schrod Date: 31 Oct 90 This ammendment handles the minor errors shown by Tom Reid. It is submitted as an ammendment because he wanted it. (I by myself think it's not necessary, these are only minor changes.) Furthermore I have added a change to Section 2.6.2 in the explanation of the movement algorithm: the variables x and y were never introduced and they are *not* the registers mentioned in the first paragraph of this section. The ammendment is given as a context diff to the draft 0.04.1 (with the changes incorporated I have sent on October, 18). It constitutes the draft 0.04.2. *** dvistd4a.tex Thu Oct 18 17:02:11 1990 --- dvistd4b.tex Wed Oct 31 17:25:45 1990 *************** *** 247,254 **** value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the new value for $\it hh$. ! For a horizontal movement from any other command, ${\it hh}$ ! should be set to be ${\it hh}+\round(x)$ if $x < {\it word\_space}$ for a horizontal movement to the right or if $x > -{\it back\_space}$ for a horizontal movement to the left. {\it word\_space\/} is defined as $\it space - space\_shrink$, and {\it --- 247,254 ---- value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the new value for $\it hh$. ! For a horizontal movement of $x$ \DVI{} units from any other command, ! ${\it hh}$ should be set to be ${\it hh}+\round(x)$ if $x < {\it word\_space}$ for a horizontal movement to the right or if $x > -{\it back\_space}$ for a horizontal movement to the left. {\it word\_space\/} is defined as $\it space - space\_shrink$, and {\it *************** *** 261,267 **** set to be $\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}+\round(y)$ if $-0.8{\it quad} Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Ammendment 10 Ammendment: definition of round() in section 2.6.2 Ammendment number: 10 Submitted by: Joachim Schrod Date: 31 Oct 90 Reason for change: This ammendment changes the name of the function round() in Section 2.6.2 to pixel_round() and defines pixel_round(). Please note that the change of the name was done in the macro \round. The ammendment is given as a context diff, assuming draft 0.04.2 at it's base. This new ammendment results in the draft 0.04.3. *** dvistd4b.tex Wed Oct 31 17:25:45 1990 --- dvistd4c.tex Wed Oct 31 18:28:22 1990 *************** *** 44,50 **** \def\in{\,in} \def\PK{{\tt PK}} \def\abs{\mathopen{\rm abs}} ! \def\round{\mathopen{\rm round}} \begin{document} \maketitle --- 44,51 ---- \def\in{\,in} \def\PK{{\tt PK}} \def\abs{\mathopen{\rm abs}} ! \def\round{\mathopen{\rm pixel\_round}} ! \def\sign{\mathopen{\rm sign}} \begin{document} \maketitle *************** *** 238,244 **** $(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}=\round(h)$ or ${\it vv}=\round(v)$. Whenever the \DVI-reading program encounters an instruction that changes the current position, it should update $h$ and $v$ using --- 239,247 ---- $(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}=\round(h)$ or ${\it vv}=\round(v)$ where $\round(n)$ is ! defined as $\sign(Kn) \cdot \lfloor \abs(Kn) + 0.5 \rfloor$ with ! $\sign(i)$ resulting in~$-1$ if~$i<0$ and in~$1$ otherwise. Whenever the \DVI-reading program encounters an instruction that changes the current position, it should update $h$ and $v$ using --- end of ammendment ========================================================================= Date: Wed, 31 Oct 90 19:11:51 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Ammendment 12 Ammendment: always issue a warning if fonts are missing Ammendment number: 12 Submitted by: Joachim Schrod Date: 31 Oct 90 Reason for change: If fonts are missing the standard only asks for warnings if an other font is substituted. A warning should be issued unconditionally as the output is not the one the user has requested. The ammendment is given as a context diff, assuming draft 0.04.4 at it's base. This new ammendment results in the draft 0.04.5. ------------------------------------------------------------ *** dvistd4d.tex Wed Oct 31 18:55:15 1990 --- dvistd4e.tex Wed Oct 31 19:05:57 1990 *************** *** 432,441 **** \item Insert black rectangles of the size of the character given in the {\tt TFM} file for the font. \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 processor is unable to locate size information for the font in question, then the processor may simply ignore any {\it set\_char\/} or {\it put\_char\/} commands that occur while the current font is that font. --- 432,441 ---- \item Insert black rectangles of the size of the character given in the {\tt TFM} file for the font. \item Print the characters from that font at a different size or ! from another font at the same size. \end{enumerate} ! In any case a warning must be issued when a font is missing. ! If methods 1 or~2 are used and the processor is unable to locate size information for the font in question, then the processor may simply ignore any {\it set\_char\/} or {\it put\_char\/} commands that occur while the current font is that font. --- end of ammendment ========================================================================= Date: Wed, 31 Oct 90 19:11:38 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Ammendment 11 Ammendment: change of max_drift correction Ammendment number: 11 Submitted by: Joachim Schrod Date: 31 Oct 90 Reason for change: The algorithm for the max_drift correction as given in section 2.6.2 makes too large movements within one word. The corrected algorithm is the same as in DVItype. Technical note: The correction is given explicitely as the definition of the new reference point. A +-1 algorithm would not work because larger errors may occur in one movement. I have introduced the term |dist| which is the distance -- but it's the inverse distance of the former algorithm! This was made because I think that round(Kh) + sign(dist)*max_drift is a more intuitive description as round(Kh) - sign(dist)*max_drift . The ammendment is given as a context diff, assuming draft 0.04.3 at it's base. This new ammendment results in the draft 0.04.4. *** dvistd4c.tex Wed Oct 31 18:28:22 1990 --- dvistd4d.tex Wed Oct 31 18:55:15 1990 *************** *** 273,281 **** 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 $\it 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 0.005\in\ (0.127\mm), 1~for output devices with device units greater than 0.005\in\ --- 273,282 ---- and subscripts to be printed consistently. After any horizontal movement, a final check is made as to ! whether $\it dist > max\_drift$ with $\it dist$ defined as ! $\abs({\it hh}-\round(Kh))$. If it is, then $\it hh$ is set to ! $\round(Kh) + \sign({\it dist}) \cdot {\it max\_drift}$. ! 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 0.005\in\ (0.127\mm), 1~for output devices with device units greater than 0.005\in\ --- end of ammendment ========================================================================= Date: Wed, 31 Oct 90 19:10:57 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Important: change in DVI definition Hi, Tom's mail of last week has triggered me to prepare four ammendments: 1. a small one with only minor changes (which I think is not worth an ammendment...) 2. one which defines round(). 3. one which corrects the max_drift correction 4. one which focuses on warnings on missing fonts. They are sent to the list for first remarks as Don has pointed out. Don, have you incorporated my changes of Oct, 18? There is another change: Don Knuth has changed the DVI definition in TeX 3.1!! Please note the following context diff to bring the appendix dvi.tex up to date: *************** *** 1,6 **** ! % dvi.tex 16 Jul 90 %------------------------------------------------------------ ! % taken from DVItype 3.2 % % definition of DVI format --- 1,6 ---- ! % dvi.tex 31 Oct 90 %------------------------------------------------------------ ! % taken from DVItype 3.4 % % definition of DVI format *************** *** 9,17 **** % ! % VERSION HISTORY (MSCF -- most signifcant change first) % % DATE WHO REMARKS % 90-07-16 js inserted \endinput and version history % 90-07-04 js (Joachim Schrod, xitijsch@ddathd21.bitnet) % first release --- 9,18 ---- % ! % VERSION HISTORY (MSCF -- most significant change first) % % DATE WHO REMARKS + % 90-10-31 js updated from DVItype 3.2 to 3.4. % 90-07-16 js inserted \endinput and version history % 90-07-04 js (Joachim Schrod, xitijsch@ddathd21.bitnet) % first release *************** *** 490,497 **** font number. Once font $k$ is defined, it must not be defined again; however, we shall see below that font definitions appear in the postamble as well as in the pages, so in this sense each font number ! is defined exactly twice, if at all. Like \id{nop} commands and ! \id{xxx} commands, font definitions can appear before the first \id{bop}, or between an \id{eop} and a \id{bop}. \bigbreak --- 491,498 ---- font number. Once font $k$ is defined, it must not be defined again; however, we shall see below that font definitions appear in the postamble as well as in the pages, so in this sense each font number ! is defined exactly twice, if at all. Like \id{nop} commands, ! font definitions can appear before the first \id{bop}, or between an \id{eop} and a \id{bop}. \bigbreak -- end of context diff As usual, the new file dvi.tex may be fetched from listserv@dhdurz1.bitnet (filelist DRIVER). Joachim ========================================================================= Date: Wed, 31 Oct 90 19:10:57 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Important: change in DVI definition Hi, Tom's mail of last week has triggered me to prepare four ammendments: 1. a small one with only minor changes (which I think is not worth an ammendment...) 2. one which defines round(). 3. one which corrects the max_drift correction 4. one which focuses on warnings on missing fonts. They are sent to the list for first remarks as Don has pointed out. Don, have you incorporated my changes of Oct, 18? There is another change: Don Knuth has changed the DVI definition in TeX 3.1!! Please note the following context diff to bring the appendix dvi.tex up to date: *************** *** 1,6 **** ! % dvi.tex 16 Jul 90 %------------------------------------------------------------ ! % taken from DVItype 3.2 % % definition of DVI format --- 1,6 ---- ! % dvi.tex 31 Oct 90 %------------------------------------------------------------ ! % taken from DVItype 3.4 % % definition of DVI format *************** *** 9,17 **** % ! % VERSION HISTORY (MSCF -- most signifcant change first) % % DATE WHO REMARKS % 90-07-16 js inserted \endinput and version history % 90-07-04 js (Joachim Schrod, xitijsch@ddathd21.bitnet) % first release --- 9,18 ---- % ! % VERSION HISTORY (MSCF -- most significant change first) % % DATE WHO REMARKS + % 90-10-31 js updated from DVItype 3.2 to 3.4. % 90-07-16 js inserted \endinput and version history % 90-07-04 js (Joachim Schrod, xitijsch@ddathd21.bitnet) % first release *************** *** 490,497 **** font number. Once font $k$ is defined, it must not be defined again; however, we shall see below that font definitions appear in the postamble as well as in the pages, so in this sense each font number ! is defined exactly twice, if at all. Like \id{nop} commands and ! \id{xxx} commands, font definitions can appear before the first \id{bop}, or between an \id{eop} and a \id{bop}. \bigbreak --- 491,498 ---- font number. Once font $k$ is defined, it must not be defined again; however, we shall see below that font definitions appear in the postamble as well as in the pages, so in this sense each font number ! is defined exactly twice, if at all. Like \id{nop} commands, ! font definitions can appear before the first \id{bop}, or between an \id{eop} and a \id{bop}. \bigbreak -- end of context diff As usual, the new file dvi.tex may be fetched from listserv@dhdurz1.bitnet (filelist DRIVER). Joachim ========================================================================= Date: Wed, 31 Oct 90 13:26:24 LCL Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID ; WED, 31 OCT 90 14:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster That correction you sent out has no real implications as far as FONTS are concerned, right?! The only change is that now \specials CANNOT appear between pages anymore. Am I right? Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ========================================================================= Date: Wed, 31 Oct 90 13:42:32 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" In-Reply-To: Message of Wed, 31 Oct 90 13:26:24 LCL from On Wed, 31 Oct 90 13:26:24 LCL Undetermined origin c/o Postmaster said: >That correction you sent out has no real implications >as far as FONTS are concerned, right?! The only change is that >now \specials CANNOT appear between pages anymore. > >Am I right? > >Stephan v. Bechtolsheim Stephan, It would seem to me that the DVI file change is really nothing more than a correction to the documentation. As far as I know, TeX never wrote XXX commands before a PRE or between EOP and BOP. (If this had been true, it would have given a better way of doing global specials: output them at the end of the preamble just before the first BOP.) You are correct in assuming that the change does not affect fonts. ---Tom ========================================================================= Date: Wed, 31 Oct 90 19:10:57 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Important: change in DVI definition Hi, Tom's mail of last week has triggered me to prepare four ammendments: 1. a small one with only minor changes (which I think is not worth an ammendment...) 2. one which defines round(). 3. one which corrects the max_drift correction 4. one which focuses on warnings on missing fonts. They are sent to the list for first remarks as Don has pointed out. Don, have you incorporated my changes of Oct, 18? There is another change: Don Knuth has changed the DVI definition in TeX 3.1!! Please note the following context diff to bring the appendix dvi.tex up to date: *************** *** 1,6 **** ! % dvi.tex 16 Jul 90 %------------------------------------------------------------ ! % taken from DVItype 3.2 % % definition of DVI format --- 1,6 ---- ! % dvi.tex 31 Oct 90 %------------------------------------------------------------ ! % taken from DVItype 3.4 % % definition of DVI format *************** *** 9,17 **** % ! % VERSION HISTORY (MSCF -- most signifcant change first) % % DATE WHO REMARKS % 90-07-16 js inserted \endinput and version history % 90-07-04 js (Joachim Schrod, xitijsch@ddathd21.bitnet) % first release --- 9,18 ---- % ! % VERSION HISTORY (MSCF -- most significant change first) % % DATE WHO REMARKS + % 90-10-31 js updated from DVItype 3.2 to 3.4. % 90-07-16 js inserted \endinput and version history % 90-07-04 js (Joachim Schrod, xitijsch@ddathd21.bitnet) % first release *************** *** 490,497 **** font number. Once font $k$ is defined, it must not be defined again; however, we shall see below that font definitions appear in the postamble as well as in the pages, so in this sense each font number ! is defined exactly twice, if at all. Like \id{nop} commands and ! \id{xxx} commands, font definitions can appear before the first \id{bop}, or between an \id{eop} and a \id{bop}. \bigbreak --- 491,498 ---- font number. Once font $k$ is defined, it must not be defined again; however, we shall see below that font definitions appear in the postamble as well as in the pages, so in this sense each font number ! is defined exactly twice, if at all. Like \id{nop} commands, ! font definitions can appear before the first \id{bop}, or between an \id{eop} and a \id{bop}. \bigbreak -- end of context diff As usual, the new file dvi.tex may be fetched from listserv@dhdurz1.bitnet (filelist DRIVER). Joachim ========================================================================= Date: Wed, 31 Oct 90 14:10:10 LCL Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID ; WED, 31 OCT 90 15:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster But then on the other hand: dvi files are NOT NECESSARILY written by TeX. That's the reason I wanted the clarification. Thanks for your answer. Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ========================================================================= Date: Wed, 31 Oct 90 15:24:31 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: Short comment on call for quick \special{} standardization In-Reply-To: Don Hosek's message of Mon, 29 Oct 90 15:43:00 PST <9010300200.AA06856@Sunburn.Stanford.EDU> There has been this outstanding problem with edges of ruled tables not quite lining up on low resolution (<=400 dpi) devices. This has to do with rules that are set as follows: <---------------------------- x ------------------------> |-------------------------------------------------------| |-------------------------------------------------|-----| |-----| <- y -> (a) (b) (c) By convention, all of our drivers currently round the left edge of the rule down, and round the size of the rule up. At the moment we will only deal with horizontal positioning and width; vertical positioning is analogous. The main reason the size of rules is rounded up is twofold. First, very small rules don't disappear. Secondly, a rule will look the same no matter where on the page it appears (this last is not in general true for PostScript, and is typically compensated for by using rather thick rules that don't show the problem as much.) But this leaves us with ragged right edges on tables constructed like the one above. Let us figure out exactly when we have a problem. First, I posit that we can change the positioning rule from rounding to truncation with no loss of generality; the only difference is a shift of a half of pixel of the entire page. So we will use truncation rather than rounding. (Drivers may be able to use this observation to their advantage---eliminate that unnecessary +0.5 throughout!) So we will have a problem in the above case when floor(a) + ceil(x) != floor(b) + ceil(y) Now, b = a + x - y so this can be rewritten as floor(a) + ceil(x) != floor(a + x - y) + ceil(y) For arbitrary a, x, and y, this is true exactly half of the time. To prove this, we can limit the range of |a| to [0..1) and limit the range of |x| and |y| to (0..1] with no loss of generality (since adding an integer to either adds the same integer to both sides). But then floor(a) == 0, and ceil(x) == 1, and ceil(y) == 1, giving us 0 != floor(a + x - y) which is true for half of the cube. In addition, it is true for each plane such that y is set to some arbitrary value, so the problem does not go away if we try to limit the width of the rules to some integer multiple of pixels, since we have no real control over absolute position (and thus |a| and |b|.) I propose a solution that keeps the benefits of the round up rule while fixing the ragged right edges, and at a very small increase in the computational costs of dvi processing. Specifically, I propose that some value in pixels be chosen (say, 10) such that if a rule is narrower than this, its width be calculated according to the traditional rules. But, if the rule is wider than this, than the width be calculated as PixRound(a + x) - PixRound(a) (or, in other words, that the right edge of the rule be rounded just like the left edge.) In this equation, PixRound() is the function that rounds a dvi unit to a pixel unit, whether by truncation or actual rounding. Going back to our example at the top, if both example rules are wider than the minimum we set, then everything will work correctly and the rules will line up. If the bottom rule is a `skinny' rule, it will be positioned as before, and we will have a misalignment if floor(a) + floor(a + x) - floor(a) != floor(a + x - y) + ceil(y) or floor(a + x) != floor(a + x - y) + ceil(y) or, restricting our range of |a|, |x| and |y| as before, floor(a + x) != floor(a + x - y) + 1 In the general case, this is again true half the time, but this time the percentage is dependent on y, which is under our control. The closer |y| is to an integer while still slightly less than one, the more likely things are to mesh exactly. (The actual probability equation is p(exact mesh) = frac(-y) where frac(n) is the fractional part of n, or n - floor(n). Thus, if y is 2.99 pixels, then the probability of an exact mesh is better than 99%. At high resolutions, this problem disappears and the rounding becomes less important, so using a `pixel' value is appropriate. In addition, the ugliness of two `identical' rules having different actual widths is in proportion to the ratio of the two widths, so only kicking in the new rounding algorithm above ten pixels makes things work. Of course, in order to get perfect boxes at a particular resolution, it is still necessary to `tune' the rule widths of narrow rules to slightly less than a pixel. Comments? I haven't implemented this yet in any of my drivers, but I well may. Thanks for your attention. -tom (rokicki@cs.stanford.edu) ========================================================================= Date: Wed, 31 Oct 90 15:31:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Special locations >That correction you sent out has no real implications >as far as FONTS are concerned, right?! The only change is that >now \specials CANNOT appear between pages anymore. This is actually a reasonable approach; I presume that the change was provoked by the question raised over the summer of what to do with specials between pages when one was reordering pages. Since no application currently available can produce specials in these locations, the loss is negligible. My recommendation had always been to ignore interpage specials anyway. -dh ========================================================================= Date: Wed, 31 Oct 90 15:56:07 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" In-Reply-To: Message of Wed, 31 Oct 90 14:10:10 LCL from On Wed, 31 Oct 90 14:10:10 LCL Stephan v. Bechtolsheim said: >But then on the other hand: dvi files are NOT NECESSARILY >written by TeX. That's the reason I wanted the clarification. > >Thanks for your answer. > >Stephan v. Bechtolsheim Actually, rereading the DVI format description, this is not really a clarification of where XXX commands can appear. Instead of suggesting that XXXs can appear before the first BOP and between EOPs and BOPs, the new description seems to be silent on the issue. (Were there other changes made elsewhere?) Stephan, you are correct in that there are other programs which can and do generate DVI files. Further, filling in for unspecified actions based on what TeX itself does is not really the proper thing to do. This, however, leaves unspecified the question of where XXX commands can appear. The author of a DVI-writing program is free to write the commands at these points. (Actually, if one were to consider DVI and GF to be a family of related file formats, XXX commands should be allowed anywhere in a DVI file: in the description of the GF format, it is specifically stated that this is allowed [Volume D, Section 1144, description of XXX1 command].) Regarding the Don's latest note about what to do with XXX commands appearing between pages: The same approach that is used in GF files could be used: they belong to the object (page for DVI, character for GF) which follows. Of course, this complicates things for drivers which scan DVI files backwards using the backpointers. (Unlike the backpointers in GF files [Volume D, Section 1147, next to last paragraph], pointers in DVI files point to the previous BOP.) I do not advocate allowing XXX commands between pages. I simply feel that if we are to prohibit it, we should. Silence on a particular issue does not necessarily imply prohibition (unless, of course, this is an unwritten rule ;-). ---Tom Reid