========================================================================= Date: Mon, 8 Jan 90 22:09: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: DVI file limitations [OK, we've had enough vacation, and as those on the list a year or more know, January is my traditional time to start rattling cages and pushing ideas through...] Here are some specifications for the outer limits on DVI files which drivers should be able to handle: font numbers: 0-255 (DVI can in theory have more, but this is sufficient for most applications. Remember, these are minimum standards.) distinct fonts: 128 (will this be enough? we might want to indicate a number of fonts/page as well) characters/font: 256 (that'll cover all Western character sets) total rules/page: ??? distinct characters/page: ??? total characters/page: ??? (I think that some research on typical values might be helpful for this) maximum character horizontal size: 600pt maximum character vertical size: 800pt (this is almost a full (European) page) maximum page horizontal size: ??? maximum page vertical size: ??? (Is there any reason to limit these?) I'm sure I've missed some. I'd appreciate seeing additions to this list and comments on values proposed. Also, if anyone would care to keep some statistics on values for total rules and character per page, I would appreciate it. -dh ========================================================================= Date: Tue, 9 Jan 90 10:29:01 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: DVI file limitations Don has written in his mail: Here are some specifications for the outer limits on DVI files which drivers should be able to handle: font numbers: 0-255 (DVI can in theory have more, but this is sufficient for most applications. Remember, these are minimum standards.) distinct fonts: 128 (will this be enough? we might want to indicate a number of fonts/page as well) characters/font: 256 (that'll cover all Western character sets) I don't know if my English is so bad -- but I have thought that these are requirements and not limits. The limits are given in the DVI specification. But even as requirements I must contradict: Why only font numbers in the range 0--255? Just because this saves three bytes in the storage? I think we should not think for such low level implementation details as ``I want to store fonts in an array [0..max_font_number-1] ...'' or something like this (besides, it's really questionable if this would be a good implementation). What does ``128 different fonts'' mean? 128 different TeX fonts in a document or 128 different TeX fonts in the part which will be output? The last situation is as a limit ok; but if someone has a DVI file with many, many fonts he should be able to output it in parts. Therefore: no limit on the amount of fonts in a DVI file. What does ``fonts per page'' mean? TeX fonts? Device fonts? If a device is not able to handle more than n fonts per page (e.g. the HP LaserJet+) the driver must combine the chars from different TeX fonts into a device (download) font. This must be done anyway if the device is not capable of collecting the required amount of chars in one download font (e.g. as in some ``HP-LJ-compatible'' devices). Or they must be inserted as rasters. Why only 256 different characters in a font? As many as storage allows... Japanese LaTeX already exists, we should make a standard for the whole TeX community, not only for the ``Western part of the world.'' (Japan is in the West of you anyway -- we in West Germany are in the East and perhaps farer away.) But great that there is activity on the list again... Joachim ========================================================================= Date: Tue, 9 Jan 90 11:50:00 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Dimitri Vulis Subject: DVI file limitations I strongly object to the 256 chars/font limit. I am also disappointed to see no mention of the 'virtual fonts' feature endorsed by Knuth. Cheers, Dimitri Vulis Department of Mathematics City University of New York Graduate Center ========================================================================= Date: Tue, 9 Jan 90 12:37:37 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Ralph Youngen Subject: RE: DVI file limitations I'm also a bit confused if Don's suggestions were ``limits'' (implying a maximal situation) or ``requirements'' (implying minimal). I suspect they were meant as ``requirements''. I seem to remember some time ago that someone suggested we take a tiered approach, where we could define a certain set of requirements at each level that a driver would have to meet in order to be classified as a ``Class n'' driver. Perhaps these values could be taken to be the requirements for a minimal (Class 0?) DVI driver. There was also a mention of ``virtual fonts'' in a recent message. I have just learned that Knuth has done some rethinking of virtual fonts. A message should appear on TEXHAX from him shortly (may already be there by now). VERY interesting stuff. Check it out... Ralph Youngen, AMS REY@MATH.AMS.COM (Internet) ------- ========================================================================= Date: Tue, 9 Jan 90 13:50:01 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: DVI driver limits In-Reply-To: Specification of limits is going to be troublesome. Here are some comments: font numbers: TeX uses values in 0..255 (see sections 11 and 12 of Tex: The Program, Volume B of Computers and Typesetting), but the DVI format is designed to support 32-bit font numbers. Drivers should therefore support at least 0..255. My drivers currently have smaller limits which vary according to the output device; those limits can easily be raised, or better, their arrays made dynamic. distinct fonts: TeX uses no more than font_max (Section 11, Volume B); this is 75 in the .web file, but we have recently increased it to 120, which is sufficient to allow a style file redefining all fonts to be read into a LaTeX document. distinct fonts/page: There is no good reason why this needs to be different than the number of fonts supported; however, some devices (e.g. HP LaserJet) impose a smaller limit. My drivers deal with them by sending bitmaps instead of characters when that limit is reached. characters/font: TeX can use up to 256 (see lc and ec in Sections 540 and 565). DVI drivers should support that many, even though many output devices support fewer than 256 characters/font. total rules/page: I can think of no good reason why a driver would have to limit this value, nor have I yet encountered any device that has such a limit. distinct characters/page: I can think of no good reason why a driver would have to limit this value, nor have I yet encountered any device that has such a limit. total characters/page: I can think of no good reason why a driver would have to limit this value, nor have I yet encountered any device that has such a limit. maximum character horizontal size: maximum character vertical size: METAFONT uses 32-bit integers for each of these, but of course never uses all of those bits. A bitmap for a 5333 line/inch device could need up to 10000 dots horizontally and vertical for some characters in a 72pt font. A 2400 dpi printer could need 5000 dots each way. My drivers impose a limit of 2000 dots, but I can probably replace statically allocated arrays that depend on those limits with dynamically allocated ones that match whatever is the limits in the font file are. maximum page horizontal size: maximum page vertical size: TeX's use of scaled coordinates imposes a limit of 2^14 pt = 18.89ft = 5.758m. This is not big enough to format billboard advertising directly, but that is surely printed with optical magnification from smaller sizes anyway. Some output devices impose limits matching either the coordinate integer size (usually 16 bits, for -32768 .. +32767 pixels), or the page size (e.g. HP LaserJet has various limits that depend on the paper tray selected). My drivers are normally compiled with a COORDINATE type == 16-bit integer, but have been carefully designed to allow that to be changed (in only one place) to a larger data type if needed. My 3.0 DVI driver development has completely eliminated any restriction (other than that imposed by 16-bit values) on paper sizes; for dot-matrix printers, the page bitmap is constructed in as many strips as are necessary, subject to available memory. Paper sizes, names, margins, and clipping requirements can be specified in configuration files external to the driver. maximum open font files: This limit is imposed by the operating system, and on some systems, further restricted by resource quotas and by the number of files already open by other processes in the current job; these vary between users (e.g. VAX VMS). In most cases, the limit is quite small (5 .. 20), so drivers have to deal with this by closing least-used files, and reopening them later. ------- ========================================================================= Date: Tue, 9 Jan 90 12:48: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: DVI driver *requirements* Yep. I used the wrong word. It should have meant to imply that those items were minimum _requirements_. Not maximal limits. There should be _no_ upper bounds (other than those implicit in the DVI format itself). To defend a few specific points: character codes 0..255 The jTeX described in TUGboat produces DVI files that fall within these limits. Another Japanee TeX does not. However, do you _really_ believe that it's necessary for *all* drivers to be able to support Japanese, Chinese, and Korean output? Of course some of the objections might have been based in my poor wording of what I was doing. distinct fonts 128 This should probably be for that portion of the document actually being output. Again these are minimum standards. Also, if you take a look around, it shouldn't be too difficult to find printers which can't even handle this much (I wish everyone on this list could read the docs for the Xerox 2700/3700/4045 printers to see the sort of difficulties we're up against. Incidentally, when I refer to fonts, characters, etc., that refers to objects in the DVI file. 128 distinct device fonts is not possible on most systems, but through creative output generation this limitation can be overcome. Also, on the topic of font numbers, 0..255 is the largest range that standard TeX will output. I think that setting minimum values at TeX's maximums (whenever practical) is probably the most reasonable plan. On rules, characters, etc. per page, Nelson Beebe says, "I can think of no good reason why a driver would have to limit this value, nor have I yet encountered any device that has such a limit." I however, have encountered such devices. Xerox makes them. Xerox laser printers impose some rather severe limitations on various items in the print process (I hate to keep bringing Xerox up, but they're *so* guilty of making TeX-hostile laser printers, it's hard not to... perhaps Tom Reid, if he has the time, can share some of his experiences from writing TeXrox with us.) Looking forward to hearing more discussion on this. -dh ========================================================================= Date: Tue, 9 Jan 90 15:24:52 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: William LeFebvre Subject: Re: DVI driver *requirements* In-Reply-To: DHOSEK@hmcvax.claremont.edu's message of Tue, 9 Jan 90 12:48:00 PST Date: Tue, 9 Jan 90 12:48:00 PST From: DHOSEK@hmcvax.claremont.edu (I wish everyone on this list could read the docs for the Xerox 2700/3700/4045 printers to see the sort of difficulties we're up against. I've written programs that tried to deal with the 2700. You're right--- it imposes some very severe restrictions. I'd be glad to swap horror stories with anyone. :-) I first started with the 2700 model I. By comparison, the current model is very generous.... About the only nice thing you could say about the 2700 was "it makes a good line printer". And that's not even true anymore. William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University ========================================================================= Date: Wed, 10 Jan 90 10:19:02 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: RE: DVI file limitations (once again) OK, some more notes about realizations and problematic devices: maximum number of fonts/page or chars/page: Our driver family (10 members on 4 different operating systems) supports as many chars/page as the device allows (e.g. 3056 on HP LaserJet+ compatible devices; 16 device fonts/page with 191 chars). There are no limits on TeX fonts/page: We do not map TeX fonts to device fonts. Instead we collect used characters in device fonts. This has the advantage that we have fewer device font switches (most documents do not need many different chars) and that our drivers are (relative) easily adaptable to special device requirements. I strongly option that we do not handle the mapping of TeX fonts to download fonts as an identical mapping. Perhaps the other way will produce better drivers... problematic devices: Everybody talking of difficult devices should have a look at the HP DeskJet download fonts; Tom Rockicki has kindly sent us the documentation. Each character has a height of 50 dots, the baseline of all chars in a font is fixed, the reference point must not be within the character, the minimum horizontal escapement is the width of a character, download font space is limited to 128K in general, ... Some other machines of this kind around? Greetings Joachim ========================================================================= Date: Wed, 10 Jan 90 10:45:52 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: William LeFebvre Subject: RE: DVI file limitations (once again) In-Reply-To: XITIJSCH%ddathd21.bitnet@eecs.nwu.edu's message of Wed, 10 Jan 90 10:19:02 CST Date: Wed, 10 Jan 90 10:19:02 CST From: XITIJSCH%ddathd21.bitnet@eecs.nwu.edu Everybody talking of difficult devices should have a look at the HP DeskJet download fonts; Tom Rockicki has kindly sent us the documentation. Each character has a height of 50 dots, the baseline of all chars in a font is fixed, the reference point must not be within the character, the minimum horizontal escapement is the width of a character, download font space is limited to 128K in general, ... My understanding is that Rokicki's deskjet driver simply doesn't use the font capabilities at all (because they are too restrictive). He just builds a bitmap image of the page and prints that. That's kind of a last resort option, but on the 2700 not even THAT option is available. That's right---the 2700 cannot accept a page-sized bitmap for printing. My recollection is fuzzy, but I believe that it has no bitmap capabilities whatsoever.... William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University ========================================================================= Date: Wed, 10 Jan 90 20:49:10 MEZ Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Konrad Neuwirth Subject: RE: DVI file limitations (once again) In-Reply-To: Message of Wed, 10 Jan 90 10:45:52 CST from I have the DVI-driver for the DeskJet at hand (the amiga version), I can send a SMALL file to anybody interested (i mean, the bitmap output in an encoded format (ZOO and then XXencoded). konrad ========================================================================= Date: Wed, 10 Jan 90 12:03:56 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: DeskJet Yes, the Amiga DeskJet driver works by sending a bitmap (but of course massive optimization is done.) It may be possible to use the downloaded fonts, but it was a puzzle I decided not to tackle. On the LaserJet, device fonts and TeX fonts should definitely not have a 1:1 correspondence; it's too restrictive. -tom ========================================================================= Date: Wed, 10 Jan 90 14:51:19 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H.F. Beebe" Subject: HP DeskJet My 3.0 driver development contains a driver for the HP DeskJet inkjet printer. Like Tom Rokicki's driver, it produces a compressed page bitmap. The downloaded font support in the DeskJet is very limited, and also requires an extra memory cartridge; I don't plan to make use of that. The HPLJ II-P laser printer can be bought now for $995 on the discount market, making it only about $300 more than discount prices of the DeskJet. Since the difference is 4 pages minutes vs. a few minutes/page, serious TeX users should opt for the laser printer instead of the inkjet. ------- ========================================================================= Date: Wed, 10 Jan 90 15:04:00 PST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: DHOSEK@HMCVAX.BITNET Subject: 2700 series printers >My understanding is that Rokicki's deskjet driver simply doesn't use >the font capabilities at all (because they are too restrictive). He >just builds a bitmap image of the page and prints that. That's kind >of a last resort option, but on the 2700 not even THAT option is >available. That's right---the 2700 cannot accept a page-sized bitmap >for printing. My recollection is fuzzy, but I believe that it has no >bitmap capabilities whatsoever.... Depending on where you are in the 2700/3700/4045 hierarchy, you _may_ be able to send bitmaps. Page size bitmaps are silly to use, however. A well-written driver will minimize the bitmap data to be sent by attempting to send bitmaps for just those parts of the page which actually have printing. Incidentally, the 2700etc. printers only allow font downloading between jobs. 87xx/97xx/4050 printers do not allow font downloading at all except in special circumstances for permanent installation on the printer's disk. -dh ========================================================================= Date: Thu, 11 Jan 90 04:18:43 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: UCIR001%FRORS31.BITNET@CUNYVM.CUNY.EDU Subject: DRIVERs standard The following maximum values used by our XEROX 9790 driver are considered as minimum requirements: ARIANE : Total rules/page = 1K Total characters/page = 20K Inversely, 64 Fonts/page have never been reached, but 128 Fonts/document have been. Bernard GAULLE ========================================================================= Date: Sun, 14 Jan 90 13:00:16 -0800 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Pierre MacKay Subject: DVI file limitations In-Reply-To: Ralph Youngen's message of Tue, 9 Jan 90 12:37:37 CST <9001091840.AA16840@june.cs.washington.edu> I would endorse Ralph Youngen's idea to have a tiered approach. While most of us who are in a position to experiment have access to pretty generous computing capabilities, not all users do, and we must somehow mediate between the more restricted user environment and the environment that we can legitimately hope that just about everybody will have in five years' time. It is probably quite important that we do not specify (AS A MINIMUM) something so demanding that it will put a large number of users beyond the pale of legitimacy. So I would endorse the notion of compliance levels rather strongly. Pierre ========================================================================= Date: Wed, 17 Jan 90 10:57:57 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: HP DeskJet Excuse me that I use this list for things not concerning driver standards but here are the people who may help me: I'm looking for the mode_def's for the HP DeskJet. Anyone out there? (I have started to implement a download driver in my free evening time.) Please report them directly to me as they should not burden the list. Thank you very much Joachim ========================================================================= Date: Sun, 28 Jan 90 15:48:00 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Dimitri Vulis Subject: Re: Character codes 0..255 >The jTeX described in TUGboat produces DVI files that fall within these >limits. Another Japanese TeX does not. However, do you _really_ believe that >it's necessary for *all* drivers to be able to support Japanese, Chinese, and >Korean output? Of course some of the objections might have been biased in my >poor wording of what I was doing. I'd like to comment on this in light of the recent article by Donald Knuth on virtual fonts that appeared at long last in TeXhax. I read the following into Knuth's remark on "mixing oldstyle digits with a caps-and-small-caps alphabet": 1) In the old days, almost every good typeface had a complete set of small caps and hanging digits. 2) With CM, we're limited to hanging digits in math italics and to whatever small caps fonts there are. If you want to have old digits mixed with, say, 17-point demibold roman, you have to conjure 17-point demibold math italics. CSC fonts waste space because they're identical to the 'uplow' variant except for the few lowercase letters (some the ligs:). 3) With virtual fonts, the following trick is possible: for each CM variant for which small caps and/or hanging digits make sence, we put the hanging digits and the small caps into some position well above 128 (say, hanging 0 become "230 and small cap a becomes "361). 4) To access the characters from this font, we create up to 4 (!) TFM files for TeX (cf. Knuth paper). One will perform no character substitutions; one will map lowercase letters into their small cap variants, if appropriate; one will map the ranging digits into the hanging digits; and one will do both. (They will be generated iff caps and/or h.d. make sence and are present in the font.) So, depending on which convention you want to follow in your text with respect to lowercase and digits, you reference the appropriate TFM in your DVI file, but there is no need to waste disk space on duplicate rasters. Likewise, the problem of accented letters will be solved by the virtual fonts used in conjunction with 8-bit TeX. (There is a religious question of whether the font should contain individually accented letters or whether we can survive with floating accents; I have an opinion about this, but I'm an aspiring cryptologist and not a font designer, and since so many prominent people feel that the answer is "yes", I shall keep my opinion to myself and stipulate that they're right.) Recall that many people (not only Chinese and Korean, but also European) use characters 128--255 to represent their national characters that aren't in ASCII (mostly Latin characters with diacritical marks). The 2 problems are 1) the total set of such characters (from Icelandic to Turkish to Lithuanian) exceeds 128, 2) there is (only partly because of 1) no uniform convention for the correspondence between these characters and the numbers 128--255. There are the ISO standards 8859-n which specify several such mappings. The reason for having several is that all of them won't fit together. So, Latin alphabet #1 covers Western European languages including Icelandic, but not Turkish; Latin #2 covers Eastern European languages; #5 covers Turkish, but not Icelandic; etc. Furthermore, both MS-DOS and the Mac assign some (different) meanings to characters >127 (these were established before ISO 8859-n's were adopted, so I'm not blaming anybody). For example, Knuth says "character 194 = Meta-B"; but to both an Icelander using Latin #1, and to a Romanian using #2, 194 is A+circumflex. To a Greek using the ELOT scheme, it's a Beta. To an IBM PC user using almost any code page setting, it's a line graphics symbol. On the other hand, "D5 is a dotless i to an IBM PC user with CP 850, and another line graphics symbol to a CP 437 user and \~O to a Turk who uses Latin #5 (and uses "FD for \i) or to a Western European; but to a Hungarian it's \H{O}! How do we deal with this? Approach 1. Use Latin Alphabet #1 and tell everyone else to stuff it. Approach 2. Put all the "reasonable" national Latin letters (definition: "reasonable"= occurring in any ISO Latin) into the large font. Use no translation for Latin #1-coded text; provide extra TFMs for 8-bit input coded according to other schemes (Dreaded question: how will TeX deal with multi-octet ISO 10646 input? :). Once again, have U+grave in "D9 and U+dot in, say, "1D9, and provide a TFM file that maps "D9 to "1D9 if the input is in Latin #2 (and remember to provide accented small caps! :). The implications of this to the Russian TeX project are also obvious (we will treat the Cyrillic letters that aren't Latin the same way we treat thorn, edh and thorn). CMCYR shares _lots_ of glyphs with CM and lends itself to exactly the same variations of parm file. Why not stuff everything in one big font file and let TeX pull out the appropriate subsets using v.f. I'd appreciate comments on this suggestion; my comment is that no one should be stuck with a device driver that can't handle this "large font" with more than 256 chars in it. At least, you might say that any driver that supports v.f. should also support > 256 chars per font. Dimitri Vulis Department of Mathematics City University of New York Graduate Center ========================================================================= Date: Mon, 29 Jan 90 22:08:27 CST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: W: Field "From:" duplicated. Last occurence was retained. Comments: Resent-From: Don Hosek Comments: Originally-From: lemaire@FRLRI61.BITNET From: Don Hosek I received the following on my UICVM account. Since we discussed the topic (albeit somewhat cursorily) last spring, and some people on the list are knowledgable on the topic, I've forwarded it there. -dh ---------------------+--------------------------------------------- Don Hosek | Internet: DHOSEK@HMCVAX.CLAREMONT.EDU Platt Campus Center | Bitnet: DHOSEK@HMCVAX.BITNET Harvey Mudd College* | Phone: 714-920-0655 Claremont, CA 91711 | >Please do not mail to U33297@UICVM.UIC.EDU ---------------------+--------------------------------------------- * Despite the address, I am actually at Pitzer College ----------------------------Original message---------------------------- We work on the following topic : the writing of TeX macros which allows color insertion. We were requested to get in touch with you by the president of Gutenberg (the french TeX users group) Bernard Gaulle. We use a \special command in order to include PostScript color code for few TeX macros. One of our TeX implementation works on the QMS colorscript model 10, the other on a Laserwriter. Then we try to extract classes of problems which imply classes of solutions. This leads to propose a minimal set of primitives solving the following problems : - action on a syntactic entity. Then we distinguish two sub-cases : - the coloring of the syntactic entity with type constructors like \begincolor and \endcolor - more complex actions : the color of a letter depends on close letters or depends on parameters specify the interaction between colors. For example, we suggest several macros for automatic shades of colors on strings. then, we code \arcenciel[text text ... text]. - action on a graphic entity (underlining, frame box, vector or arrow in a \picture environment) If you have some reflexion for eventual developments, they are welcomed. On the other hand, if you know persons working on this subject, could you transmit us their addresses. Benoit Lemaire & Christophe C\'erin Universit\'e de Paris Sud LRI bat 490 91405 Orsay-- France mailing address : cerin@lri.lri.fr or lemaire@FRLRI61.BITNET