========================================================================= Date: Wed, 1 Aug 90 10:57: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: Draft Proposal "Level 0" DVI Driver Standard Date: Tue, 01 Aug 5 10:0C CET From: NORBERT.SCHWARZ@RUBA.RZ.RUHR-UNI-BOCHUM.DBP.DE Subject: RE: Draft Proposal "Level 0" DVI Driver Standard To: DHOSEK@HMCVAX.CLAREMONT.EDU Dear Don, some remarks on "A Draft Proposal for the Level 0 DVI Driver Standard ..................................................................... to 2.2.2 DVI character size Are character sizes measured before or after rescaling by MAGNIFICATION NUMBER /or RESOLUTION ? Does this mean 20,000 characters times (600pt x 800pt) ? to 2.2.3 Number of DVI characters per page - There are devices (drivers), which are limited in the numbers of positioning commands. It is possible to put 20,000 characters on a single page, but not on random positions. - better: ... as many as 20,000 DIFFERENT (!) DVI characters to 2.6.4 Objects off of the page A rule is a single printable object, correct ? My opinion: Even a "Level 0 Driver" should print rules partially. to 3 Configuration In a standard there is a need of a exact(!) list which facilities may be configured externally. i.e "naming scheme of fonts" to 4.4 Missing fonts Only (solid) black rectangles are allowed ? Further (1) Has a "Level 0 Driver" the right to access TFM-files ? i.e. Have these to be present ? (2) Is it allowed to a "Level 0 Driver" to concatenate rules ? How are these counted ? (3) Missing: (a) A page selection method has to be present: - by (\count0) - by pagenumbers (paper) (b) Protocol - output of generation time of the DVI-file ------------------------------------------------------------------------ - Norbert Schwarz, Rechenzentrum Ruhr-Universitaet Bochum Norbert.Schwarz@RUBA.RZ.RUHR-UNI-BOCHUM.DBP.DE ========================================================================= Date: Wed, 1 Aug 90 17:57:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: Drivers standard From: Robin Fairbairns on LSL cluster Subject: Drivers standard My comments follow. However, I did have a certain amount of fantasy formatting the document. - since it uses \emergencystretch, it is plainly a TeX 3.0 file; this prompted me to acquire and install TeX 3.0 (though for my first printing I simply commented that line out); however, I *do* like your change file! - the line `\def\tensl¤\sl‡' causes my LaTeX to blow up in \begin¤document‡; I assume you're using some fancy new lfonts (M&S?) - perhaps it would have been a good idea to emphasise this in the intro to the article? I have no `technical' comments to make on the proposed standard. However, my involvement with DVI driver writing is limited to a rather small number of lines in Brian ¤H K‡'s LN03 driver, and no doubt if I went into the subject deeper I could root out something... One of the parts of my job is an (ISO) standards writer; looking at your document with that sort of eye to it, I was struck by the feeling that it didn't read much like a standard. Standards *specify*; the use of the word `should' in a standard introduces advisory text. I would suggest that you make the text specify in the ISO directives way: "A driver shall " I was struck by your misspelling of `algorithm'! Robin Robin Fairbairns, Senior Consultant, postmaster and general dogsbody Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Tel (+44) 223 420414; Fax (+44) 223 420044; Telex 817346 LSLCAM G Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk ========================================================================= Date: Thu, 2 Aug 90 11:00:15 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIKGUN@DDATHD21.BITNET Subject: pixel_round and fonts On Fri, 27 Jul 90 Thomas J. Reid sent a message concerning drift correction. If this has been covered in the meantime I apologize for bothering everybody again, but this morning my mailbox was not flooded by messages, and I must assume that some mail was lost due some malfunction of our bitnet connection. Sorry. But now into the details: In his examples Tom Reid found "three-pixel errors" on the character "m" in some fonts. When I tried to find out how that much of an error can come up I found that in our pk files for a 300 dpi write-white engine (mode_def ricoh_mmmmlxxx) the pixel width of the "m" was perfectly ok (namely 44 pixels for about 43.54 pixels which dvitype assumed), but for a 300 dpi write black engine (mode_def imagen) we had got an error of more than 2 (namely 46 pixels for the same tfm width). The difference between the fonts for with mode imagen and ricoh_... is that the imagen fonts were created back in July 1987, while the ricoh_... fonts were computed in August 1989. Thus I ran MF again and, what wonder, now the horizontal escapement value for "m" in cmbx10 scaled \magstephalf comes out with 44 Pixels. I don't know what made these widths wrong back in 1987. DEK (in ancient times when he himself answered messages) wrote answering a question which value a driver program should pick: "A font designer may choose the number of pixels to look best at low res [e.g. there's a command change_width in plain MF to do this very thing] because, for example, you might want the letter T to be an odd number of pixels wide on account of symmetry." And the MFbook says in Chapter 24 (p. 199, 1st printing) about the width w of a character: "If w is not a good value, we want to replace it by either w+1 or w-1, whichever is closer to the device-independent width from which w was rounded. ... Plain METAFONT's change_width does this." Thus one would have expected widths of 44 and 43 for "m", but NEVER values as large as 46! I decided to have an exhaustive test run on our sets of fonts. From the comparison of the device dependent widths between fonts created in 1987 and in 1989 (because this would give good hints on bad spots in the old fonts) I got a lengthy list which I did not yet check completely. I will send it later if this has not been done already by someone else. Now two questions arise: 1. What looks/works better in Tom Reid's tests with CORRECT fonts? The total drift will be significantly reduced even for the ten-m test! 2. How do we GET RID OF BAD OLD FONTS spread all over the world? (this also applies to a large number of installations at our site!) Klaus Guntermann xitikgun@ddathd21.bitnet ========================================================================= Date: Thu, 2 Aug 90 13:10:28 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: comments of Norbert Schwarz Norbert Schwarz had many comments: > Are character sizes measured > before or after rescaling by MAGNIFICATION NUMBER /or RESOLUTION ? After scaling, i.e., effective char sizes. > Does this mean 20,000 characters times (600pt x 800pt) ? Yes. > - There are devices (drivers), which are limited in the > numbers of positioning commands. It is possible to put > 20,000 characters on a single page, but not on random positions. All the limits should be bound to hardware and software. E.g., there are printers like the HP LaserJet IIP with a usable base memory size of 390 KB. With this printer a full bitmap page cannot be printed, but there are limitations on the usage of downloaded chars, too. On such printers the driver implementor should use the device as best as he can. I will write up an ammendment for this. > My opinion: Even a "Level 0 Driver" should print rules partially. Yes. But partially printing of chars should not be required at this level. > to 4.4 Missing fonts > > Only (solid) black rectangles are allowed ? No. There are three items in this list. Should we add another item? Rectangles in the appropriate size? > (1) Has a "Level 0 Driver" the right to access TFM-files ? > i.e. Have these to be present ? A driver should have the right to access TFM files but he should not be required to do so. This is the text of another ammendment (on the maxdrift algorithm) which will come. > (2) Is it allowed to a "Level 0 Driver" to concatenate rules ? Why not? > How are these counted ? The rules in the DVI file are counted, not in the device dependent output. This is important because there are many devices which do not know anything about rules. > In a standard there is a need of a exact(!) list which facilities > may be configured externally. > i.e "naming scheme of fonts" > > (a) A page selection method has to be present: > - by (\count0) > - by pagenumbers (paper) No. We have discussed this in length: The level 0 standard -- named `Basic Functionalities of Drivers' -- defines the requirements which are *needed* for printing or previewing a DVI document. Things which may be implemented by preprocessores are not part of this level. I had submitted a proposal for an intro to the standard which clarifies what is ``level 0.'' Don has posted a note which substituted my proposed term `tiers' with `sub-standards.' The words do not matter -- it is important that such an intro is prepended. Don, what is with this intro? > (b) Protocol > - output of generation time of the DVI-file Why must a protocol be written? A protocol should only be neccessary if some problems have occured. Why is the generation time so important? Is this really a topic for level 0? Joachim ========================================================================= Date: Thu, 2 Aug 90 18:12:59 +0200 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Jan Michael Rynning Subject: Re: rounding errors. In-Reply-To: Tom Rikicki's message of Mon, 2 Jul 90 19:58:57 -0700 As Tom Rikicki points out, TeX's global and font magnifications are fixed point numbers, quantized to 10^-3, and MF's magnification is a fixed point number, quantized to 2^-16. Hence, if we assume that the values are correctly rounded, the real magnifications lie in the intervals [globmag+-10^-3/2], [fontmag+-10^-3/2], and [mfmag+-2^-16/2] The number used for the pk or gf file specification is an integer, so it may be off from the real value by +-1/2. Multiplying and adding this all up, we should be looking for a pk or gf file in the interval [dpi*[[globmag+-10^-3/2]*[fontmag+-10^-3/2]+-2^-16/2]+-1/2] If we further assume that the driver does its computations in 32-bit floating point with a 23-bit mantissa (frequently used representation for single precision floating point), every multiplication may add a relative error of +-2^-22/2. These errors are several magnitudes less than the others, so going for double precision won't help much. If we give up the assumtion of correct rounding, we'll have to remove all occurences of "/2" from the formulas above. If we furter take the computational errors into account, we should probably be on the safe side if we set l=round(0.999999*dpi*(globmag*fontmag-0.001*(globmag+fontmag)-0.0002)-1) u=round(1.000001*dpi*(globmag*fontmag+0.001*(globmag+fontmag)+0.0002)+1) and look for pk or gf files in the interval [l,u] For globmag=fontmag=1, and large dpi values, this is slightly greater than +-0.22%. At 300 dpi it's +-0.33%, and at 72 dpi it's +-1.39%. If you look at LFONTS.TEX, you'll find things like \def\@ptscale#1{ scaled #100} \font\fivsc = cmcsc10 \@ptscale5 % small caps This gives us fontmag=0.5. For globmag=1, and large dpi values, the size of the interval increases to slightly more than +-0.34%. At 72 dpi the interval becomes +-2.78%. The point I'm trying to make is that we can't specify the size of the interval as a percentage, if want to make sure that we find the file, for reasonable magnifictions and resolutions. Doing so would make the size of the interval proportional to dpi*globmag*fontmag. As you see from the formulas above, the three largest error terms are proportional to dpi*(globmag+fontmag) from TeX's fixed point rounding errors dpi from MF's and TeX's fixed point rounding errors 1 from the integer used in the file specification (not necessarily in that order). The only error term proportional to dpi*globmag*fontmag comes from the computational errors. As I said before, that term is several orders of magnitudes less than the greatest one. No wonder an interval size proportional to dpi*globmag*fontmag won't do! Comments? Jan Michael Rynning, jmr@nada.kth.se Department of Numerical Analysis If you can't fully handle domains: and Computing Science, ARPA: jmr%nada.kth.se@uunet.uu.net Royal Institute of Technology, UUCP: {uunet,mcvax,...}!nada.kth.se!jmr S-100 44 Stockholm, BITNET: jmr@sekth Sweden. Phone: +46-8-7906288 computational errors into account, we should probably be on the safe side if we set l=round(0.999999*dpi*(globmag*fontmag-0.001*(globmag+fontmag)-0.0002)-1) u=round(1.000001*dpi*(globmag*fontmag+0.001*(globmag+fontmag)+0.0002)+1) Received: from SEARN.SUNET.SE by TAMVM1.TAMU.EDU (Mailer R2.03B) with BSMTP id 7063; Thu, 02 Aug 90 11:20:32 CDT Received: from SEARN by SEARN.SUNET.SE (Mailer R2.05) with BSMTP id 0140; Thu, 02 Aug 90 18:14:55 O Received: from nada.kth.se by SEARN.SUNET.SE (IBM VM SMTP R1.2.2MX) with TCP; Thu, 02 Aug 90 18:14:46 O Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00968; Thu, 2 Aug 90 18:12:59 +0200 Date: Thu, 2 Aug 90 18:12:59 +0200 From: Jan Michael Rynning To: The TUG DVI driver standards discussion list Subject: Re: rounding errors. In-Reply-To: Tom Rikicki's message of Mon, 2 Jul 90 19:58:57 -0700 Message-Id: As Tom Rikicki points out, TeX's global and font magnifications are fixed point numbers, quantized to 10^-3, and MF's magnification is a fixed point number, quantized to 2^-16. Hence, if we assume that the values are correctly rounded, the real magnifications lie in the intervals [globmag+-10^-3/2], [fontmag+-10^-3/2], and [mfmag+-2^-16/2] The number used for the pk or gf file specification is an integer, so it may be off from the real value by +-1/2. Multiplying and adding this all up, we should be looking for a pk or gf file in the interval [dpi*[[globmag+-10^-3/2]*[fontmag+-10^-3/2]+-2^-16/2]+-1/2] If we further assume that the driver does its computations in 32-bit floating point with a 23-bit mantissa (frequently used representation for single precision floating point), every multiplication may add a relative error of +-2^-22/2. These errors are several magnitudes less than the others, so going for double precision won't help much. If we give up the assumtion of correct rounding, we'll have to remove all occurences of "/2" from the formulas above. If we furter take the computational errors into account, we should probably be on the safe side if we set l=round(0.999999*dpi*(globmag*fontmag-0.001*(globmag+fontmag)-0.0002)-1) u=round(1.000001*dpi*(globmag*fontmag+0.001*(globmag+fontmag)+0.0002)+1) and look for pk or gf files in the interval [l,u] For globmag=fontmag=1, and large dpi values, this is slightly greater than +-0.22%. At 300 dpi it's +-0.33%, and at 72 dpi it's +-1.39%. If you look at LFONTS.TEX, you'll find things like \def\@ptscale#1{ scaled #100} \font\fivsc = cmcsc10 \@ptscale5 % small caps This gives us fontmag=0.5. For globmag=1, and large dpi values, the size of the interval increases to slightly more than +-0.34%. At 72 dpi the interval becomes +-2.78%. The point I'm trying to make is that we can't specify the size of the interval as a percentage, if want to make sure that we find the file, for reasonable magnifictions and resolutions. Doing so would make the size of the interval proportional to dpi*globmag*fontmag. As you see from the formulas above, the three largest error terms are proportional to dpi*(globmag+fontmag) from TeX's fixed point rounding errors dpi from MF's and TeX's fixed point rounding errors 1 from the integer used in the file specification (not necessarily in that order). The only error term proportional to dpi*globmag*fontmag comes from the computational errors. As I said before, that term is several orders of magnitudes less than the greatest one. No wonder an interval size proportional to dpi*globmag*fontmag won't do! Comments? Jan Michael Rynning, jmr@nada.kth.se Department of Numerical Analysis If you can't fully handle domains: and Computing Science, ARPA: jmr%nada.kth.se@uunet.uu.net Royal Institute of Technology, UUCP: {uunet,mcvax,...}!nada.kth.se!jmr S-100 44 Stockholm, BITNET: jmr@sekth Sweden. Phone: +46-8-7906288 ========================================================================= Date: Thu, 2 Aug 90 16:33: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 standards Date: Thu, 2 Aug 90 19:05:57 EDT From: Karl Berry Subject: dvi standards To: dhosek@YMIR.CLAREMONT.EDU I do not know if I already sent this to you, but here it is again, if I didn't. karl@cs.umb.edu ---- Hi, I read through the dvi standards document you posted last night. Here are some comments: The quotes in the title seem unnecessary. Some rationale for the apparently arbitrary numbers (600pt x 800pt characters and rules, 20,000 characters on a page, 1000 rules, stack depth of 100, moving 2^31 units, 64 fonts) might be nice. Or are they all implied by `the possible output of TeX82'? In ``location of the origin'', does ``coordinates'' really have an umlaut? I've never seen that (even in DEK's books). In ``specials'', the standard says the dvi driver must issue warnings about certain specials. I strongly believe that the driver should allow such warnings to be disabled by the user. Nothing is more annoying than seeing a special that you know perfectly well is nonstandard being warned about when you are previewing the document (or whatever). In ``the scaling number'', don't you mean `non-square aspect ratio', not `non-unit'? In ``minimum set of magnifications'', the driver should be able to `load fonts at the following magnifications ...' -- if the fonts exist. Also, shouldn't `magstep0' etc. be in typewriter and preceded with a \? In ``margin of error'', shouldn't `...the driver should use that font...' be `the driver should use that magnification'? Are we talking about the global magnification of the dvi file or the magnification for a particular font. The latter seems more likely to me -- if someone asks for foo.100pk, the driver has to look for foo.{101,102,98,99}pk. If that's what that subsection is saying, it should read something like `if a dvi file requests a magnification x for a particular font, and a font exists with a magnification within 2% of x, then the driver should use that font without warning'. By the way, where did 2% come from? Seems like a lot. In `missing fonts', items 2 and 3 shouldn't be capitalized, since they don't start a sentence (although they could, if you put periods at the ends of items 1 and 2). Also, in item 2, `the size of the font' should be `the size of the character', shouldn't it? Or is the idea to have rectangles 10pt high for characters in a missing font foo10? I think people will have a lot of trouble implementing doing 600pt x 800pt characters. My LW II+ runs out of memory a lot sooner than that. Thanks for putting in the work to create this document. I think a standard like this is a real step forward in the TeX world. karl@cs.umb.edu ========================================================================= Date: Thu, 2 Aug 90 16:42:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Amendment: DVI limits only for devices which may support it (S2) Amendment: DVI limits only for devices which may support it (S2) Amendment number: 06 Submitted by: Joachim Schrod Date: 02 August 1990 Currently says: 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 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). [vertical bars indicate the changed portion] Reason for change: There exist popular devices on which it is impossible to realize the required limits. It is nonsense to say that these devices may not be used for TeX output any more. Example: Suppose you have an HP LaserJet+ with 512 KB of memory, leading to 390 KB usable memory. A driver for such devices should also support nearly-compatible printers (old Kyoceras), therefore it may not use character codes between 0 and 32 resp. 128 and 159. If a page with 20000 different characters shall be printed these characters may neither be downloaded (only 16*191=3056 chars) nor may they be printed in bitmapped form because you cannot print a full page bitmap with this printer. Furthermore this device cannot print characters in the size 600 to 800 pt for the same reasons. ========================================================================= Date: Thu, 2 Aug 90 16:51: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: Thu, 2 Aug 90 16:47:46 PDT From: langdon%laura.llnl.gov@lll-lcc.llnl.gov (B. Langdon) Subject: dvi driver standard Lots to agree with there. I don't care for the rules on Specials. I have made dvi files that work on two different spoolers and a previewer which silently ignore specials other than their own. I don't relish seeing a bunch of mandatory error messages, nor getting calls from people who are worried by them, nor having to make different versions of the dvi file. Reality is that spoolers have had essential functionality via specials and some of this will not be officially defined by the committee, and will continue to be used. Hopefully you won't do this do previewers, which are not entirely unrelated to spoolers. Anyway, as I said, there's lots to agree with in the proposal. ========================================================================= Date: Fri, 3 Aug 90 06:27:59 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIKGUN@DDATHD21.BITNET Subject: max_drift and bad fonts As announced earlier I did a comparison of fonts for different print engines to find out which might be defect. (I hope that this time my message can go out in reasonable time.) The pktype output lines containing TFM width and dx (horziontal excapement) values were compared. If there were differences larger than one pixel the font was considered defect. The investigation of fonts gave the following table of bad (b) or questionable (q) fonts. "Bad" fonts have at least one character exceeding the nominal width (as computed from the TFM width). "Questionable" fonts have deviations in a sense that escapement values are less than expected. Fonts marked with an asterisk were also reported by Tom Reid to contain three-pixel errors on "m". magstep font 0 h 1 2 3 4 5 cmb10 b b b b b b cmbx5 b b* b cmbx6 b b* b b* cmbx7 b b b b cmbx8 b* b b b cmbx9 b* b* b* b* b* cmbx10 b* b* b b* b b cmbx12 b b b b b b cmbxsl10 b b b b b b cmdunh10 b cmr7 b cmr8 b* cmr9 b* cmr10 b* cmr12 b* cmr17 b* cmsy5 q q q q q q q cmsy6 q q q q q q q cmsy7 q q q q q q cmmi8 q I re-ran MF on the fonts marked 'b' and the differences disappeared. Can anybody explain this behaviour? How many fonts at other sites are affected? Sorry for raising more questions than giving answers. Klaus Guntermann xitikgun@ddathd21.bitnet ========================================================================= Date: Fri, 3 Aug 90 12:25:18 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: dvi driver standard > From: langdon%laura.llnl.gov@lll-lcc.llnl.gov (B. Langdon) > Subject: dvi driver standard > > I don't care for the rules on Specials. I have made dvi files that work > on two different spoolers and a previewer which silently ignore specials > other than their own. I don't relish seeing a bunch of mandatory error > messages, nor getting calls from people who are worried by them, nor > having to > make different versions of the dvi file. I agree strongly with this: it seems an obvious thing to do in device-INDEPENDENT files, thus making even the specials usable on more than one device. It does, howver, require some standard for how the device for which a special is intended is specified. Something such as--- everything up to the first ":" is an `identifier' of the device driver for which the special is intended Chris Rowley ========================================================================= Date: Fri, 3 Aug 90 13:19:44 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: pixel_round and fonts In-Reply-To: Message of Thu, 2 Aug 90 11:00:15 CDT from On Thu, 2 Aug 90 11:00:15 CDT said: >On Fri, 27 Jul 90 Thomas J. Reid sent a message concerning >drift correction. > >... > >The difference between the fonts for with mode imagen and ricoh_... >is that the imagen fonts were created back in July 1987, while the ricoh_... >fonts were computed in August 1989. >Thus I ran MF again and, what wonder, now the horizontal escapement >value for "m" in cmbx10 scaled \magstephalf comes out with 44 Pixels. Hmm, this is interesting. The fonts which I found the three-pixel errors in were gernerated on May 10, 1988 --- sometime between your "bad" and "good" set. It is certainly possible that the three-pixel difference is due to an error in our METAFONT. Do the values of blacker, fillin, and o_correction have any effect on the pixel widths? (I don't know METAFONT very well.) The cmbx10 font for which I found the difference was generated with the values: blacker := 0.70; fillin := 0.0; o_correction := 0.5; The other fonts had values close to these. >... > >Now two questions arise: >1. What looks/works better in Tom Reid's tests with CORRECT fonts? > The total drift will be significantly reduced even for the ten-m test! If it proves to be true that "correct" fonts do not have differences in width which exceed one pixel, then there will be no difference between the two drift-correction techniques. These two techniques are: #1: set hh to pixel_round(h) +- max_drift #2: set hh to hh +- 1 If an individual character cannot have an error exceeding one pixel, then hh cannot drift by more than one pixel at a time. In this case, both methods result in a correction on just one pixel. However, if it proves to be true that "correct" fonts can have differences exceeding one pixel but never as much as three pixels, then the two methods should once again be compared. >2. How do we GET RID OF BAD OLD FONTS spread all over the world? > (this also applies to a large number of installations at our site!) First we need to identify the source of width differences of more than one pixel. If it turns out that this is due to faulty versions of METAFONT, then we need to let people know through TeXhax and/or some of the other general distribution lists. > Klaus Guntermann > xitikgun@ddathd21.bitnet ---Tom Reid ========================================================================= Date: Fri, 3 Aug 90 14:48:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: pixel_round and fonts The difference in escapements between the imagen and ricoh fonts is most definitely due to differences in mode_def's. The MF code for m in the cm fonts resets the pixel width so that the three vertical lines of the m are equidistant. Since the value of blackness will change the pixel widths of the verticals, it will have an effect on the horizontal pixel escapement. No change to the MF or CM source code has changed this particular effect. -dh ========================================================================= Date: Fri, 3 Aug 90 14:57:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Amendment: Change to definition of limits for maxdrift (App E) Amendment: Change to definition of limits for maxdrift (App E) Amendment number: 07 Submitted by: Joachim Schrod Date: 02 August 1990 Currently says: For a horizontal movement from any other command, ${\it hh}$ should be set to be ${\it hh}+{\it pixel\_round}(x)$ if $x<0.2{\it quad}$ for a horizontal movement to the right or if $x>-0.9{\it quad}$ for a horizontal movement to the left. $\it quad$ is defined to be the design size of the current font in the \DVI\ file (after all necessary magnifications have been applied). If $x$ exceeds the bounds outlined above, ${\it hh}$ is set to be ${\it pixel\_round}(h+x)$. In this way, rounding errors are absorbed by interword spaces. Change to read: For a horizontal movement from any other command, ${\it hh}$ should be set to be ${\it hh}+{\it pixel\_round}(x)$ if | $x < {\it word\_space}$ for a horizontal movement to the right or if | $x > -{\it back\_space}$ for a horizontal movement to the left. {\it | word\_space\/} is defined as $\it space - space_shrink$, and {\it | back\_space\/} is defined as $\it 0.9 quad$ if the driver uses {\tt | TFM} files. If the driver does not use {\tt TFM} files the design | size of the current font in the {\tt DVI} file (after all necessary | magnifications have been applied) may be used for a {\it quad}, and | {\it word\_space\/} may be approximated by $\it 0.2 quad$. If $x$ exceeds the bounds outlined above, ${\it hh}$ is set to be ${\it pixel\_round}(h+x)$. In this way, rounding errors are absorbed by interword spaces. [vertical bars indicate the changed portion] Reason for change: A driver should not be forced to read TFM files (perhaps they are not available there at all). But if it wants to it may -- and then it should use the most precise information available. ----- Amendment procedure. You may vote "Yes", "No" or "Abstain" on this amendment. You may change your vote at any time the amendment is still on the floor. The status of votes on all amendments will be sent to the voting members of the Driver Standards Group once every 2 days. ========================================================================= Date: Fri, 3 Aug 90 14:58:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Amendment: Change to maxdrift value (App E) Amendment: Change to maxdrift value (App E) Amendment number: 08 Submitted by: Joachim Schrod Date: 02 August 1990 Currently says: After any horizontal movement, a final check is made as to whether $\abs(Kh-{\it hh})>{\it max\_drift}$. If it is, then $\it max\_drift$ is added or subtracted to $hh$ to bring it closer to $Kh$. A similar check is made with $\it vv$ and $v$. $\it max\_drift$ should be set to $2$ for output devices with device units smaller than or equal to $1/200$ inches and $1$ for output devices with device units with device units greater than $1/200$ inches. Change to read: After any horizontal movement, a final check is made as to whether $\abs(Kh-{\it hh})>{\it max\_drift}$. If it is, then $\it max\_drift$ is added or subtracted to $hh$ to bring it closer to $Kh$. A similar check is made with $\it vv$ and $v$. $\it | max\_drift$ should be set to~2 for output devices with device | units smaller than or equal to $1/200$ inches, 1~for output devices with device units with device units greater than $1/200$ + inches, and 0~for output devices with device units with device units + greater than $1/100$ inches. [vertical bars indicate changed lines, plus signs indicate added portions. Reason for change: Previews usually have resolutions below 100 dpi. On a screen the space between two words (usually two to three pixels!) should always be recognizable, and should not be narrowed by a drift. With previews visualization of the interword space is more important than equidistant widths between the characters of a word; previews are often used for proofreading. After all we will not get equidistant widths anyway. Ties are inserted for formatting reasons. ----- Amendment procedure. You may vote "Yes", "No" or "Abstain" on this amendment. You may change your vote at any time the amendment is still on the floor. The status of votes on all amendments will be sent to the voting members of the Driver Standards Group once every 2 days. ========================================================================= Date: Tue, 7 Aug 90 14:29:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Minimum numbers of characters per page etc. Joachim's amendment 6 indicating that limits be imposed only on devices which can support those limits is, in my opinion rather misguided. The whole point of establishing these minimum standards is so that someone who is designing a macro package or a document or something along those lines can be assured that if they stay under quantity X, their page can be printed on ANY output device supported by TeX. Joachim's change will lead to some ambiguity: Laserjet drivers may feel absolved from writing drivers that support 256 character fonts since the Laserjet only handles 190-someodd characters per font. Ln03 driver writers will not bother to take the extra steps to support large fonts like LN03, etc. The numbers in the standard are arbitrary and probably too large in many cases. I would prefer to see the minimum levels reduced rather than the standard weakened in this manner. -dh ========================================================================= Date: Wed, 8 Aug 90 11:23:39 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Minimum numbers of characters per page etc. Don Hosek writes: > Joachim's amendment 6 indicating that limits be imposed only on devices > which can support those limits is, in my opinion rather misguided. The > whole point of establishing these minimum standards is so that someone > who is designing a macro package or a document or something along those > lines can be assured that if they stay under quantity X, their page can > be printed on ANY output device supported by TeX. Joachim's change will > lead to some ambiguity: Laserjet drivers may feel absolved from writing > drivers that support 256 character fonts since the Laserjet only handles > 190-someodd characters per font. Ln03 driver writers will not bother to > take the extra steps to support large fonts like LN03, etc. The numbers > in the standard are arbitrary and probably too large in many cases. I > would prefer to see the minimum levels reduced rather than the standard > weakened in this manner. Obviously he missed the point: The splitting of TeX fonts with 256 characters in device fonts with fewer characters is POSSIBLE and therefore not concerned by my amendment. Printing a 600x800pt character on a 300dpi laser beam printer with 512KB memory (e.g., HP LaserJet IIP, Kyocera F-800, just to name some popular ones) IS ***IMPOSSIBLE***. SO WE ARE DEFINING THAT THESE PRINTERS MUST NOT BE USED FOR TeX OUTPUT! We should lower the limits? But what are reasonable ones? Here at Darmstadt we once had written a DVI driver for a device with only 100 KB font storage and where we could not print a full page bitmap. This had worked reasonably well -- as long as not unusual documents, like those with 20000 characters on one page or a character with a size of 600x800pt, were printed. (By the way, how large are those 20000 characters?) This standard will not be accepted by the USERS if it does not support the devices they are using very often. I think this clarified the meaning of my amendment. If my wording in the amendment did not tell it clear enough someone who knows English better than I should reformulate it. Joachim ========================================================================= Date: Wed, 8 Aug 90 09:53:42 EST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: DAVID@PENNDRLS.BITNET I'm afraid I agree with Don about not allowing drivers to claim they meet the standards if they don't. The idea is to be able to say "you can print this file with any standard-conformant driver". If I can't print the file with driver X, then driver X is not standard conformant no matter how hard the author tried. Perhaps you could set up a classification system. Class A drivers can handle the minimums specified in the current standard. Class B drivers have lower minimums, determined by the most common types of more limited printers. Class C drivers would have the lowest minimums, determined by the lurking small printers that are only just barely adequate for TeX use. Then you would need a program that would rate a DVI file as Class A, B, or C (hmm, probably ought to have a DVI conformance checker regardless), so that someone that had to have the absolutely widest distrabution for his file could make sure a Class C driver could print it, and everybody else could use Class A. Actually, I suspect that the vast majority of files that don't include TeX graphics would fall into class B. But, then, I don't know how common these limited printers are . . . -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU) ========================================================================= Date: Wed, 8 Aug 90 17:19:51 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: classes of drivers David Murray suggests to classify drivers according to the devices they drive. Well, it's not a matter of drivers, it's a matter of devices! To what class belongs a driver for the HP LaserJet when it is able to fullfill class C on a device with 1MB and only class B on a device with 512 KB? -- It's still the same driver!! > But, then, I don't know how common these limited printers > are . . . How common is the HP LaserJet IIP in the USA? Is it really an unused resp. an unusual device? If this standard is to be accepted in this part I will test every driver (usually named DVIHP, DVIJEP, DVILASER/HP, etc) for this device if the driver is really conformant --- and it will not be... By the way, I'm not afraid of having an unconformant driver if it's a good driver. And I'm sure that many users will have the same opinion. Have you ever used Turbo Pascal? And laughed about ISO-Pascal, haven't you? We are creating a standard which will not be accepted by users because the standard neglects popular output devices. Joachim ========================================================================= Date: Wed, 8 Aug 90 11:11:47 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: classes of drivers In-Reply-To: Message of Wed, 8 Aug 90 17:19:51 MES from I agree with Joachim. A "standard" which ignores common devices is very likely to be ignored by users and driver developers. The older Xerox printers would have some difficulty handling 20,000 characters per page; they have a limit of 24K bytes per page, but this includes all positioning information. If our guidelines were to remain with a limit of 20,000 characters, I would simply ignore the requirement. If this means that my driver is not Level-0-compliant, so be it! However, there is a danger in this: The first requirement is the hardest to break. But once done, it becomes easier to ignore other requirements that a driver author may not like or that require much effort. After all, why bother: no matter how much effort is put into a second feature, the driver will still be non-compliant. O.K., so you suggest reducing the limits. Well, if we were to go with the least capable printer, the limit is likely to be so low as to be a useless point in the guidelines. Yes, it would be nice if we could could just say that "a driver should be able to handle XXXXX characters per page." Unfortunately, such a statement is too simplistic of a solution. A driver is a program (or set of programs) for transforming device independent files into device dependent form. In developing guidelines for drivers, device dependencies must be kept in mind. A statement along the lines of what Joachim suggests that "a driver should work to the best ability of the device for which it supports if it cannot support the limits in the guidelines" recognizes such device dependencies. ---Tom Reid ========================================================================= Date: Wed, 8 Aug 90 15:38:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Minimum numbers of characters per page etc. Joachim Schrod writes: >Don Hosek writes: >> Joachim's amendment 6 indicating that limits be imposed only on devices >> which can support those limits is, in my opinion rather misguided. The >> whole point of establishing these minimum standards is so that someone >> who is designing a macro package or a document or something along those >> lines can be assured that if they stay under quantity X, their page can >> be printed on ANY output device supported by TeX. Joachim's change will >> lead to some ambiguity: Laserjet drivers may feel absolved from writing >> drivers that support 256 character fonts since the Laserjet only handles >> 190-someodd characters per font. Ln03 driver writers will not bother to >> take the extra steps to support large fonts like LN03, etc. The numbers >> in the standard are arbitrary and probably too large in many cases. I >> would prefer to see the minimum levels reduced rather than the standard >> weakened in this manner. >Obviously he missed the point: The splitting of TeX fonts with 256 >characters in device fonts with fewer characters is POSSIBLE and >therefore not concerned by my amendment. >Printing a 600x800pt character on a 300dpi laser beam printer with >512KB memory (e.g., HP LaserJet IIP, Kyocera F-800, just to name some >popular ones) IS ***IMPOSSIBLE***. > SO WE ARE DEFINING THAT THESE PRINTERS MUST NOT BE USED FOR TeX OUTPUT! >We should lower the limits? But what are reasonable ones? Here at >Darmstadt we once had written a DVI driver for a device with only 100 >KB font storage and where we could not print a full page bitmap. This >had worked reasonably well -- as long as not unusual documents, like >those with 20000 characters on one page or a character with a size of >600x800pt, were printed. (By the way, how large are those 20000 >characters?) > This standard will not be accepted by the USERS if it does not >support the devices they are using very often. My example of the characters was a convenient case. Your amendment says that if drivers cannot reach the prescribed limits, they can fall short and still call themselves level 0. I'm saying that if the popular printers, e.g., the HP LJIIP can't handle the specifications we listed, then we should change those specifications. The purpose of the character size is to allow people to know that they can print some graphic as a single character, for example (cf. Capture, Metaplot, et alia). Let's say that printer X comes with 20K of printer memory and can print characters as big as 1in x 1in (which will each take up 1K of printer memory). What's the largest TeX character that printer can print? According to your ammendment, it's 1in by 1in. A clever author could go up to 4in by 5in by breaking the character into 20 pieces. See what I mean about ambiguities? I want TeX users to be secure in knowing they can print X number of characters on the page and Y number of rules so long as they're using a Level-0 conformant driver; your amendment loses that. -dh >I think this clarified the meaning of my amendment. If my wording in >the amendment did not tell it clear enough someone who knows English >better than I should reformulate it. Joachim ========================================================================= Date: Wed, 8 Aug 90 15:44:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: classes of drivers >By the way, I'm not afraid of having an unconformant driver if it's a >good driver. And I'm sure that many users will have the same opinion. >Have you ever used Turbo Pascal? And laughed about ISO-Pascal, haven't >you? >We are creating a standard which will not be accepted by users because >the standard neglects popular output devices. So let's change the standard in such a way that popular output devices are taken into consideration without losing the value of the standard. If user X creates a TeX file and DVItypes it (or some such) to see if it falls within the limits of level 0, and gives it to user Y and says, "if your driver is level 0, you should be able to print it fine" and user Y's driver written according to the specification you want doesn't print it then what was the point of having those specifications? We might as well say "A driver should be able to print as many rules as the output device will handle." etc. The figures I gave were too high. I'm aware of that. Let's lower them then. The point of those numbers is to insure that a DVI file whose contents fall within those limits can be printed on any Level 0 driver, not just on those level 0 drivers supporting good printers. -dh ========================================================================= Date: Wed, 8 Aug 90 21:02:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: Comments from Peter Breitenlohner Date: 8 August 90, 13:48:02 GMT From: Peter Breitenlohner 32308-412 (089) To: Don Hosek Message-id: X-Envelope-to: DHOSEK TFM width from TFM and PK files: I fully understand, that the reading of unnecessary font files should be avoided, thus if the TFM file is never read, the width from the PK file can not be compared. But: if the TFM file is read and if the TFM widths do not agree, I think the width from the TFM file should be taken as the correct one; this is the width TeX has based its computations on, thus correct alignment of right margins depends on using this width. In addition unequal width should cause an error message! Another problem arises with VF files. A VF file for a font A might specify that char X is to be typeset as char Y of another (real or virtual) font B. At this moment I would like to know whether char Y from B has the same width as X from A; if yes one can avoid extra positioning commands for the output device or extra push/pop instructions in the case of DVIcopy. For reasons of efficiency I would like to make this decision once while reading the VF file for A, not each time char X from font A is to be typeset. Thus I would like to know the TFM widths for all local fonts while reading the character maps from a VF file. The easiest way to get them is to read the TFM file and one can certainly not read another VF file since that might lead to an infinite recursion (think of the file recurse.vpl described in VPtoVF.WEB). Once one has decided that char X from font A and char Y from font B do have the same width, it would be extremely embarrasing to find that the PK file for font B specifies a different width and to modify all sorts of decisions made earlier. It is clear that the character escapements from a PK file should take precedence over escapements computed from TFM width, no question about this. By the way, what should one do with escapements from a PK of GF file which are not integer values ??? My preferred strategy would be: take the TFM width from whereever you can get it, but if the width is read from the TFM file and from a PK file and these two differ then a. take the width from the TFM file as the correct one, and b. complain loudly about this problem, this is a serious problem which should be looked at and corrected. All this probably means that some font files are corrupted or that the files don't belong together. I assume this should also show in different check sums. I hate the idea that TeX and DVItoXXX could use different TFM widths and that this goes on and on undetected! Regards Peter [Thinking about the problem it seems to me that it is essential that the precedences of widths follow this order: VF, TFM, PK. -dh] ========================================================================= Date: Thu, 9 Aug 90 05:13:37 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIKGUN@DDATHD21.BITNET Subject: driver capabilities and device restrictions In my opinion the discussion about drivers and printers does not hit the point in all cases, and there are some misunderstandings. I see that there are devices which can come in different variations, e.g. with different amounts of memory installed (and are upgradeable). And that gives reason to some problems because how would you rate a driver for this device? Other limits are not changeable (e.g. number of characters per font). And to stay with the already discussed HP compatible printers there are both: Joachim Schrod writes: >Obviously he missed the point: The splitting of TeX fonts with 256 >characters in device fonts with fewer characters is POSSIBLE and >therefore not concerned by my amendment. >Printing a 600x800pt character on a 300dpi laser beam printer with >512KB memory (e.g., HP LaserJet IIP, Kyocera F-800, just to name some >popular ones) IS ***IMPOSSIBLE***. The first topic addresses the limitation of characters per font. This MUST be overcome by a driver conforming to level 0. The second is just a matter of installed memory. If you plug in another MB of memory you can have that character printed as a bitmap (this will take some time over a serial line, but it will work) or break it up into pieces (as Don Hosek suggests). Don Hosek writes: >My example of the characters was a convenient case. Your >amendment says that if drivers cannot reach the prescribed >limits, they can fall short and still call themselves level 0. >I'm saying that if the popular printers, e.g., the HP LJIIP can't >handle the specifications we listed, then we should change those >specifications. The purpose of the character size is to allow >people to know that they can print some graphic as a single >character, for example (cf. Capture, Metaplot, et alia). Let's >say that printer X comes with 20K of printer memory and can print >characters as big as 1in x 1in (which will each take up 1K of >printer memory). What's the largest TeX character that printer >can print? According to your ammendment, it's 1in by 1in. A >clever author could go up to 4in by 5in by breaking the character >into 20 pieces. See what I mean about ambiguities? I want TeX >users to be secure in knowing they can print X number of >characters on the page and Y number of rules so long as they're >using a Level-0 conformant driver; your amendment loses that. Now, how would we rate a driver that can print the required large characters on the extended printer, but (of course) not on the small one? To my opinion the driver writer is not to blame for this. He should get the level 0 approval for his driver. But one cannot promise someone that a document will be printed with that driver in all cases. Now we can either couple the level 0 approval with some device requirements (e.g. `conforms fully if used on devices with this-and-that extra equipment') or just say: `may fail with only basic equipment'. But I doubt if a clear statement will be possible in all cases (e.g. printing may fail even on 2 MB HP compatible if some other application made macros and forms resident and thus reduced the available memory; the driver cannot detect that!). By the way: I would like if we require somehow that customizations can be done even after installation. Someone may start with just the base memory and be happy with that (e.g. as long as no graphics are required) and upgrade the printer later on. One should be able to tell the driver that the environment changed. Tom Reid writes: >However, there is a danger in this: The first requirement is the hardest >to break. But once done, it becomes easier to ignore other requirements >that a driver author may not like or that require much effort. After >all, why bother: no matter how much effort is put into a second feature, >the driver will still be non-compliant. This is important. But lowering the requirements will also not help because users that have the need for the large characters have no means to determine whether a driver will fulfill their expectations. If level 0 is to contain the 600x800pt requirement, I don't see an easy solution. Klaus Guntermann xitikgun@ddathd21 ========================================================================= Date: Thu, 9 Aug 90 11:18:44 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "LEICHTER-JERRY@CS.YALE.EDU Jerry Leichter" Subject: Pixel rounding, again I hate to re-open a subject that seems to have quieted down, but it occurred to me that in all the discussion, the class of algorithms proposed missed a possible alternative. All of them had the following form: Input: h, hh, some error and a character. Output 1: Place character at the current position, calculate new values for h, hh and error. Output 2: If error too large, adjust hh. The effect of this is to correct the error to the right of the character. Depending on the algorithm, the error may be completely corrected, or it may be partially corrected and then perhaps patched up some more on characters placed even further to the right. Consider the more general algorithm: Input: h, hh, some error and a character. Output 0: Calculate new h, hh and error if character is placed at current position. If too large, maybe adjust current position. Output 1: Place character at the current position, calculate new values for h, hh and error. Output 2: If error too large, adjust hh. That is, try to split the error, putting some on either side of the character. If nothing else, this double the chance that you can bury at least some of the error in an inter-word gap. If, indeed, the maximum error possible is 3 pixels, and you decide to correct to an error of 0 by, say, putting a 1-pixel correction before and a 2-pixel correction after the character, then in a row of "m"'s you'd still be adding 3 pixels between adjacent characters, which is what the original "correct to 0" algorithm would do. (Though there WOULD be a difference: The entire row of m's would be 1 pixel further to the right here.) This is the worst case. There are further generalizations of this approach which require keeping track of the errors induced by a succession of characters, then apportioning the re-positioning among them as evenly as possible. This would be much more complicated and certainly harder to test - it would be hard to construct a comprehensive set of test cases - and I very much doubt it's worth the trouble. But using what amounts to one character of memory might make it possible to do better than using NO memory, at little cost. I don't have the appropriate setup here to try this out at the moment, so I can't report any experimental results. But perhaps I can tweak someone's curiosity enough to give it a whirl.... -- Jerry ========================================================================= Date: Thu, 9 Aug 90 19:49:50 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Explicit limits in the draft DVI driver standard Recent discussions on this list have centered on the problem of the specification of limits in the draft DVI driver standard, such as "the driver shall be able to print ##### different characters on one page". One proposed amendment would modify such language to permit deviations where the limit was in practice too large, and objections were raised that this opens a can of worms that one would rather not open. It is important to remember that there are two considerations here. One is whether the driver itself can handle those limits, and the second is whether the device can. For the latter, in some cases, adding more memory to the device, or upgrading its firmware, or upgrading to the next higher model, can be used to get around existing limits (and we must face the fact that EVERY printer on the market today has many fixed limits that potentially affect TeX output). We really cannot do anything about device limits, other than to observe in the standard that such limits exist, and the standard cannot dictate what they are, or should perhaps be. We can, however, set limits that a driver should be able to support. This means that a manuscript that requires 20,000 different characters on one page may indeed not print on a regular HP LaserJet Series II, but it might very well do so on one that had additional memory installed. The language in the standard must therefore make clear this distinction, and the fact that a particular driver can produce output from a particular DVI file is still no guarantee that the printer will have resources to handle the file. Note, for example, that the available memory on a PostScript printer on a shared network (as many are today) is a function of what jobs have been processed since it was started; PostScript jobs can, and do, leave behind things in memory that persist until the next printer reboot. I at times have to power-cycle the Apple LaserWriter around the corner from me for just that reason--it gets VM (virtual memory) exceeded errors on pages I know that it has printed successfully before. We can suggest that driver writers document known limits in the driver programs, and in the devices they support. Such documentation may help users to understand failures they experience, and also may be useful the next time they buy an output device. The red PostScript Language Reference Manual has an appendix giving implementation limits for the PostScript interpreter in the Apple LaserWriter. However, I can find no such tables in any of the other PostScript books I have (and I think I own them all), nor is any such information present in the PostScript printer description files from Adobe (I checked a half dozen of them), nor is it even possible to coax those limits out of the printer, except possibly by tedious binary search experiments to find where the limits are using test files. If we look at programming language standards (Fortran, Cobol, Ada, LISP, Pascal, Modula/2, et al), implementation limits are not even addressed by the standard. In the real world, those limits are often hit. [My PLOT79 software, for example, on many UNIX implementations must be compiled with compiler switches that enlarge compiler tables for statements and symbols.] Those language standards would suggest that perhaps it is inappropriate for a DVI driver standard to have specified limits. It may be advisable instead to have a table of SUGGESTED minimum limits, and keep the main part of the standard free of absolute numbers. ------- ========================================================================= Date: Fri, 10 Aug 90 15:19:01 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: differences in TFM widths Peter Breitenlohner has covered the problem of different TFM widths in different incarnations of one font (VF, TFM, PK) in a recent mail. As I remember, the checksum should be different in such a case: they are computed in a way so that small changes in TFM widths will lead to big changes in the checksum. And I expect that checksums must not be ignored. So if we get identical checksums we may assume identical TFM widths. But looking at the standard I discovered that checksums are not mentioned. I begun to write an amendment, but remembered the discussion a while ago about the special checksum value 0. So I wanted to have a little feed back before I present an amendment: Shall checksums with a value of 0 be ignored? (Please note that there are conflicting statements in different format definitions!) Joachim ========================================================================= Date: Mon, 13 Aug 90 09:50:43 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Explicit limits in the draft DVI driver standard In-Reply-To: Message of Thu, 9 Aug 90 19:49:50 CDT from On Thu, 9 Aug 90 19:49:50 CDT Nelson H. F. Beebe said: > >... > >We can suggest that driver writers document known limits in >the driver programs, and in the devices they support. Such >documentation may help users to understand failures they >experience, and also may be useful the next time they buy an >output device. > >... > >Those language standards would suggest that perhaps it is >inappropriate for a DVI driver standard to have specified >limits. It may be advisable instead to have a table of >SUGGESTED minimum limits, and keep the main part of the >standard free of absolute numbers. >------- I think that Nelson's ideas here represent a good way of addressing the problem. In addition to giving suggested limits for numbers of characters, rules, character sizes, fonts, etc., we should distribute TeX and MF source files containing pages of varying complexity and characters of varying sizes. This test file could be used by driver authors as a benchmark to demonstrate the limits of a particular model (or memory option) of a device. Having such a test file would make it easier for users to visualize the limits of page complexity. Most devices have limits not on the number of characters, but rather on the number of bytes in the output file. This count includes positioning commands; extra bytes are needed for each word, font change, kern, diacritical mark (assuming that CM fonts are being used), and so forth. ---Tom Reid ========================================================================= Date: Wed, 15 Aug 90 22:05:20 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: MMDFII Mail System Subject: Failed mail Your message was not delivered to the following addresses: (USER) Unknown user name in "alien@uk.ac.essex" Your message begins as follows: Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id aw21209; 13 Aug 90 15:48 GMT Received: from relay.cs.net by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa09213; 13 Aug 90 16:24 BST Received: from tamvm1.tamu.edu by RELAY.CS.NET id aa04998; 13 Aug 90 11:38 EDT Received: from TAMVM1.TAMU.EDU by tamvm1.tamu.edu (IBM VM SMTP R1.2) with BSMTP id 8778; Mon, 13 Aug 90 10:38:25 CDT Received: by TAMVM1 (Mailer R2.03B) id 6913; Mon, 13 Aug 90 10:37:50 CDT Date: Mon, 13 Aug 90 09:50:43 CDT Reply-To: The TUG DVI driver standards discussion list Original-Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Explicit limits in the draft DVI driver standard To: Adrian Clark , Chris Rowley In-Reply-To: Message of Thu, 9 Aug 90 19:49:50 CDT from Sender: DRIV-L%edu.tamu.tamvm1@net.cs.relay On Thu, 9 Aug 90 19:49:50 CDT Nelson H. F. Beebe said: > >... > >We can suggest that driver writers document known limits in >the driver programs, and in the devices they support. Such >documentation may help users to understand failures they >experience, and also may be useful the next time they buy an >output device. > >... > >Those language standards would suggest that perhaps it is >inappropriate for a DVI driver standard to have specified >limits. It may be advisable instead to have a table of >SUGGESTED minimum limits, and keep the main part of the >standard free of absolute numbers. >------- I think that Nelson's ideas here represent a good way of addressing the problem. In addition to giving suggested limits for numbers of characters, rules, character sizes, fonts, etc., we should distribute TeX and MF source files containing pages of varying complexity and characters of varying sizes. This test file could be used by driver authors as a benchmark to demonstrate the limits of a particular model (or memory option) of a device. Having such a test file would make it easier for users to visualize the limits of page complexity. Most devices have limits not on the number of characters, but rather on the number of bytes in the output file. This count includes positioning commands; extra bytes are needed for each word, font change, kern, diacritical mark (assuming that CM fonts are being used), and so forth. ---Tom Reid ========================================================================= Date: Sun, 26 Aug 90 23:26:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Votes I'm going to make one change to the voting procedure (unless I get any objection by Wednesday)... if an amendment has been out for two weeks and has not been settled, it will be considered voted on with those votes received. (This seems necessary due to the lack of votes being received from some). -dh ========================================================================= Date: Mon, 27 Aug 90 11:56:28 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: MESSAGE AGENT Subject: Re: Votes Dear The TUG DVI driver standards discussion list, This is an automatic reply. Feel free to send additional mail, as only this one notice will be generated. The following is a prerecorded message, sent for phil I am attending a workshop in Portland, Oregon. I will return on Wednesday (8/29) and will read your message at that time. If you need immediate assistance with something related to departmental computing facilities, please contact K-H Jan at the address . William LeFebvre ========================================================================= Date: Mon, 27 Aug 90 15:32:20 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Bart Childs Subject: Re: Votes I had emergency appendectomy a week ago today. I do not plan to study and vote for at least another week or so. Please do not consider my inactivity anything else than a tremendous shortage of time. I plan to return to being an active member as soon as possible. I am well on my way to a good recovery and expect to be told that tomorrow by my physician. Bart ========================================================================= Date: Tue, 28 Aug 90 00:07:48 LCL Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: W: Invalid RFC822 field -- "(5.61/PURDUE_CS-1.2) ID ; MON, 27 AUG 90 17:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster Wish you a good recovery!!!! StvB ========================================================================= Date: Thu, 30 Aug 90 18:37: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: The Level 0 Draft standard (v 0.03) -- Request for comments From: IN%"lee@sqarc.sq.COM" 30-AUG-1990 16:06:46.88 To: dhosek@YMIR.CLAREMONT.EDU CC: Subj: RE: The Level 0 Draft standard (v 0.03) -- Request for comments Received: from jarthur.Claremont.edu (134.173.4.42) by YMIR.CLAREMONT.EDU with PMDF-822; Thu, 30 Aug 1990 16:06 PDT Received: from uunet by jarthur.uucp id aa26077; 30 Aug 90 16:09 PDT Received: from utai.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA25920; Thu, 30 Aug 90 18:47:22 -0400 Received: from sq ([192.31.6.1]) by neat.cs.toronto.edu with SMTP id <10134>; Thu, 30 Aug 1990 18:37:10 -0400 Received: from sqarc.sq.com (sqarc) by sq.sq.com with SMTP id 31; Thu, 30 Aug 90 18:40:34 EDT Received: by sqarc.sq.com (4.0/SMI-4.0) id AA11549; Thu, 30 Aug 90 18:38:15 EDT Date: Thu, 30 Aug 1990 18:38:15 -0400 From: lee@sqarc.sq.COM Subject: RE: The Level 0 Draft standard (v 0.03) -- Request for comments In-reply-to: <2317@shelby.Stanford.EDU> To: dhosek@YMIR.CLAREMONT.EDU Message-id: <9008302238.AA11549@sqarc.sq.com> X-Envelope-to: dhosek MMDF-Warning: Parse error in original version of preceding line at jarthur.Claremont.edu Newsgroups: comp.text.tex Organization: SoftQuad Inc. Just a few very minor points. All questions I ask here are rhetorical, I'm not looking for answers, just pointing out some things... >The driver should be able to print a page containing as many as >20,000 {\tt DVI} characters. Of course, on some devices it might be necessary to combine adjacent glyphs in order to do this. >\subsubsection{Font numbers} >The driver should be able to accept font numbers (the parameter >$k$ given by the {\it fnt\_def\/} command) in the range $0\le >k<256$. This encourages implementors to use a single byte for this... >The driver should be able to handle any document containing 64 or fewer >distinct {\tt DVI} fonts. Limits on fonts per page? >\subsection{Specials} > >The Level~0 Standard requires no support for specials. Does this mean that the standard explicitly requires that drivers must support no specials, or does it mean ``The Level~0 Standard does not require any support for specials, other than that mentioned in this section:'' >\subsection{Font formats} >The driver should be able to read {\tt PK} fonts with the What about device-native (e.g. HP Soft fonts) formats? >\subsection{The scaling number} > This is an old naming scheme derived >from the old 200~dpi No end of sentence here? >If a {\tt DVI} file requests a magnification within 2\,\% of a >supported magnification, the driver should use that font without >warning. Should `should' here be `may' (i.e. it is permitted but not required)? Lee -- Liam R. E. Quin, lee@sq.com, {utai,utzoo}!sq!lee, SoftQuad Inc., Toronto Nicholas: [...] The best/ Thing we can do is to make wherever we're lost in Look as much like home as we can. [Christopher Fry, The Lady's Not For Burning] ========================================================================= Date: Thu, 30 Aug 90 18:43:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: The Level 0 Draft standard (v 0.03) -- Request for comments >From: lee@sqarc.sq.COM >Just a few very minor points. All questions I ask here are rhetorical, >I'm not looking for answers, just pointing out some things... >>The driver should be able to print a page containing as many as >>20,000 {\tt DVI} characters. >Of course, on some devices it might be necessary to combine adjacent >glyphs >in order to do this. True. Actually this portion of the standard is likely to be slightly amended since the complexity indicated is somewhat beyond that possible on certain output devices (e.g., the HP Laserjet IIp with no extra memory). >>\subsubsection{Font numbers} >>The driver should be able to accept font numbers (the parameter >>$k$ given by the {\it fnt\_def\/} command) in the range $0\le >>k<256$. >This encourages implementors to use a single byte for this... Well, since some drivers don't even reach this level right now... in any event, TeX uses a single byte for this information. >>The driver should be able to handle any document containing 64 or >fewer >>distinct {\tt DVI} fonts. >Limits on fonts per page? No, a specification of minimum support. >>\subsection{Specials} >> >>The Level~0 Standard requires no support for specials. >Does this mean that the standard explicitly requires that drivers >must support no specials, or does it mean >``The Level~0 Standard does not require any support for specials, other > than that mentioned in this section:'' The latter. >>\subsection{Font formats} >>The driver should be able to read {\tt PK} fonts with the >What about device-native (e.g. HP Soft fonts) formats? Drivers _can_ read other formats if they choose, but they *must* support PK files. >>\subsection{The scaling number} >> This is an old naming scheme derived >>from the old 200~dpi >No end of sentence here? Yeah, that's been fixed already. Embarrassing, isn't it? >>If a {\tt DVI} file requests a magnification within 2\,\% of a >>supported magnification, the driver should use that font without >>warning. >Should `should' here be `may' (i.e. it is permitted but not required)? No, it's actually "must". The amount has been reduced to (I think) 0.2% and is intended to account for certain rounding errors that occur e.g., when cmr10 at 10.95pt is requested in a document with \magnification=1095. -dh ========================================================================= Date: Fri, 31 Aug 90 10:11:39 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: checksums of DVI files A while ago I had sent a `request for feedback', if checksums of 0 should be ignored. I still would appreciate them -- this theme should be covered in the standard (if the driver should issue warnings etc.) I know of a lot of drivers which do not recognize checksums anyway. This must be forbidden. Joachim ========================================================================= Date: Fri, 31 Aug 90 13:17:44 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: checksums of DVI files In-Reply-To: Message of Fri, 31 Aug 90 10:11:39 MES from On Fri, 31 Aug 90 10:11:39 MES said: >A while ago I had sent a `request for feedback', if checksums of 0 >should be ignored. I still would appreciate them -- this theme should >be covered in the standard (if the driver should issue warnings etc.) > >I know of a lot of drivers which do not recognize checksums anyway. >This must be forbidden. > > Joachim I agree that Level 0 should include comments regarding comparing font checksums. Printing a warning for mismatched checsums and continuing is an appropriate action. For the question of what to do if one or both checksums are zero: The normal suite of TeX/TeXware and MF/MFware programs are always careful to compute and copy checksums. A zero-exception rule would not be meaningful: if one checksum is zero, both will be zero. However, there is no reason that other programs could not be written to output DVI files. It is possible that these programs may not have access to a font checksum and would therefore write zero for that checksum. A zero-exception rule would be needed for these programs. Therefore, I suggest that the zero-exception rule be retained and any conflicts between different format descriptions should be resolved. ---Tom Reid ========================================================================= Date: Fri, 31 Aug 90 19:51:18 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Re: checksums of DVI files In-Reply-To: <3FBA07768E1F40123A@CC.UTAH.EDU> ***************************************************************** ***************************************************************** ** I will be out of the country the entire month of September. ** ** Because my mail volume is large, it will take several weeks ** ** in October just to catch up. Please do not expect to ** ** correspond with me until November. ** ***************************************************************** ***************************************************************** Tom Reid writes: >>... >> For the question of what to do if one or both checksums are zero: >> The normal suite of TeX/TeXware and MF/MFware programs are always >> careful to compute and copy checksums. A zero-exception rule >> would not be meaningful: if one checksum is zero, both will be >> zero. >>... This is not necessarily so; it is common for users to generate the .dvi file with TeX on one machine, and process it on another. The fonts (and their checksums) can be different on the two machines. I do agree that the case of 0 checksums is unlikely in fonts and .dvi files generated by standard TeXware and MFware; however, there do exist other programs, unrelated to TeX, that output .dvi format (one such was cited recently on this list). -------