========================================================================= Date: Thu, 1 Aug 1991 13:15:06 MDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: Re: Virtual fonts In-Reply-To: Your message of Tue, 30 Jul 1991 11:46:58 -0500 A dvi to dvi processor which eliminates virtual fonts has already been written, and is on some of the archives. Tom Rokicki's dvips driver supports virtual fonts. Mine do not yet, but will before release. ======================================================================== 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@math.utah.edu ======================================================================== ========================================================================= Date: Fri, 9 Aug 1991 17:28:37 MSZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Draft 0.05a of level-0 standard available Here we are again :-) While I created the report for the Board I looked over the driv-l backlog of the last year. I found that a lot of minor corrections were posted in the last year which did not find their way in the draft. Well, I sit down a few days and spent work on the draft. It is now (La)TeXable [sic!] and contains no overfull hboxes anymore (but some underfull's which I still must look at ;-). The changes are outlined at the end of this mail. IMO, they are to be considered minor changes. In the driv-l mails there were even more problems and inconsistencies pointed out, but I was not able to repair them without serious changes. Therefore I will present those problems again in postings coming `real soon now.' Since there has been no change on the draft since March, 25, I assume that the draft (neglecting the problems mentioned above) is settled. Therefore I will forward it to barbara beeton for publication in TUGboat (as an official RFC), so that we may schedule a final approval for the end of this year. (I think a new tier with standardization of specials is waiting for us ;-) IF YOU HAVE ANY OBJECTIONS ON THE MINOR CHANGES MADE BY ME RECENTLY, YOU SHOULD IMMEDIATELY SEND ME A NOTE !!!! =========== [A summary of the changes follows below!] Yep, but how you may receive it? -- Anonymous ftp users fetch it from ftp.th-darmstadt.de, directory pub/tex/dvi-standard/standards. If you have compress and tar you may want to fetch draft-0.05a.tar.Z, otherwise the file README mentions all files which are in this archive. -- Other users send a mail to listserv@dhdurz1.bitnet with only one line in it: GET DVISTD PACKAGE You will receive all files by email. [[ Don, how do I transport it to ymir? Shall I send you a VMS shar? ]] Enjoy -- and many thanks to all contributors, see ACKNOWLEDGEMENTS below :-) -- Joachim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: xitijsch@ddathd21.bitnet Secretary of TUG DVI standards committee ---------------- Change log entry for draft 0.05a (and for 0.04c) follows: revision 5.1 locked by: schrod; date: 1991/08/06 15:12:07; author: schrod; state: Released; lines: +481 -213 draft 0.05a MAJOR CHANGES, DRIV-L POSTINGS OF THE LAST YEAR COLLECTED AND PARTLY INCORPORATED. EDITORIAL CHANGES: Did not use style option mf any more. This style option needed the NFSS, which is not in use at all sites. The draft must be TeXable with a `standard' LaTeX system. The `author' of the draft is now the TUG DVI Driver Standards Committee. Added distinction between standard text, explication, and rationale. The standard text is just the `pure,' definitive, short statement to be made. An explication pinpoints important consequences or implications of the standard text. Both are published in one document and are already finished. The rationale is an additional document describing why this standard text was chosen and names other possibilities discussed, but not included. The reason for the possibilities which were not included are usually outlined. The rationale is not written yet. All three parts will be within one \TeX{} source, although the rationale will be published as a separate document. (This conforms more to the standard documents I've read up to now, this structure may change again in the future.) Completed replacement of `should' with `shall' and `must.' (`should' is no good term in a standard...) There's still one `should': In the section on specials, on the definition when warnings should be issued. But this section needs clarification anyhow. Completed replacement of `DVI driver' with `DVI processor.' (At least on those occasions where not explicitely a device-driving program is meant.) Exchanged item `Magnification number' and `Resolution number' (now first) since the latter should be the canonical form by now. CHANGES OF CONTENTS: Abstract slightly rewritten, it conforms now more to usual conventions (see, e.g., Mark Wegman's paper in SIGPLAN, Vol. 21, No. 5). Commented out the trip test statement in the abstract. A trip test is not mentioned in the report. If it is mentioned it will be added back. Enhanced the introductionary paragraph to define a few terms (render, etc.) used later on. The term `DVI font' was defined nowhere and is therefore discarded. Just `font' is enough, since it concerns all fonts a DVI processor must handle. The same holds for `DVI character size,' it's renamed to `character size.' A paragraph was added to the explication of the section `character size' which states explicitely that the `character size' is the size of the glyph, not the TFM bounding box. This explication was demanded by Pierre MacKay on driv-l and generally aggreed on. The term `non-unit aspect ratio' does not exist. Renamed to `aspect ratio unequal to one.' Added explication which points out that no rule is set if the width or the height is less than 0pt. Added an explication that the maxdrift algorithm does not solve all problems with positioning. Mentioned a few problems. Added escape-clause (realization of functionality perhaps not possible due to device contraints) to the section `Objects off the page' (formerly named `Objects off of the page'). It was forgotten when accepting ammendment 06. Defined the term `special.' Says explicitely that level 0 does not define the meaning of any special. In section `Configuration' changed `without having to recompile the processor' to `without having to recompile or relink the processor.' Added explication what `etc.' in this paragraph means (`make as many things configurable as possible'). But this explication should be changed anyhow... In section `Minimum set of magnifications,' added explication which defines the term `magstep.' Moved the encouragement to support all possible magnifications to the explication, it's implicitely contained in the standards text. ACKNOWLEDGEMENTS: Small changes for correction of spelling errors and inserting better phrases (contributed by Nelson Beebe, Karl Berry, Friedrich Haubensak, Berthold Horn, Pierre MacKay, Doug McDonald, Arthur Ogawa, Greg(?) Platt, Liam Quin, and Thomas Reid). ---------------------------- revision 4.4 date: 1991/03/25 00:00:00; author: hosek; state: Released; lines: +20 -9 draft 0.04c Merged in ammendments 09 and 10. Ammendment topics: 09: definition of round() (S2.6.2) [introduces and defines pixel_round()] 10: change of max_drift correction (S2.6.2) [move only one pixel] Corrects some typographic errors of draft 0.04b, but again, this document is not TeXable. ---------------------------- ========================================================================= Date: Sat, 10 Aug 1991 11:08:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Virtual fonts -Today for the first time I read the virtual font business (Knuth's article). -Question I have: - - what's wrong with the idea of writing a dvi->dvi processor - which eliminates all the virtual fonts, resulting in a - virtual-font-free dvi file? - - Does anyone have other references I should read/follow up. Nothing's wrong with the preprocessor approach (other than inconvenience). In fact two already exist, dvicopy and dvivfdvi. The former is available at various TeX archives, the latter, as far as I know is only distributed by GUTenberg. -dh ========================================================================= Date: Wed, 14 Aug 1991 16:46:46 +0200 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Eberhard Mattes Subject: Empty pages I've heard that there are drivers out there, which omit blank pages. Is that allowed or is it illegal according to the dvi drivers standard? Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) ========================================================================= Date: Wed, 14 Aug 1991 11:25:37 MDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: Re: Empty pages In-Reply-To: Your message of Wed, 14 Aug 1991 16:46:46 +0200 My drivers do not omit blank pages, and I would view it as an error to do so. Such pages are rare in TeX output, and if they are there, were created for a reason, and therefore must be preserved. ======================================================================== 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@math.utah.edu ======================================================================== ========================================================================= Date: Thu, 15 Aug 1991 08:32:04 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Jerry Leichter Subject: re: Empty pages I absolutely agree with Nelson Beebe: A driver has no business trying to "improve" the user's output by supressing blank pages. If they are there, either it's because (a) I wanted them there (so that, for example, I could do two-side printing without having to shuffle through the output to insert a blank sheet so that a chapter really DOES begin on a recto page) or (b) I have a bug in my TeX code, in which case I want to know about it and fix it. In any case, for a printer with real two-sided printing - and they are no longer a rarity - leaving out a blank page could completely destroy a carefully arranged file. -- Jerry ========================================================================= Date: Thu, 15 Aug 1991 20:24:00 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Thomas Reid Subject: re: Empty pages In-Reply-To: Message of Thu, 15 Aug 1991 08:32:04 EDT from On Thu, 15 Aug 1991 08:32:04 EDT Jerry Leichter said: >I absolutely agree with Nelson Beebe: A driver has no business trying to >"improve" the user's output by supressing blank pages. If they are there, >either it's because (a) I wanted them there (so that, for example, I could >do two-side printing without having to shuffle through the output to insert >a blank sheet so that a chapter really DOES begin on a recto page) or (b) I >have a bug in my TeX code, in which case I want to know about it and fix it. > >In any case, for a printer with real two-sided printing - and they are no >longer a rarity - leaving out a blank page could completely destroy a carefully >arranged file. > -- Jerry At this point, I agree with Nelson and Jerry that, as a general rule, blank pages should be printed (at least by default). Jerry's reasons above are all valid. However, there are [possibly] some situations where it may be desirable to suppress blank pages: o Some time ago we discussed global options. One proposed method was to have all global options on a page by themselves. If this method is adopted, the page would otherwise be blank and should never be be printed. (Of course, if one of the other approaches is adopted, then this point is no longer an issue.) o If some TeX macros format a document for duplex printing by inserting blank pages at certain times (as Jerry mentions), it might be desirable to suppress the blank pages if the document is printed on a simple printer. (This could be done by giving the user an option to include to suppress the pages.) One problem with this is: What is a blank page? A page created by \null \vfill \eject with non-zero values for \hoffset and/or \voffset will produce a DVI file with various combinations of DOWNs, RIGHTs, PUSHes, and POPs. The page will not, however, contain any SET_nnn instructions. What if the page contains, in addition to some possible DOWN, etc. commands, a special to pull a sheet from a secondary tray? Well, this is a page of another color. It is probably meant to serve as a marker sheet between different sections. It has no marks; yet it must remain. The gain from suppressing blank pages under this condition (savings of paper) seems relatively minor in contrast to the potential complications from defining blank pages. I would favor always printing these pages. Besides, there are other ways of indicating that a page is a recto or verso page which do not involve putting blank pages in the DVI file. I have implemented one technique which I will describe if there is interest. Can anyone else think of conditions which would make suppression of blank pages desirable? ---Tom Reid ========================================================================= Date: Wed, 21 Aug 1991 12:13:28 +0200 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Eberhard Mattes Subject: Empty pages Tom Reid said: > Can anyone else think of conditions which would make suppression of blank > pages desirable? I can't. But I can think of reasons (bugs) why a driver could omit blank pages: Once upon a time I worked with a computer which used CR to end lines. Printers had to be configured to translate that CR to CR/LF. Unfortunately, some printers ignored CR at the beginning of the line (when the carriage is already returned), so it wasn't translated to CR/LF and one had to print a space and a CR to create an empty line. Maybe there are some printers which ignore FF after a blank page. Of course, a dvi driver should take care of this problem. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) ========================================================================= Date: Wed, 21 Aug 1991 13:26:18 MESZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Joachim Schrod Subject: Re: Empty pages In-Reply-To: <9108211017.AA13071@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from "Eberhard Mattes" at Aug 21, 91 12:13 pm Eberhard Mattes wrote: > Maybe there are some printers which ignore FF after a blank page. Yes. The HP LaserJet series. And all full compatibles. -- Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany ========================================================================= Date: Fri, 23 Aug 1991 15:06:06 +0200 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Eberhard Mattes Subject: Empty pages In-Reply-To: Joachim Schrod's message of Wed, 21 Aug 1991 13:26:18 MESZ <9108211131.AB05773@azu.informatik.uni-stuttgart.de> > > Maybe there are some printers which ignore FF after a blank page. > Yes. The HP LaserJet series. And all full compatibles. Hewlett Packard: LaserJet III Technical Reference Manual, p. 6-16: FF - Form Feed Advances the current active position to the same horizontal position at the top of the text area on the next page. **** - Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) ========================================================================= Date: Fri, 23 Aug 1991 16:26:45 MESZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Joachim Schrod Subject: Re: Empty pages In-Reply-To: <9108231325.AA15841@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>; from "Eberhard Mattes" at Aug 23, 91 3:06 pm Eberhard Mattes wrote: > > > > Maybe there are some printers which ignore FF after a blank page. > > Yes. The HP LaserJet series. And all full compatibles. > > Hewlett Packard: LaserJet III Technical Reference Manual, p. 6-16: > > FF - Form Feed Advances the current active position to the same horizontal > position at the top of the text area on the next page. > **** Manuals are nice, but empirical experiences, too :-) The following machines I had in direct access: HP LJ IIID -- single FF == eject HP LJ II -- single FF ignored Kyocera F-1010 -- single FF ignored Kyocera F-1000 -- single FF ignored Kyocera F-2000 -- single FF ignored Anybody interested in the results on a HP LJ IIP (which I have at home) or a Sharp? Moral: Don't trust it... -- Joachim // PLEASE NOTE CHANGE OF EMAIL ADDRESS !! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany