========================================================================= Date: Mon, 3 Sep 90 10:11:14 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: other programs which produce DVI files > however, there do exist other programs, unrelated to TeX, that > output .dvi format (one such was cited recently on this list). An interesting TeX-unrelated program which produces DVI is GNU troff (one needs a troff for printing UNIX manual pages). Interesting because in the output DVI units are no scaled points -- many drivers break down on that. Joachim ========================================================================= Date: Mon, 3 Sep 90 18:15:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: DVI driver standard Date: Mon, 3 Sep 90 12:00:39 +0200 From: Peter Dalgaard SFE Subject: DVI driver standard To: dhosek@YMIR.CLAREMONT.EDU I'm by no means an expert on this subject, but I did spend some time tracking down a bug in one of Beebe's drivers. One curious feature of the cmr font is that the TFM width and the pixel width do not always agree to within rounding error. The characters i, l, and 'dotless i' are explicitly corrected by one pixel in the Metafont sources if necessary to achieve symmetry. In particular, this happens in the 11pt font at 300dpi. Therefore, whatever positioning algorithm is chosen, words that contain many 'i's and 'l's should be carefully checked for visual appearance. Here is a list of suggested benchmarks: iii) milliliter illiterate initialization In particular, 'iii)' is visually very sensitive to uneven spacing of the 'i's. Long words like 'initialization' tend to provoke an explicit positioning command in the middle of the word in the DVI file, which can lead to very ugly results. Peter Dalgaard pd@kubism.ku.dk ========================================================================= Date: Mon, 3 Sep 90 18:58:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: Comment on amendment 6 Nelson sent me the following a while back. Unless there is any objection, I'd like to accept Nelson's modification to the text as given. From: "Nelson H. F. Beebe" Subject: Comment on amendment 6 To: dhosek@science.utah.edu In >>... >> Amendment: DVI limits only for devices which may support it (S2) >> Amendment number: 06 >> Submitted by: Joachim Schrod >> Date: 02 August 1990 >> Change to read: >> >> As a rule, {\tt DVI} drivers should be able to interpret any {\tt >> | DVI} file which falls within the following limits. >> | If these requirements may not be realized due to limits of the >> | output device they should be fulfilled as far as possible. Besides of >> | this exception the >> specifications are a {\em minimum\/}; good drivers will probably >> be able to handle {\tt DVI} files exceeding these limits ({\tt >> DVI} files which exceed the limits are likely to be rare, but >> might still occur). >>... The English is incorrect. It should read >>... >> If these requirements may not be realized due to limits of >> the output device, they should be fulfilled as far as >> possible. Aside from this exception, the specifications... >>... I agree with the intent, but we must be certain to have the language correct first. ------- ========================================================================= Date: Mon, 3 Sep 90 19:05:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: RE: Specification of algorithim for handling rounding to device units From: IN%"hobby@research.att.com" 29-AUG-1990 08:38:24.27 To: dhosek@HMCVAX.CLAREMONT.EDU CC: Subj: RE: Specification of algorithim for handling rounding to device units Received: from research.att.com (192.20.225.2) by HMCVAX.CLAREMONT.EDU with PMDF-822; Wed, 29 Aug 1990 08:36 PDT Date: Wed, 29 Aug 90 08:36:33 EDT From: hobby@research.att.com Subject: RE: Specification of algorithim for handling rounding to device units To: dhosek@HMCVAX.CLAREMONT.EDU Message-id: X-Envelope-to: dhosek I have some comments on the proposed specification: 1. If all standard drivers are to be required to meet this specification, it is too specific. For instance, $\lceil Kn-{1\over2}\rceil$ and $\lfloor Kn-{1\over2}\rfloor$ should not be excluded as possible definitions for ${\it pixel\_round}(n)$. The only time the ceiling is required is for rule dimensions. I am also skeptical about fixing exact values for ${\it max\_drift}$. 2. I think it is a mistake to add or subtract ${\it max\_drift}$ from $\it hh$ when it gets too far away from $Kh$. It is fairly well established that $\it hh$ should be changed by the minimal amount necessary to bring it into the desired range. Thus the correction should be something like $${\it hh}\gets\lfloor Kh+{\it max\_drift}\rfloor$$ or $${\it hh}\gets\lceil Kh-{\it max\_drift}\rceil$$ as appropriate. (This even allows ${\it max\_drift}$ to be non-integer if desired.) 3. I did not intend to force everyone to throw out their existing code that tests ${\rm abs}({\it hh}-{\it pixel\_round}(n))$ instead of ${\rm abs}(Kh-{\it hh})$. Recent messages to TeXhax could mislead people into thinking that I did. Similarly, I don't want to force the correction stategy suggested in comment 2 on everyone, especially those who test ${\rm abs}({\it hh}-{\it pixel\_round}(n))$. - John Hobby hobby@research.att.com (201)582-5362 ========================================================================= Date: Mon, 3 Sep 90 19:06:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: standard for DVI drivers: comment [Next time I send something out for general comment, I'll just have them send there responses straight to driv-l... over a week for me to get to forwarding? Horrid!] Date: Wed, 29 Aug 90 13:58:50 +0200 From: maavl@cwi.nl Subject: standard for DVI drivers: comment To: dhosek@YMIR.CLAREMONT.EDU Message-id: <9008291158.AA08715@papegaai.cwi.nl> X-Envelope-to: dhosek Dear Don Hosek, this is a comment on the draft for specfictaions for DVI drivers I just received from TeXhax issue 57 (your contribution was dated more than a month ago, I hope this response is still in time). I missed a point or two that has caused me some annoyence on existing DVI-drivers. Most importantly, there is no specification of the rounding of rules. According to what is said on this point in Volume B of Comp.&Typesetting (TeX The Program) there can be but one correct way to do this. First the width and height of the rule must be rounded to device units (pixels), resulting in and integer-sized rectangular region of pixels. Then this rectangle should be positioned as if it were a character with its origin in the lower left hand corner. Note that this again involves rounding, so the upper and right edges will be subject to double rouding, thereby possibly moving a full pixel from their "ideal" location. I am not sure if the current specifications imply that if in a sequence of rule- and displacment commands (no intervening characters) two of the rules have the same `h' coordinate (resp. `v'), then their left (resp. bottom) edges will align perfectly (in other words, the amount of drift will be unchanged); in any case this would be a very desirable property. Another point is mostly relevant for screen- and dot-matrix DVI drivers, that set up a bitmap representation in memory for the page. In this case it is probably the bitmap size rather than the physical dimensions of the device (what is the physical dimension of a window in a windowing system anyway?) that determine where the output will be clipped. It would be desirable to have some indication of how large this bitmap should be chosen, probably depending on the contents of the DVI file. In view of the 1-square- inch directive concerning the upper-left corner (which itself is hardly relevant for these drivers) and the common practice printing into the margins I would suggest that for each page the size of the shipped-out box should be surrounded by at least 1-inch margins on all sides. By the way, I have been using METAFONT to draw pictures that were to be incorporated in TeX documents, and have experienced that none of the drivers I have access to satisfy the minimal requirements in your proposal, especially on the point of character size (I had to revert to chopping-up techniques); it would be nice if future DVI drivers would not have such problems. -- Ma van Leeuwen Ce re for Mathematics and Computer Science Am erdam, The Netherlands in rnet: maavl@cwi.nl ========================================================================= Date: Mon, 3 Sep 90 19:11:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: A few more amendments decided amendments 6&7 have received enough votes to be considered decided. Since amendment 2 has been stalled and is over a month old, I've concluded voting on that as well, giving a tie-breaker vote to fail it. By the way, my decision on the expiration dates for amendments is to make the limit be 28 days, before the amendment is closed. It was pointed out that, for some people, vacations and business trips would make two weeks a bit inconvenient. Four weeks seems like a better compromise. For your information, here is the voting chart for amendments to date. |Amendment Number | | | | | | |0000|0000|0111|1111|1112|2222 |1234|5678|9012|3456|7890|1234 --------------------------+----+----+----+----+----+----- Nelson Beebe |YNNN|YYYY| | | | Bart Childs |YYYY|yYYN| | | | Adrian Clark |ZZZZ|YNNY| | | | Bernard Gaulle |YNNN|YYYN| | | | John Gourlay |YNNN|YYAA| | | | Robert McGaffey |XXXX|XXX | | | | Tom Rokicki |YNNN|YYYN| | | | Jan Michael Rynning |nYyy|yYYY| | | | Joachim Schrod |YYNN|YYYY| | | | Ralph Youngen |XXXX|XXX | | | | --------------------------+----+----+----+----+----+----- Pass/Fail: |PfFF|PPP | | | | Legend: ------- A Abstain F Failed f failed with chair's tie-breaker N No P Passed p passed with chair's tie-breaker Y Yes W Withdrawn X No vote received Z Not on committee when amendment submitted n "no" Vote received after amendment decided: included "for the record" y "yes" Vote received after amendment decided: included "for the record" Amendment 1: Change margin of error tolerance (S4.3.2) Amendment 2: Change padding to end of DVI files (appendix A) Amendment 3: Change padding to end of GF files (appendix B) Amendment 4: Change padding to end of PK files (appendix C) Amendment 5: Change to wording of minimum stack depth (S2.5) Amendment 6: DVI limits only for devices which may support it (S2) Amendment 7: Change to definition of limits for maxdrift (App E) Amendment 8: Change to maxdrift value (App E) ========================================================================= Date: Mon, 3 Sep 90 19:13:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: Amendment number: 07 Something of interest... Date: Fri 31 Aug 90 18:20:57-MDT From: "Nelson H. F. Beebe" I tentatively vote Yes on Amendment number: 07. I have not implemented code that follows this, and I am uncertain enough about its impact that I expect to make any such code controlled by a run-time option from the command-line or a startup file in my 3.0 DVI drivers. ------- ========================================================================= Date: Tue, 4 Sep 90 20:30:06 GMT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: CA_ROWLEY%vax.acs.open.ac.uk@RELAY.CS.NET Subject: RE: FWD: Comment on amendment 6 > > Nelson sent me the following a while back. Unless there is any > objection, I'd like to accept Nelson's modification to the text as > given. I can't say I'm wild about Nelson's English either, but I defer to Don's academic status in this area (maybe it's the Utah dialect?) chris ========================================================================= Date: Wed, 5 Sep 90 10:28:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek From: IN%"bkph@ai.mit.edu" 2-SEP-1990 05:09:52.99 To: dhosek@YMIR.CLAREMONT.EDU CC: Subj: DVI-standard Received: from life.ai.mit.edu (128.52.32.80) by YMIR.CLAREMONT.EDU with PMDF-822; Sun, 2 Sep 1990 05:09 PDT Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA19154; Sun, 2 Sep 90 08:16:25 EDT Received: by rice-chex (4.1/AI-4.10) id AA27774; Sun, 2 Sep 90 08:16:17 EDT Date: Sun, 2 Sep 90 08:16:17 EDT From: bkph@ai.mit.edu (Berthold K.P. Horn) Subject: DVI-standard To: dhosek@YMIR.CLAREMONT.EDU Message-id: <9009021216.AA27774@rice-chex> X-Envelope-to: dhosek Hi: some quick comments on the draft standard, for work on which I wish to thank you! (I am sure you are tired of reading this stuff, but...) (a) There may need to be a distinction between what limitations are due to the driver, and what are due to the device it is driving. Should a driver be considered non-conforming just because there is no way to make a particular device do what is requested? (This is mostly in connection with sections 2.2.2, 2.2.3, 2.3.1, 2.4, 2.6.4). (b) Where does the requirement for a stack-depth of 100 come from section 2.5)? Several of the other requirements appear to relate closely to real requirements of typical DVI files. For example, some TeX output really does use a lot of fonts (Nelson Beebe's DVI driver manual, for example), so requiring a minimum of 64 fonts seems quite reasonable. But deep stacks seem quite rare (or am I missing something?). Perhaps the thinking was that deep stacks should be easy to implement, so why not make this number quite large? But what if some way of processing DVI files makes it expensive to allow deep stacks? Should a driver be excluded just because it can't handle something that virtually never happens in practice? How about making the limit 64 instead (a nice round number)? (c) Throughout the standard there is a strong assumption that bitmaps are used - there is some danger here that you will be legislating what programs written in the past ought to do! (closing the barn door after the proverbial cow). Of course, it is quite common for standards to only emerge once things stop changing - and one reason things stop changing is that they are slowly becoming obsolete (I don't mean this to sound irritating, I am merely am trying to be funny or provocative here, but read on). There shouldn't be an insistence on being able to read PK files (section 4.1), for example, if the job can be done without them. Similarly there shouldn't be an insistence on being able to read TFM files, particularly if the information you need (namely TFMW) is in the PK files already. In this context, several sections may become less relevant (section 4.2, 4.3, for example). That is, section 4 seems to address what may be implementation issues, things that should perhaps be left up the implementer, not the standard. That is the standard should focus on what is to be accomplished, not details of how it is accomplished. (Maybe it should say: The driver should be able to read PK files if it needs them---which is kind of redundant). (d) Similar things may be said about the appendix on rounding to device units. Rather than saying this is how you should do rounding, it should perhaps say, something like, if you can't do the right thing, you may deviate up to what the following algorithm provides for. But it should not force drivers to make errors as large as those inherent in the DVItype max_drift algorithm (whatever version is finally decided upon). Again too much focus on implementation issues, not what is to be accomplished. The standard appears to be forcing a particular implementatin, virtually writing the code for the implementer. (e) The section on specials (2.8) seems to be slightly inconsistent or perhaps ambiguous. On the one had it says specials need not be supported, yet it requires that specials not defined by the standards committee should be flagged. This suggests that the driver needs to know which specials are in this (yet to be defined) list and which aren't, even though it doesn't know what to do with them either way. Maybe it should say that the driver must at least flag those not in the magic list, but it may in fact just go ahead and flag all specials. (n-1) Presumably by set_char and put_char in the second last paragraph you mean set*, put*. (n) The appendices are missing. Some refer to material generally available, for example, in ``TEX: the program'' but other material appears to be specific to this proposed standard and hence should be included soon to invite discussion. For example, the list of DVI commands to be supported (section 2.1) is rather important (I'd, by the way, recommend all, but fnt_def2, fnt_def3, fnt_def4, fnt2, fnt3, fnt4, set2, set3, set4, put2, put3, put4 - given that the limit on number of fonts is 256 and the limit on the number of characters in a font is 256). (n+1) does there exist a draft DVI "trip test"? Berthold K.P. Horn P.S. please don't misinterpret the critical tone of this piece of email, I really appreciate what you are doing, and I was smiling all the time I wrote it. Unfortunately facial expressions cannot be communicated in email - and without body language you can't tell what is said tongue in cheek from what is meant to be offensive... ========================================================================= Date: Thu, 6 Sep 90 10:49:14 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: DVI standard Berthold K.P. Horn writes > There shouldn't be an insistence on being able to > read PK files (section 4.1), for example, if the job can be done > without them. The insistence on PK files is ok because it allows a user to send fonts in this format along with his document. There should be one format, generally agreed upon. It's PK because DVI is still used together with TeX and fonts generated by METAFONT. > Similarly there shouldn't be an insistence on being > able to read TFM files, particularly if the information you need > (namely TFMW) is in the PK files already. There is no insistence on the usage of TFM files. But please note that more informations than the TFM width can be used: the space dimensions -- and these are not available in the PK file. (See also ammendment 07 which was accepted in the mean time.) > (d) Similar things may be said about the appendix on rounding to > device units. Rather than saying this is how you should do rounding, > it should perhaps say, something like, if you can't do the right > thing, you may deviate up to what the following algorithm provides > for. But it should not force drivers to make errors as large as those > inherent in the DVItype max_drift algorithm (whatever version is > finally decided upon). Again too much focus on implementation issues, > not what is to be accomplished. But what is this: ``the right way to do rounding''? The answer is given by the algorithm and if anybody is using an other algorithm which he can prove to be equivalent he may. We can not expect that the ``right way'' is obvious -- we had too much discussions on it. Let me just give an actual example for the importance of the inclusion of such themes in the standard: Commercial distributed fonts like the Kinch AP fonts or the Bitstream fontware package have wrong horizontal escapements in their PK files (i.e., the pixel widths differ more than 50% from their equivalences of the TFM widths); and commercial drivers often don't use the horizontal escapements. The result of this alliance is that the font suppliers tell: Why should I repair the fonts, there are drivers around which can use them properly. And the driver writers say: Why should I change the driver? Look, it's doing better than your `so-called-standard-driver'! (I'm about to write a TUGboat article on this subject.) To emphasize it again for the people new in this discussion list: There may be differences between the pixel equivalences of TFM widths and the corresponding horizontal escapements which are intented by the font designer and which must be obeyed by the driver! > The standard appears to be forcing a > particular implementatin, virtually writing the code for the implementer. This is of course a problem but how should we PRECISELY specify how the way is ``to do the right thing''? > (n+1) does there exist a draft DVI "trip test"? An interesting question. In my opinion it should read: ``Will there ever be a DVI trip test?'' I cannot see how we can test things like precise positioning of chars and rules; and these are the things I consider as important because they concern the elementary functionality of a driver: to output a document with the highest quality available on this device, just like TeX should be used to typeset `masterpieces of the typographic art'. Joachim Schrod ========================================================================= Date: Thu, 6 Sep 90 15:28:05 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: ogawa@SATURN.ARC.NASA.GOV Subject: Membership I would be interested in becoming a member of this discussion group. My particular accent will be on the ways that DVI standards affect Mac, DOS, and Unix users as regards book publishing (corporate publishing included). Issues around support of non-CM, non-MF fonts, integrated graphics, high-res output, workgroup publishing, demand publishing are my concern. My thanks to all current members for their efforts. Art Ogawa TeX Consultants 920 Addison/ Palo Alto, CA 94301 415-323-9212 ========================================================================= Date: Thu, 6 Sep 90 22:46:34 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: ogawa@SATURN.ARC.NASA.GOV Subject: re: Draft Proposal "Level 0" DVI Driver Standard This is in response to the Draft proposal for DVI Standard (level 0), version 0.03. First, many thanks for the work put into this document, and others. Second, my apologies for not being more active sooner. General: 0. The meaning of ``DVI Driver'' seems conceptually unclear. DVI is a _page description language_. DVI files are _read_ by ``DVI readers''. DVI files read by such readers are then _translated_ to the native language of the target device, where the pages are _rendered_. 1. I find the use of the word ``should'' inappropriate in a standard. This document would do better to use ``shall'' and ``must'' as appropriate. The word ``should'' finds its best use as a way of recommending best practices. Therefore I suggest rewriting the document with due attention paid to every instance of ``should''. 2. The point of view from which these standards are written seems much too narrow, e.g., the concern only with fonts that are bitmapped and downloaded, output only to paper, software that is implicitly not commercial. 3. Style: ``level-0 standard'' (note hyphen). Abstract: I would change the organization and some of the wording as follows: Change from: \begin{abstract} The following represents a minimal standard (level~0) for {\tt DVI} drivers. The complete standard will be presented as a series of ``tiers'' requiring increasingly stringent control over the output of {\tt DVI} drivers. A trip test for {\tt DVI} drivers will be created which will allow developers of {\tt DVI} drivers to insure that their drivers meet the standards developed here. The specifications here should be considered minimal and driver developers are encouraged to write drivers whose capabilities are beyond these specifications. This version of the Level~0 Standard presented here is draft~0.03. It has been reviewed by the TUG Driver Standards Committee and is now being presented to the TUG membership at large for review. This will form one portion of the TUG {\tt DVI} Driver Standard. \end{abstract} Change to: \begin{abstract} The TUG {\tt DVI} Driver Standard defines functional and interface | requirements for computer programs (DVI drivers) | that read and translate files in the DVI page description language. | This document is the subset of the DVI standard (level~0) | applying to minimally functional DVI drivers. | The specifications here should be considered a minimum requirement; | developers are encouraged to write drivers exceeding these | specifications. | (The version of the Level~0 Standard presented here is draft~0.03. It has been reviewed by the TUG Driver Standards Committee and is now being presented to the TUG membership at large for review.) The complete standard will be presented as a series of ``tiers'' requiring increasingly stringent control over the functionality and interface of {\tt DVI} drivers. | A trip test for {\tt DVI} drivers will be created which will allow developers of {\tt DVI} drivers to insure that their drivers meet the standards set forth here. | \end{abstract} Section 1 {Purpose of the Level~0 standard}: I would like to clarify the first paragraph as follows: Change from: The Level~0 Standard is meant to be a base standard to which all drivers should adhere. It is intended to allow all reasonable applications to be printed on all drivers. Change to: The Level~0 Standard is intended as a base standard to which all | conforming drivers must adhere, allowing all reasonable | documents to be rendered (i.e., printed or displayed) accurately. | When we refer to accurate rendering, we mean that the when the data | generated by the DVI driver are transmitted to the output device, | the latter shall produce a page accurately depicting | the page described by the DVI file (disregarding resolution effects).| Section 2 {The {\tt DVI} file}: I want to add the important change in functionality as follows: Change from: As a rule, {\tt DVI} drivers should be able to interpret any {\tt DVI} file which falls within the following limits. These specifications are a {\em minimum\/}; good drivers will probably be able to handle {\tt DVI} files exceeding these limits ({\tt DVI} files which exceed the limits are likely to be rare, but might still occur). Change to: A conforming driver shall be capable of accurately {\it reading} any | valid DVI file. | | It shall also correctly {\it render} any {\tt DVI} file | whose demands on the DVI driver fall within the following limits. | These specifications are a {\em minimum\/}; good drivers will probably be able to handle {\tt DVI} files exceeding these limits ({\tt DVI} files which exceed the limits are likely to be rare, but might still occur). Section 2.2.1 {Number of characters in a {\tt DVI} font}: The footnote is probably referring to the HP LaserJet. The problem is that it begins by talking about an ``output device'' and ends by talking about ``downloading a font to the printer.'' Needs a rewrite. Sections 2.2.2, 2.2.3, 2.3.1, 2.4, 4.4 (item 3): Change ``print'' to ``render,'' since we're device independent. Section 2.6.1 {Location of the origin}: Give the metric equivalent of the measurement: ``one inch (2.54 cm)'' Section 2.6.4 {Objects off of the page}: I understand the intent here (having experience with HP's PCL interpreters), but the exposition needs cleaning up: Change from: Any printable object which would lie entirely off the physical page should not be printed but any changes to positioning should still be taken into consideration. Any printable object which would lie partially off the physical page should either be clipped so that portion of the object that lies off the page is not printed or omitted entirely. Change to: Any printable object which would lie partially or entirely off | the physical page may remain unrendered, but any resulting changes | to positioning must still be accurately reproduced: all other objects| on the page must be accurately rendered. | Section 3 {Configuration}: The text of this section refers to ``recompiling the driver.'' This is not an appropriate way to refer to a commercial application, where recompiling is customarily out of the question. Change from: It should be possible for the installer of a driver to configure such things as the location and naming scheme of fonts, default paper size, etc.\ without having to recompile the driver. Change to: The installation procedure for a driver shall allow | configuring such things as the location and naming scheme of fonts, | default paper size, etc., in a flexible way. | Section 4 {Font files}: This entire discussion is inapplicable to systems employing printer-resident fonts, scaleable fonts, and system-supported fonts. On a Macintosh or a NeXT printing to a PostScript printer, the DVI driver need never concern itself with a single bitmap (when MF fonts are never used, for example). However, the DVI driver still needs to make the connection between the TFM name of a font and the system name of the font, so the discussion of ``Missing Fonts'' is still applicable. Furthermore, support for bitmap format fonts should in principle be optional. I agree that PK is preferrable to PXL, but I think that the simple ability to convert freely between PK, PXL, GF, and system formats (OS2, MS-Windows, Macintosh) provides enough support at installation or configuration time. I suggest the following changes: Section 4 {Font files}: I suggest changing the name of this section to ``Font Support''. Section 4.1 {Font formats}: Change from: The driver should be able to read {\tt PK} fonts with the location specifiable at run time. The {\tt PK} format is given in appendix~\ref{pk-format}. {\tt GF} support is optional. The {\tt GF} format is given in appendix~\ref{gf-format}. Change to: The driver should be able to read {\tt PK} fonts with the location specifiable at run time. Alternatively, the driver's installation may support PK format | bitmap fonts by converting them to a system-supported format, | with the driver supporting system fonts. | 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}. Section 4.2 {The scaling number}: This section is unmotivated and is not related to the other sections. Has something been left out? Section 4.3.1 {Minimum set of magnifications}: The word ``load'' has not been defined. I suggest changing it to ``render'', as elsewhere with ``print''. Section 4.3.2 {Margin of error}: It to be seems your intent to allow silent font substitution under certain circumstances. The language of this section mandates silence; surely not your real intent. Change from: If a {\tt DVI} file requests a magnification within 2\,\% of a supported magnification, the driver should use that font without warning. Change to: If a {\tt DVI} file requests a magnification within 2\,\% of a supported magnification, the driver should use that font, | and may do so without issuing a warning. | Section 4.4 {Missing fonts}: Saying that the DVI driver is to ``continue processing'' and ``under no circumstances'' to abort is clearly to mandate against the behavior of some of ArborText's drivers which bomb if a required font is not found. This is already taken care of by the first paragraph of section 2, which requires error-free processing of any valid DVI file. Also, the language needs to be more precise with respect to font and member. Change from: If a font is missing the driver should continue processing and deal with the missing font in one of three ways: \begin{enumerate} \item Insert appropriate white space where the font would appear, \item Insert black rectangles of the size of the font given in the {\tt TFM} file, \item Print the characters from that font at a different size or from another font at the same size after issuing a warning. \end{enumerate} If methods 1 or 2 are used and the driver is unable to locate size information for the font in question, then the driver may simply ignore any {\it set\_char\/} or {\it put\_char\/} commands that occur while the current font is that font. Under no circumstances should a missing font cause a fatal error. Change to: A missing font\impnote{% | We emphasize: | under no circumstances shall a missing font cause a fatal error | (see Section~2).% | } | shall be treated in one of three ways: | \begin{enumerate} \item Insert appropriate white space where the font member would | have appeared, where the width of such space is to be | derived from font metric (TFM or other) information. | \item Insert a black rectangle as in the preceeding method. | \item Print the member from that font at a different, but available, | size or from another font at the same size after issuing a | warning message. | \end{enumerate} If methods~1 or~2 are used, and the driver is unable to locate | size information for the font in question, then the driver may simply ignore any {\it set\_char\/} or {\it put\_char\/} commands that occur while the current font is that font. ========================================================================= Date: Fri, 7 Sep 90 15:30:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: From the masses.... From: IN%"WSULIVAN@IRLEARN.BITNET" "Wayne G. Sullivan" 7-SEP-1990 04:09:26.8 7 To: Don Hosek CC: Subj: dvi standards Received: from YMIR.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU with PMDF-822; Fri, 7 Sep 1990 04:08 PDT Received: from IRLEARN.UCD.IE (MAILER@IRLEARN) by YMIR.CLAREMONT.EDU with PMDF-822; Fri, 7 Sep 1990 04:08 PDT Received: by IRLEARN (Mailer R2.03B) id 2138; Fri, 07 Sep 90 11:57:52 GMT Date: Fri, 07 Sep 90 11:46:56 GMT From: "Wayne G. Sullivan" Subject: dvi standards To: Don Hosek Message-id: X-Envelope-to: dhosek You asked for comments so here: The 'small space' algorithms seem very close to those in DVITYPE, but not quite the same. Is there any good reason for the changed values? Though the values in your abstract are quite reasonable, it seems to me absolute stupidity to fiddle with a reasonably good standard. Next time somebody will make some other minor change: the result is chaos. Perhaps I misunderstand, but it seems that it is proposed to use truncation rather than rounding to obtain hh from h. Again, this looks like tinkering for no good reason. It can be even worse, though, because in many TeX files the left margin has h=0. A single sp rounding error could cause the left margin to be 1 pixel out. Wayne Sullivan ========================================================================= Date: Tue, 18 Sep 90 10:06:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: ex populo cognoscenti [thoughts from the people] From: IN%"PEB@DM0MPI11.BITNET" "Peter Breitenlohner 32308-412" 18-SEP-1990 04 :57:24.94 To: Don Hosek CC: Subj: Received: from JNET-DAEMON by HMCVAX.CLAREMONT.EDU with PMDF-822; Tue, 18 Sep 1990 04:57 PDT Received: From DM0MPI11(PEB) by HMCVAX with Jnet id 8902 for DHOSEK@HMCVAX; Tue, 18 Sep 90 04:57 PDT Date: 18 September 90, 13:37:42 GMT From: Peter Breitenlohner 32308-412 (089) To: Don Hosek Message-id: X-Envelope-to: DHOSEK Don, I have three comments on the Driver Standard (Lev 0): 1. > The driver should accurately track movement using the pixel width > from the font raster file and the {\tt TFM} width from either the > font raster file or {\tt TFM} file with the {\tt TFM} width from > the font raster file taking priority. ..... Here I would prefer: The driver should accurately track movement using the pixel width from the font raster file and the {\tt TFM} width from either the font raster file or {\tt TFM} file which ought to be identical. Any difference detected in these {\tt TFM} width values should be noted as an error that should, sooner or later, be eradicated from the font files. Likewise any discrepancy in the font checksum values should be noted as an error (provided that both values are non-zero). ..... I think it is not very important that the drivers show a consistent behaviour with lousy font files. To me it seems much more important that such discrepancies should be detected in order to be taken care of. 2. I don't quite understand why all movements should be rounded upwards when converted from DVI units to pixels. There may be good reasons for that in rule dimensions, but I can see no such reasons in other movements (e.g. kerns etc). 3. What is the driver supposed to do with non-integer character escapements (as supported by the GF and PK format)? round them upwards again? Assume that a PK file specifies an escapement of 8.05 pixel, should this really be rounded to 9? I would rather think it should be rounded to 8! Regards Peter