========================================================================= Date: Mon, 12 Feb 90 17:12:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: DHOSEK@HMCVAX.BITNET Subject: Virtual fonts pre-processor For those of you who missed it in TeXhax: >Date: Tue, 23 Jan 90 23:08:00 GMT >From: Chris Thompson >Subject: VF files and DVI-to-DVI converters >Keywords: TeX, dvi files, virtual fonts Reading, in rapid succession, Don Knuth's specification of VF format (TeXhax #11-12) and the article by Stephan v. Bechtolsheim in TUGboat Vol.10 No.3 about DVI-to-DVI converters, I had the following thought. It would be possible to process a DVI file that contains references to virtual fonts, and generate another which contains no such references. Indeed, this can be done simply using the VF files, without even the need to read the TFM files for the non-virtual fonts referred to. Roughly, if the currently selected font is virtual, one replaces by {DVI from the VF file} & by {DVI ...} adjusting the font numbers carefully (reassigning font numbers is a standard trick in DVI-to-DVI processors). One also needs to check for the case, which will never arise in practice, in which the DVI from the VF file uses (or , , ) before w has been set locally. This isn't quite as good as putting support for VF files in the DVI-to-device program, because the command above should be treated as a character escapement, rather than white space, for the purposes of `DVItype-style pixel rounding'. (The effect is liable to be that one effectively gets `maxdrift = 0' for material set in the virtual font.) However, as a stopgap measure until all your favourite DVI drivers are enhanced to support VF files, such a program might be extremely useful. When Don says `I fully expect that all people who have implemented DVI drivers will ... be unable to resist installing a VF capability into their own software during the first few months of 1990', I fear his tongue must be in serious danger! Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk ========================================================================= Date: Wed, 14 Feb 90 10:45:43 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: VF fonts Concerning Don's remarks on VF and DVItoDVI: This is a very good idea, and it's even right for those who want to update their own drivers. With a DVItoDVI processor they may check their new code and the inclusion of this new code will yield less errors in a whole driver family. This is especially true if the DVI driver family is an object-oriented system, where the object ``DVI document'' now be redefined. There must must be a stack of such objects, the constructors and destructors are getting more complex, etc. Well I think too, that ``all people who have implemented DVI drivers will [...] be unable to resist installing a VF capability into their own software [...],'' even if I don't believe that this will be done ``during the first few months of 1990.'' But I don't know if they are doing it because they like the new format or just because they cannot ignore when Don Knuth is pushing a new font format... Joachim ========================================================================= Date: Sun, 25 Feb 90 23:51:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: DHOSEK@HMCVAX.CLAREMONT.EDU Subject: TUG90 Yes, it's that time of year again. This year, it looks like we weill have a panel discussion on the program starring ourselves. Everyone who will be attending should let me know as soon as possible (Tom Reid and Nelson Beebe need not respond ;-). Also, let me know when you'll be arriving in College Station since I'd like to get together with everybody as soon as possible. The format of our discussion will be: first as summary of where we stand (we WILL have a report for the meeting if it means only my opinions are represented). There will be a printed report distributed at the meeting (Tom, I presume we can print off the necessary copies at A&M during or just before the conference; correct me if I'm wrong). This will be followed by a question and answer session where we will respond to questions on why things are that way and say "we'll get to it sometime in the future" in response to most of the questions along the lines of "what about this?" Readers of comp.text (and the newly created comp.text.tex) will be aware that I have promised two things for the conference, and these are top priority: (1) the minimal requirements for a driver (2) graphics inclusion I will be sending notes off on both of these soon. -dh ========================================================================= Date: Mon, 26 Feb 90 00:56:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: DHOSEK@HMCVAX.CLAREMONT.EDU Subject: Minimum standard for DVI drivers The entirety of discussion on this topic is contained in the January logs for driv-l. Nobody indicated areas that they thought the minimum specs should be extended to, but we still have time to deal with that. Below is a summary of views on each of the items, with my proposals for the final standard. We'll listen to views for roughly two more weeks, then roughly two weeks later I will call for a vote from committee members (a list of who is officially a committee member will be posted later this week or sometime next week... I would like to make a few adjustments). Incidentally, committee membership is only a factor in voting. We welcome comments and contributions from all. font numbers: I suggested the range 0-255. Joachim Schrod felt that it was silly to restrict to this range since this would encourage poor coding practices and felt that we should require any font number to be accepted. Nelson Beebe noted that TeX will only create DVI files with 0-255, but DVI can have 32bit values. 0-255 was an acceptable minumum in his view. My suggestion: 0-255 is likely the range of font numbers that will appear in most DVI files found (except our dvitrip.dvi file to be created) drivers shouldn't restrict themselves to this range, but it is a good minimum to deal with. As a side note, all dvi commands should be correctly interpretted by the driver regardless of minimums like this. distinct DVI fonts [in section of document printed]: I suggested 128. The reason for 128 over 256 was due to printers like the Xerox 2700 and 8700 which allow no graphics in certain incarnations and highly restrictive font usage. Joachim had no problems with this minimum with the description ammended as it is here. Nelson noted that standard TeX has font_max at 75 and his site upped it to 120. Since it is unlikely that all fonts loaded will be used, I presume that he has no problem with 128. My suggestion: nobody seems to think 128 is too low. Anybody care to argue that it's too high? Bernard Gaulle has noted that Xerox 9790 runs at his institution have never exceeded 64 fonts / page, but have hit 128 fonts / job; I suppose this indicates that if worse comes to worst, one can print the file out a page at a time. distinct DVI fonts / page: Joachim made some comments on techniques to deal with restrictive devices (see his note of 9Jan90). Nelson felt there was no reason for this to be different than the previous number. My suggestion: We can deal with this item and the last in one of two ways: (a) the number of fonts/page should be the same as fonts/portion of document output and be a number around 64, or they should be different and this number should be ~64 the other around ~128. I lean toward the latter since it would encourage better handling of device characteristics. characters/font: I feel that 256 is adequate. Joachim and Dmitri Vulis objected to the 256 character limit to do concerns over support for Oriental (and otherwise) character sets. Nelson agreed that 256 was a good minimum. He also noted that some output devices had more stringent restrictions. My comments: Remember, these are the bare minimum requirements. There are _very_ few users "out there" who are dealing with fonts containing more than 256 characters. Even Saito's jTeX does not use fonts containing more than 256 characters (see his article in TB 8#2). total rules per page: Nelson didn't see why this restriction was necessary. Bernard reported that his site has found 1K to be adequate. My comments: the restriction is due to certain brain dead printers. total characters per page: Nelson had the same view here. Bernard reported that his site has found 20K to be adequate. My comments: PiCTeX could cause problems, but oh well. Anybody have any idea how many characters can be placed on a page with a 64K TeX? distinct characters per page: No comments here from anyone (except Nelson's ditto of his comments for the last two items). Do we want it to be the same as the above value? Remember the printers with no graphics capability. Perhaps somebody could do a statistical analysis on DVIs for a large number of documents. maximum character size: I proposed 600pt (h) by 800 pt (v) Nelson noted that his drivers have a limit of 2000x2000dots but he was willing to change that. Some comments on MF were also made. My comments: any objections to my stated minimum maximum size? minimum page size: My comment: Nelson made a whole bunch of comments which have led me to think that this is best defined as the largest paper size handled by the printer (making life hard for people who write DVI to drafting plotter programs). Other: Nelson suggested dealing with the issue of maximum open font files, but as he noted this is highly system-dependent and not really an issue for the standard. Looking forward to seeing your comments. -dh ========================================================================= Date: Mon, 26 Feb 90 01:24:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: DHOSEK@HMCVAX.CLAREMONT.EDU Subject: Graphics inclusion This is a big topic and we broached it last summer. From comments on the net, I gather that we need to permit it via two approaches: Approach #1: Short and simple. All necessary information for the driver appears in the \special command. Something like \special{include