========================================================================= Date: Sun, 19 May 91 12:42:05 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: [ELISABET@MAX.U.WASHINGTON.EDU: note from Dan Karron on Netherlands UMFT program] Possibly some good considerations here for future iterations of the DRIVER standard Date: Fri, 26 Apr 91 16:22 PDT From: ELISABET@MAX.U.WASHINGTON.EDU Subject: note from Dan Karron on Netherlands UMFT program To: mackay@CS.WASHINGTON.EDU X-Envelope-To: mackay@CS.WASHINGTON.EDU X-Vms-To: MACKAY From: IN%"karron@CMCL2.NYU.EDU" 26-APR-1991 13:58 To: ELISABET@MAX.U.WASHINGTON.EDU CC: Subj: umft Received: from mcclb0.med.nyu.edu by MAX.U.WASHINGTON.EDU; Fri, 26 Apr 91 13:58 PDT Received: from karron.med.nyu.edu by MCCLB0.MED.NYU.EDU with PMDF#10421; Fri, 26 Apr 1991 16:59 EDT Received: by karron.med.nyu.edu (5.52/890607.SGI.DBK2) (for @mcclb0.med.nyu.edu:ELISABET@max.u.washington.edu) id AA27316; Fri, 26 Apr 91 17:11:42 EDT Date: Fri, 26 Apr 91 17:11:42 EDT From: karron@karron.med.nyu.edu Subject: umft To: ELISABET@MAX.U.WASHINGTON.EDU Reply-to: karron@CMCL2.NYU.EDU Message-id: <9104262111.AA27316@karron.med.nyu.edu> X-Envelope-to: ELISABET It is a really good idea, but it has too many hooks from the boys in the netherlands. It should take the black art out of making fonts. I will integrate in into the MakeTeXPK script. The main idea is that the algorithm for searching for fonts needs to be updated/replaced. The first call for a particular font should 1) if that font is there, and you can read it, great, go ahead I use the new unix access() call, which reports about whether it exists, and what not. 2) If that font is not there, you can do three things: 2.1) barf and abort, or use a zero sized font after a diagnostic. 2.2) look around for a 2.2.1) gf font of the same size 2.2.2.1) look around for different sized fonts 2.2.2.1.1) for each different sized font, try pk then gf 3) go ahead and make the font or 3.1) send a note to the tex administrator (guru) to make that font in the dead of night. These options should be sett able from a command line option, an environment var, or a compiled int default. All dvi drivers should have these options. You also need to define how many magsteps up and down to look for a font. Also, you need to allow for a sloppy install where the fonts are not exactly where you expect them, so the algorithm can search down from the TEXFONT dir to subdirs. Cheers! dan. | karron@nyu.edu (e-mail alias ) Dan Karron, Research Associate | | Phone: 212 263 5210 Fax: 212 263 7190 New York University Medical Center | | 560 First Avenue Digital Pager <1> (212) 397 9330 | | New York, New York 10016 <2> 10896 <3> | ========================================================================= Date: Mon, 20 May 91 09:27:12 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: [ELISABET@MAX.U.WASHINGTON.EDU: note from Dan Karron on Netherlands UMFT program] In-Reply-To: Pierre MacKay's message of Sun, 19 May 91 12:42:05 -0700 <9105201133.AA02338@Sunburn.Stanford.EDU> DVIPS has, of course, all of these possibilities---everything is done through MakeTeXPK. -tom ========================================================================= Date: Mon, 20 May 91 15:43:11 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: response to a message sent to INFO-TeX In-Reply-To: "Teresa A. Ehling"'s message of Wed, 01 May 91 21:34:28 EDT <7CFA2E7D000088BF@Post-Office.UH.EDU> Although the University of Washington had a large part in the development and dissemination of at least one version of dvi2ps, the UnixTeX distribution---still managed from the University of Washington, no longer does anything more than pass it on. We do not feel we can support it for precisely the reasons intimated in your message. It is impossible to know how many versions there are---all pretty good, and most with special and desirable features, but seriously out of phase with one another. We have therefore decided to put what little effort we can spare behind the continuing support and development of Stefan v. Bechtolsheim's TeXPS. One reason is that Stefan, during the time when he could afford to work intensively at it, was in close touch with the TeX Users Group driver standards committee. The relationship with this committee is rather indeterminate in the case of many otherwise satisfactory versions of dvi2ps. Drivers from Nelson Beebe's collection are associated with the work on this committee, and Tom Rokicki, who produces dvips is one of the most important contributors to the developing standard. More than anything else, I believe that you should consider this relationship with the driver standards committee. (There is certainly room for more than one driver, so long as the basics underlying the code are consistent.) Karl Berry's work on font-naming conventions in also an important part of the driver standard effort. For information about the standard, you might get in touch with Thomas Reid (X066TR%TAMVM1.BITNET) or DHOSEK@YMIR.CLAREMONT.EDU ========================================================================= Date: Wed, 22 May 91 12:11:19 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Karl Berry Subject: reading the dvi file One thing I do not see addressed in the DVI standard is the issue of actually reading the DVI file -- whether drivers are allowed to require the DVI file be seekable, i.e., that cur_pos and set_pos can be implemented. (Maybe I'm just missing this.) The Unix utility dviselect can now output a dvi file on stdout; the next release of web2c will give this capability to TeX itself (probably). However, no drivers that I am aware of can actually read from a pipe; they all want to read the end of the file first. Perhaps the standard should discuss this. karl@cs.umb.edu ========================================================================= Date: Wed, 22 May 91 18:58:44 MSZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: reading the dvi file Karl Berry wrote: > One thing I do not see addressed in the DVI standard is the issue of > actually reading the DVI file -- whether drivers are allowed to require > the DVI file be seekable, i.e., that cur_pos and set_pos can be > implemented. (Maybe I'm just missing this.) > > The Unix utility dviselect can now output a dvi file on stdout; the next > release of web2c will give this capability to TeX itself (probably). > However, no drivers that I am aware of can actually read from a pipe; > they all want to read the end of the file first. I know a few. > Perhaps the standard should discuss this. Yes, but not in level 0. A level 0 compliant driver may choose to demand complete DVI files. It's not a basic feature we need under all circumstances. But I don't know now, in which standard tier to place it... Any suggestions? ``Additional Bells and Whistles for Robust Drivers'' or such? -- Joachim ========================================================================= Date: Wed, 22 May 91 16:51:20 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: reading the dvi file In-Reply-To: Your message of Wed, 22 May 91 12:11:19 EDT Because users frequently wish to process only selected pages of a dvi file, and because the postamble contains the summary of font usage, I feel that it is vital for performance reasons that a dvi driver be able to use random positioning in the dvi file. Some drivers that permit receiving the .dvi file from a pipe, which is not seekable, just copy their stdin to a scratch file. My 3.0 drivers check for this case, and abort if they cannot seek on stdin (they CAN if you do "dvifoo Sender: The TUG DVI driver standards discussion list From: Stephan Bechtolsheim Subject: reading the dvi file In-Reply-To: "Nelson H.F. Beebe"'s message of Wed, 22 May 91 16:51:20 MDT <9105222254.AA21157@arthur.cs.purdue.edu> I don't think it's for a level 0 standard necessary to read from stdin, but in general it's so easy to add (copy to scratch file), that drivers should have it at level x, x > 0. 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, 22 May 91 16:12:58 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: dvi files, scratch files, etc. I don't think drivers should be required to work on non-seekable input for two reasons: - Where do you put the (arbitrarily large) input dvi file? /tmp? Just another thing that can fail; just another thing that needs to be set up system to system. - If you're going to be creating that scratch file anyway, why not just like TeX do it, since TeX does it anyway? - Said functionality doesn't buy you anything. I don't consider using tex -createoutputtostdout foo | dvips -readstandardin to be preferable to tex foo ; dvips foo This whole issue of reading standard in/writing standard out bugs me. It's silly, system-dependent, and virtually useless. Why don't we discuss something that will do people some good, like a standard for specials for graphics inclusions? Or virtually anything else? Here's something. I think dvi drivers should be required, when not creating just a bitmap, to generate the output in the same order as the characters and rules came in in the dvi file---this way specials can be used to specify certain characteristics (such as color or rotation or whatnot) without having to worry about the driver reordering things. -tom (Sorry to be such a grouch.) ========================================================================= Date: Wed, 22 May 91 19:10:47 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Thomas Reid Subject: Re: dvi files, scratch files, etc. In-Reply-To: Message of Wed, 22 May 91 16:12:58 -0700 from On Wed, 22 May 91 16:12:58 -0700 Tomas G. Rokicki said: >I don't think drivers should be required to work on non-seekable input >for two reasons: > > - ... > >This whole issue of reading standard in/writing standard out bugs me. >It's silly, system-dependent, and virtually useless. Why don't we >discuss something that will do people some good, like a standard for >specials for graphics inclusions? Or virtually anything else? I agree with Tom Rokicki on this. To his reasons, I would also add: - The normal reason for piping output from one program into another is to allow the two programs to "run" concurrently. If DVI drivers just copied stdin to a temp file so that they could seek on the temp file, then the *real* work of the driver couldn't begin until TeX finished. Thus, the driver is not really "running" (ie, it is not performing the overall intended function of the driver), it's just hanging around in the system occasionally stealing cycles from TeX so that it can write TeX's output to a temp file. >Here's something. I think dvi drivers should be required, when >not creating just a bitmap, to generate the output in the same order >as the characters and rules came in in the dvi file---this way specials >can be used to specify certain characteristics (such as color or >rotation or whatnot) without having to worry about the driver reordering >things. I strongly *disagree* with this, however! The proper way to ensure consistency in how specials are processed is to properly define the scope of the special. (This topic was covered quite some time ago on this list.) Further, the interaction between the special and other DVI commands (including other specials) within the scope of the special must be clearly defined; the author of a DVI driver *must* have the freedom to support the codes in a manner which is most efficient for the device. This is a device-dependent issue. One reason why I object to this so strongly is that it would have serious impact on my driver: My driver has an option to impose pages from the DVI file into booklets. This involves printing two 8 1/2" by 5 1/2" pages in landscape on the front and two pages in *inverse landscape* on the back of each sheet. At the level of code I generate for the printer, "inverse landscape" must be faked by printing the strings backwards using "landscape" fonts which have simply have the characters rotated by 180 degrees. If I were required to preserve order, then I would have to position each character individually. This would not allow me write as many characters per page as are stipulated in the level 0 standard. However, a stronger objection to this requirement is that you specifically exempt things that are bitmapped. Well, bitmapping is a device-dependent feature: For some devices, fonts might always be bitmapped; for others, never. For still others, the decision to bitmap or not might be based on the specific font used or other criteria. With my driver, fonts are bitmapped if they are not resident on the printer. A printer at one location might have some fonts resident on it while a printer at another place might not have them. The decision on whether or not to bitmap rules is based on the number of rules on the page. Thus, exempting things that are bitmapped will cause different results to be obtained from printing the same DVI file on different printers or processing the DVI file with drivers for different kinds of printers. This is hardly something that we'd want from a Device Independent file! Further, changes made in the TeX source (such as using a different font or adding more rules) could cause results which are largely unxepected. ---Tom Reid ========================================================================= Date: Thu, 23 May 91 12:10:54 MSZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: dvi files, scratch files, etc. Tomas G. Rokicki wrote: > This whole issue of reading standard in/writing standard out bugs me. > It's silly, system-dependent, and virtually useless. Reading from stdin is useless? No, see below. But silly? Hm, I would say ``not appropriate'' ;-) > Why don't we > discuss something that will do people some good, like a standard for > specials for graphics inclusions? Or virtually anything else? YES!!!!! > Here's something. I think dvi drivers should be required, when > not creating just a bitmap, to generate the output in the same order > as the characters and rules came in in the dvi file---this way specials > can be used to specify certain characteristics (such as color or > rotation or whatnot) without having to worry about the driver reordering > things. IMHO no; we should have a definition of scoping as discussed earlier in this list. Within a scope characters may be juggled around freely. But one last comment to the stdin discussion: It's a special case of a general issue: How to cope with incomplete DVI files. There are TeX systems which do not handle interrupts properly and leave an incomplete DVI file -- but with an high quality DVI driver I want to have a look at this DVI file. So: why, for heavens sake, must drivers copy something to a temporary file? A simple way to do it: 1. If a DVI file is not seekable one may not skip arbitrarly backwards. (Let's say, just within a buffer of fixed size; if the wanted page is there, ok; otherwise bang.) Of course, one may arbitrarly skip forwards. This is still useful if a large DVI file is to be written and one wants to have a look at the start while TeX is still running. Users may choose to look at them one after the other. (Note that I think that this feature is most useful for previews!) 2. If the DVI file is seekable but is incomplete (i.e., has a correct preamble and no postamble) a virtual postamble is build on the fly while reading the DVI file from front (and while producing the output, of course!). This virtual postamble covers all pages read up to now. (In fact, in previews one often wants to have an additional directory of the last seen $n$ pages because the probability of demanding them again is high.) That means searching and skipping in these pages is fast and easy. Searching and skipping in later pages is of course slower as one really have to read them. But -- better than nothing. Easy. To emphasize it again: Nothing for level 0, but something for later. -- Joachim ========================================================================= Date: Thu, 23 May 91 12:33:54 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: dvi files, scratch files, etc. In-Reply-To: Thomas Reid's message of Wed, 22 May 91 19:10:47 CDT <9105230121.AA03935@Sunburn.Stanford.EDU> (I say) >>Here's something. I think dvi drivers should be required, when >>not creating just a bitmap, to generate the output in the same order (Tom Reid says) >I strongly *disagree* with this, however! The proper way to ensure >consistency in how specials are processed is to properly define the >scope of the special. (This topic was covered quite some time ago on >this list.) I definitely agree with this---and while the topic was covered, it was most assuredly not agreed upon. And I agree with the other issues that Tom Reid raises. I should have rephrased things. First, when I say `create a bitmap', I'm referring to all of those drivers that create a large bitmap in memory and then send just the bits to the driver---these drivers actually render, and thus are responsible for the specials themselves. And when I referred to ordering, it was precisely so specials are scoped properly, something that should be done by a precise definition of those specials. Nelson Beebe wrote up a document on specials that he was kind enough to share with me, and I made some rather extensive comments back. Since I don't have permission to redistribute Nelson's document, and since my comments are based on that document, I can't share them to solicit comments. So I don't know how to proceed on these `special' issues. -tom