========================================================================= Date: Mon, 2 Jul 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: Does margin-of-error imply a directory/file search? > 2. I wonder if any driver will allow a deviation of 2% to AN EXISTING > MAGNIFICATION. This means that > > EVERY DRIVER MUST DO A DIRECTORY/FILE SEARCH !! Here is a basic algorithm for a level 0 driver allowing the 2% deviation that requires no directory/file search: 1. Attempt to open file at calculated size (s) 2. If successful goto step 9 3. Calculate l = .98s and u = 1.02s 4. Loop through list of supported magnifications to see if any fall in range [l,u] 5. If any do, set s to that value and goto step 8. 6. Otherwise Issue a warning message and goto the missing font handler 7. Attempt to open the file. 8. If unsuccessful goto the missing font handler 9. If s is not in list of supported magnifications, add it to the list. This algorithm can be implemented in any language on any operating system (assuming that an attempt to open a non-existent file does not cause a fatal error). A quality driver will, in fact, do a directory/file search, but this is not obligatory at level 0. -dh ========================================================================= Date: Mon, 2 Jul 90 21:14:25 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, 2 JUL 90 21:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster Well, I suggest to do the following: - compute the file extension - if not found, search +/- 1 I think that would be enough...... And in particular this type of rounding error is what we want to catch. What do you guys think?! Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ========================================================================= Date: Mon, 2 Jul 90 19:23:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: rounding errors. >ell, I suggest to do the following: > - compute the file extension > - if not found, search +/- 1 > >I think that would be enough...... And in particular >this type of rounding error is what we want to catch. I had originally suggested 2% since I wasn't sure that the above algorithm would catch rounding errors consistently when the numerical part of the extension was given by 5*res*mag, but after a few trial calculations, I haven't found any cases where it's off by more than one here (Tom, could you try doing some more elaborate stuff with the rounding error program you showed me and see if you can find any errors greater than +/-1 on any variation on the extension?) Since the 2% figure was arbitrary, unless someone can find a case where the above won't find the rounding error, I'll go with that. -dh ========================================================================= Date: Mon, 2 Jul 90 21:46:52 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, 2 JUL 90 21:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster My basic idea behind this whole thing was also that the driver is NOT in the business of fixing up the user's oversights in that the user defined fonts he or she has not available. But I feel the driver must cope with the deficiencies of TeX (the magnification should be a number specified with ten or more significant digits instead of only four or so). StvB ========================================================================= Date: Mon, 2 Jul 90 19:58:57 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: rounding errors. In-Reply-To: Don Hosek's message of Mon, 2 Jul 90 19:23:00 PDT <9007030237.AA20658@Sunburn.Stanford.EDU> One problem here, folks, is the difference between the way TeX does magstep computations and the way METAFONT does. MF uses a much more accurate value (quantized to 1/65536) than TeX does (quantized to 1/1000). The higher the DPI, the higher the error. There will always be a DPI where there will be an error of 1, if there is any difference at all between METAFONT and TeX (which there certainly is, since 1.2 cannot be exactly represented as an integer multiple of 65536.) (This occurs whenever DPI * mag ^= k + 0.5, where k is an integer. In order for the error to be 2, assuming as above that rounding goes two ways, DPI * abs(mag_MF - mag_TeX) >= 1. So we calculate abs(mag_MF - mag_TeX) for the standard magsteps, and we have: Magstep Error (* 10›6) (the ceiling, for good measure) 0: 0 1/2: 444 1: 4 2: 3 3: 4 4: 407 5: 328 6: 23 7: 176 8: 181 9: 226 This fits in with our expected results, that the expected max error should be one plus the maximum quantization error, in this case the 1/2000 of TeX. So, we can expect a maximum error of (1 + floor(DPI / 2000)) At 2540, this goes up to 3, but normally 2 is sufficient. This says nothing about users who say cmr10 at 3.3 truept, of course. -tom ========================================================================= Date: Tue, 3 Jul 90 09:04:38 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Bart Childs Subject: Does margin-of-error imply ... The above note brings up one of the real problems with out efforts to create a standard. I have no problem with the statements except: * items 6 and 8 reference a missing font handler. Exactly what will it do? If it finds a substitute and proceeds then we have joined the world of desk-top-publishers and (likely) low quality documents. The point is that if substitutions are done, then two things must happen: 1) the setting of each character in a substituted font must be preceeded by the setting of the position it should be placed rather than relying upon the normal movement due to the setting of the previous character. 2) some kind of strong warning must be dumped to the screen on interactive runs and an additional page printed that lists the font and size that could not be found and the font and size that is used as a substitute. * item 3 has a reasonable statement of ``closeness'' but if close is good enough, then again the setting of position should be repeated here (item 1) just above without 2)). I really believe that ``quality'' concerns should lead to a preference of warning and substituting cmff10 at 10truept for all missing text fonts OR Tom Rokicki's scheme of making it if the MF sources exist. I believe that many (maybe most) users will never understand what the heck is happening with our current state of messages and substituting. They will be convinced that TeX really doen (oops does) not correlate with quality. I think some kind of search should be obligatory at level 0, I do not think that font substitution should ever be obligatory, it should be an option. Bart ========================================================================= Date: Tue, 3 Jul 90 09:11:20 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Bart Childs Subject: Rounding Errors I have to sound like being against everything. The extensions for fonts should never have that archaic 5* in it. AM fonts are gone or should be. The extension should be like done in MF or should be magsteps like 0, h, 1, ... I know that h is a poor substitute for half and at 10 we encounter some problems. MS-DOS is the best reason for the 0, h, ... The BIG reason for abandoning the 5* is to try to make things logical. Consider the poor user out there by him(her)self. dpi1643 is more misleading than dpi329. Both are lies. While we have the chance let's try to make it believable not what we hackers can memorize. The 2% or whatever is arbitrary and a reasonable number in my mind. Bart ========================================================================= Date: Tue, 3 Jul 90 09:14:32 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Bart Childs Subject: Driver should NOT fix user oversights I think StvB is correct in this point. On the deficiency of TeX, the driver also cannot make up for the limited precision that comes through in the DVI file. Bart ========================================================================= Date: Tue, 3 Jul 90 13:09:00 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Driver should NOT fix user oversights In-Reply-To: Message of Tue, 3 Jul 90 09:14:32 CDT from I agree with Stephan and Bart that the code within the driver should only be responsible for accounting for roundoff and precision problems in how TeX, MF, and the DVI file represent scaling information. Tom Rokicki did a good analysis of part of the problem; however, it did not cover all the sources of error. These sources include: o TeX uses magnifications expressed as 1000, 1095, etc. while MF uses more accurate numbers (as indicated by Tom Rokicki). o When constructions like \font\whatever=cmr10 scaled\magstephalf are used, TeX incorporates its approximation of the magnification into the design size of the font. In this case, the numbers which show up in the DVI file indicate font cmr10 with an "atsize" of 717619sp and a design size of 655360sp. This corresponds to a scaling of just slightly less than 1.095 (about 1.094999695) due to rounding and precision error. o A global magnification (through \magnification) goes into the DVI file using TeX's scale factor. (Ie, 1095 is used for \magnification= \magstephalf.) o A global magnification should be multiplied by each font's "atsize" to determine the actual "atsize." This combines TeX's "exact approximation" (global mag) with an "approximate aproximation." The result is more rounding error. A particularly bad situation exists when both magnifications are \magstephalf. In theory, the result should be a \magstep1 font. However, the numbers work out as follows: -- for \magnification=1095 \font\test=cmr10 scaled 1095, the driver will combine this as: floor ((717619 * 1095 + 500) / 1000) = 785793. -- for \magnification=1000 \font\test=cmr10 scaled 1200, the driver will combine this as: floor ((786432 * 1000 + 500) / 1000) = 786432. The difference between these two is 639sp. If these two numbers are converted to "dpi" values for use in a file name using the formula: dpi = atsize / designsize * res the respective dpi values will be 359.7 and 360.0 for a 300 dpi device. These would likely both be rounded to 360 dpi, so no problem would occur. However, at 2540 dpi, the values are 3045.5 and 3048.0, respectively; clearly a source of a problem. Thus, the sources of error are: TeX's low precision which can be compounded to a second level versus MF's higher precision. Rokicki's analysis showed an error on the order of 0.1% of the resolution. Doubling this for a product of two approximate numbers gives an error of about 0.2% of the resolution. At 300dpi, this is +/- 1dot; at 2540dpi, it becomes +/- 5dots. Perhaps a complete analysis of the errors is called for, but I suspect that it will give similar results. Allowing a 2% error is overdoing matters by about one order of magnitude. Since the number of values to be tested is sufficiently small with a 0.2% range, a more appropriate algorithm is something like: static int offset[11] = {0, 1, -1, 2, -2, 3, -3, 4, -4, 5, -5}; int dpi, i, n_values, found; dpi = ComputeDPIValue (...); n_values = 2 * ceil (resoultion * 0.02) + 1; found = 0; for (i = 0; i < n_values; i++) { if (OpenFont (..., dpi + offset[i])) { found = 1; break; } } if ( ! found) { MissingFontRecovery (...); } ... Of course, drivers would optimize this code: the resolution for a run will (most likely) be constant throughout the run. Further, for most drivers, the resolution will never change, so "n_values" can be replaced by a constant. For the higher resolution devices, this algorithm is probably no less efficient than searching the directories. It is certainly simpler to implement! Especially if the driver supports multiple directories (one for user-defined fonts, another for group- or project-defined fonts, and one for system fonts) or if different conventions are used to build the names for different directories. Further, the algorithm is much more portable between different operating systems. ---Tom Reid ========================================================================= Date: Tue, 3 Jul 90 14:54:31 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: rounding errors I was the one who sent the mail to Don which he has forwarded to the list: > 2. I wonder if any driver will allow a deviation of 2% to AN EXISTING > MAGNIFICATION. This means that > > EVERY DRIVER MUST DO A DIRECTORY/FILE SEARCH !! It seems to me that me question has been misunderstood. I want to present the rest of my mail first: > In level 0 of the standard only the list of magnifications as > specified in section 4.3.1 is important. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%% new-style context diff (for use with patch) %%%%%%%%%%%%%%%%%%%% > > *** dvistd21.tex Mon Jul 2 16:58:38 1990 > --- dvistd2a.tex Mon Jul 2 16:25:15 1990 > *************** > *** 241,248 **** > > \subsubsection{Margin of error} > > ! If a {\tt DVI} file requests a magnification within 2\% of an > ! existing magnification, the driver should use that font without > warning. > > \subsection{Missing fonts} > --- 241,248 ---- > > \subsubsection{Margin of error} > > ! If a {\tt DVI} file requests a magnification within 2\,\% of a > ! magnification listed above, the driver should use that font without > warning. > > \subsection{Missing fonts} > As you will see the algorithm presented by Don will implement my proposed change as he does not look for ANY EXISTING MAGNIFICATION, i.e., for a magnification AVAILABLE ON DISK. He looks for a SUPPORTED magnification as described above. > 4. Loop through list of SUPPORTED magnifications to see if any fall in > range [l,u] [Emphasizing by me.] As Tom has described a rounding error may be detected by (1 + floor(DPI/2000)) * 2 + 1 tries to open a file -- that is exactly what I have named a file search. I did not want to know how it can be realized (I know because I have implemented such a beast:-) I ASKED IF IT REALLY IS IMPORTANT FOR A LEVEL 0 STANDARD ! In my opinion the algorithm described by Don is fully sufficient for a level 0 driver -- but I want to address THIS algorithm in the standard; existing and supported magnifications are two different things! To include again an other part of the original mail to Don: > In my personal opinion a sophisticated max drift algorithm is more > important than an adaptable font naming scheme [or a luxury font > lookup]. But perhaps I'm alone > in my struggle for *output* quality -- I still prefer a correct > uncomfortable program to an incorrect comfortable one. Joachim ========================================================================= Date: Tue, 3 Jul 90 15:14:59 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 ; TUE, 3 JUL 90 15:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster All of this is happening silently, right?! I mean we don't have the requirement that this is reported? Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ========================================================================= Date: Tue, 3 Jul 90 15:15:20 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: rounding errors I was the one who sent the mail to Don which he has forwarded to the list: > 2. I wonder if any driver will allow a deviation of 2% to AN EXISTING > MAGNIFICATION. This means that > > EVERY DRIVER MUST DO A DIRECTORY/FILE SEARCH !! It seems to me that me question has been misunderstood. I want to present the rest of my mail first: > In level 0 of the standard only the list of magnifications as > specified in section 4.3.1 is important. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%% new-style context diff (for use with patch) %%%%%%%%%%%%%%%%%%%% > > *** dvistd21.tex Mon Jul 2 16:58:38 1990 > --- dvistd2a.tex Mon Jul 2 16:25:15 1990 > *************** > *** 241,248 **** > > \subsubsection{Margin of error} > > ! If a {\tt DVI} file requests a magnification within 2\% of an > ! existing magnification, the driver should use that font without > warning. > > \subsection{Missing fonts} > --- 241,248 ---- > > \subsubsection{Margin of error} > > ! If a {\tt DVI} file requests a magnification within 2\,\% of a > ! magnification listed above, the driver should use that font without > warning. > > \subsection{Missing fonts} > As you will see the algorithm presented by Don will implement my proposed change as he does not look for ANY EXISTING MAGNIFICATION, i.e., for a magnification AVAILABLE ON DISK. He looks for a SUPPORTED magnification as described above. > 4. Loop through list of SUPPORTED magnifications to see if any fall in > range [l,u] [Emphasizing by me.] As Tom has described a rounding error may be detected by (1 + floor(DPI/2000)) * 2 + 1 tries to open a file -- that is exactly what I have named a file search. I did not want to know how it can be realized (I know because I have implemented such a beast:-) I ASKED IF IT REALLY IS IMPORTANT FOR A LEVEL 0 STANDARD ! In my opinion the algorithm described by Don is fully sufficient for a level 0 driver -- but I want to address THIS algorithm in the standard; existing and supported magnifications are two different things! To include again an other part of the original mail to Don: > In my personal opinion a sophisticated max drift algorithm is more > important than an adaptable font naming scheme [or a luxury font > lookup]. But perhaps I'm alone > in my struggle for *output* quality -- I still prefer a correct > uncomfortable program to an incorrect comfortable one. Joachim ========================================================================= Date: Tue, 3 Jul 90 16:12:44 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" In-Reply-To: Message of Tue, 3 Jul 90 15:14:59 LCL from On Tue, 3 Jul 90 15:14:59 LCL Stephan said: >All of this is happening silently, right?! I mean we >don't have the requirement that this is reported? > >Stephan v. Bechtolsheim Stephan, Whith DRIV-L notes arriving in quick succession, it's hard to tell which note you are replying to. My feelings are: o The algorithm to account for roundoff and precision errors should operate quietly. There is no point in informing the user that, for example, font cmr10.360pk substituted for cmr10.359pk when (1) the user generally can't do anything to correct the situation; (2) the output is still correct; and (3) there is likely no major performance degradation for making the substitution. o If the font is not found according to the above algorithm, this fact should [must?] be reported. This situation indicates that the output will be incorrect. ---Tom Reid ========================================================================= Date: Tue, 3 Jul 90 17:16:08 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 ; TUE, 3 JUL 90 16:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster > o If the font is not found according to the above algorithm, this > fact should [must?] be reported. This situation indicates that > the output will be incorrect. I agree, we should allow for the option -q (for quiet) though. Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ========================================================================= Date: Thu, 5 Jul 90 15:33:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Font mapping (This note is being sent to both the archive group and the DVI standards group... apologies for duplicates. Please direct follow-ups to the appropriate group). Nelson's comments with regard to the Xwindows stuff, while interesting, don't address the issue that Mackay, Berry, and myself have been discussing. The mechanism by which long names are mapped to short names is irrelevant. What we are working towards is the ability to say, "if you wish to use Adobe's Times Bold Italic, you should use the command \font\tbi=??? with an appropriate name ??? that will work on all systems. Thus we want to come up with a set of rules for taking a long name and reducing it to something 8 characters or less that we can adopt as standard. This relates to the TeX archive issue in that it would be nice if the PL files for device-specific fonts were named consistently across all archives. One issue that we haven't touched on is font encoding. My feeling is that with the advent of VF (standing, of course for "composite fonts" ;-), the standard PL files for device fonts should assume _no_ remapping of characters by the device driver. This still causes a problem with Adobe fonts, but I suppose we could slip in an extra character to indicate whether we're dealing with the Adobe Standard Encoding (cf the Red book) or ISO8859/1. -dh ========================================================================= Date: Fri, 6 Jul 90 12:55:05 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: bbeeton Subject: accumulated roundoff vs. level 0 driv-l-ers, after investigating the inquiry below, i took a look at the draft proposal for the level 0 standard, and couldn't be sure (without digging into dvitype, which i admit i was too lazy to do) that the problem of accumulated pixel roundoff is covered. you may be assuming it as part of 2.7.2, changes in position due to characters, but the text there isn't specific on this point. i think this is important enough to be worth an explicit mention, and i think it's a legitimate concern even at level 0. i know the topic has been discussed. -- bb -------------------- Date: Fri, 6 JUL 90 14:11:42 BST From: CHAA006@vax.rhbnc.ac.uk To: BNB <@NSFnet-Relay.AC.UK:BNB@math.ams.com> Subject: TUGBoat V11 #2 Barbara --- What happened to the kerning between the "p" and the "r" of "postprocessing" at p.205, l.10 ? "the postprocessing phase is explicitly removed from" ^^ ** Phil. ------- my reply (edited): see p 310, col 2, 2nd paragraph under "output". surprised that's all you noticed, under the circumstances. there's also a nasty kerning in "PostScript" on p 206, col 1, l 20. ------- ========================================================================= Date: Fri, 6 Jul 90 16:23:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Font mapping > > ;-), the standard PL files for device fonts should assume _no_ > > remapping of characters by the device driver. This still causes >a > > problem with Adobe fonts, but I suppose we could slip in an >extra > > character to indicate whether we're dealing with the Adobe >Standard > > Encoding (cf the Red book) or ISO8859/1. >There is a fundamental problem with Adobe fonts (as I understand >it), >that they do not have a consistent set of characters. A lot are >`guarenteed', but fonts like Times and Lucida (I know by >experiment) >have extra characters, and there are characters in some fonts >which >are not available in `vanilla' PostScript. Should there be a >recommended encoding vector for PS fonts... I'm moving this part of the discussion to the Drivel list, since it's more appropriate here. I think that yes, we should provide a recommended encoding vector for PS fonts although to think of it in such terms might be a little short-sighted. PostScript is just the tip of the proverbial iceberg. Is VF going to be an adequate solution to the problems that Unicode and ISO 10646 will pose in the future (assuming of course that there will ever be output devices which support those coding schemes). Just some thoughts for food. -dh ========================================================================= Date: Tue, 10 Jul 90 09:36:23 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Karl Berry Subject: Font mapping In-Reply-To: Don Hosek's message of Thu, 5 Jul 1990 15:33 PDT <9394B2C58B40603AB5@HMCVAX.CLAREMONT.EDU> PostScript fonts in Adobe's standard encoding can be dealt with without virtual fonts (at least if one doesn't care about the unencoded characters in the fonts). I have made up a set of pure TFM files with all the appropriate ligature and kerning (from the AFM files), and wrote some simple TeX macros so that \" and so forth still work. I didn't think it worthwhile to do the unencoded characters, because they are used so infrequently in English, and I don't write in any other language :-) karl@cs.umb.edu ========================================================================= Date: Tue, 10 Jul 90 15:48:54 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 ; TUE, 10 JUL 90 13:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster What is the state of the newest standard. Don: could you send out the TeX source code of it?! Thanks. Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ========================================================================= Date: Tue, 10 Jul 90 14:10:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: >What is the state of the newest standard. Don: could you send out >the TeX source code of it?! I've been waiting largely on Joachim Schrod's getting me the necessary items from the WEB programs to include the documentation for the various file formats in the document. I also am culling the algorithim for rounding from DVItype for inclusion. I intend to spend a couple hours tonight getting everything into shape and ready for distribution and should tomorrow or the day after be ready to mail it to this list as well as to TeXhax, UKTeX and comp.text.tex to start getting people's comments on it as it stands. That leaves us a scant 60 days for review so we'll need to work fast. I'd like to try and keep discussion centred on the standard as much as possible, if we can. -dh ========================================================================= Date: Wed, 11 Jul 90 13:49:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: Driver Standard From: IN%"platt@ccm.UManitoba.CA" "Craig Platt" 11-JUL-1990 13:45:19.70 To: Don Hosek CC: Subj: Driver Standard Received: from YMIR.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU; Wed, 11 Jul 1990 13:44 PDT Received: from ccm.UManitoba.CA by YMIR.CLAREMONT.EDU; Wed, 11 Jul 1990 13:43 PDT Date: Wed, 11 Jul 90 15:10 CDT From: Craig Platt Subject: Driver Standard To: Don Hosek Message-id: <983C39A2D9A0403DB6@YMIR.CLAREMONT.EDU> X-Envelope-to: DHOSEK Hi Don, I'm not sure where this should be sent, but I figure you could forward appropriately to the list. You could also add my name to the discussion list, if you're so inclined. ----------------------------------------------- Here are some comments on the "Draft Proposal for the ``Level 0'' DVI driver Standard" distributed at the TAM meeting. --In 2.7.2, are you assuming all devices use "pixels"? At TAM, Peter Flynn asked if anyone had done a driver for a pen plotter (DVIPEN?). Joachim Lammarsch said that at the Karlsruhe DANTE meeting, one was used to TeX a large banner (over 10 meters long). Anyway, referring to "pixels" on a rectangular grid is technology-dependent. Perhaps a better terminology would be "machine width" or "device width" or ...? --In 2.7.4 "off of" should be "off". --In 2.8.2, define "handle" and "any". Including the extreme cases listed in 2.3-2.5 and 2.7.3? I think Don Hosek said something about handling these extremes, but "not necessarily all at once". Perhaps this should be clarified. --Also in 2.8.2, what is a "DVI" font? as opposed to ...? --I think 4.1 is too strict. I think the important thing is that a user ought to be able to create and install new fonts or updates of fonts from pk or gf files, perhaps using software supplied with the driver, without having to rely on the distributor. Note that Blue Sky will supply for the asking an MPW program to convert pk files to Macintosh suitcase files. (But they dont advertise it. You have to ask.) I think there other drivers (e.g., DVI2LIST?) that dont read pk files directly, but allow conversion to a special font format. --References to "one inch" (2.7.1) and "pixels per inch" (4.2.1) are clearly arbitrary and "culturally biased", but perhaps they could be kept as a reflection of the historical origins of the TeX system (like the 223 "signature" bytes). Disclaimer: The preceding notes were scribbled while waiting out a 6 hour delay in the Dallas airport after a nearly sleepless night. Discount accordingly. --------------------------------------------------------------- Craig Platt Department of Mathematics and Astronomy BITNET: platt@uofmcc University of Manitoba ATTNET: 204-474-9832 Winnipeg, MANITOBA R3T 2N2 or 474-8703 Canada --------------------------------------------------------------- ========================================================================= Date: Thu, 19 Jul 90 18:24:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Level 0 Draft 0.03 OK, here's the draft as it stands. I'll be sending the explicit listing of the DVItype rounding algorithim separately (I'm not finished writing this up--it can't (unfortunately) simply be cut-and-pasted out of DVItype, being scattered throughout the whole program). -dh %-----Level-draft-003.tex--------------------------------------------------- \documentstyle[ltugboat,fileform,mf]{article} \title{A Draft Proposal for the ``Level~0'' {\tt DVI} Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG {\tt DVI} Driver Standards Committee}} \makeatletter \newcounter{impnote} \def\theimpnote{\alph{impnote}} \def\impnote#1{{\def\@mpfn{impnote}% \let\thempfn=\theimpnote \footnote{#1}}} \makeatother \def\tensl{\sl} \let\App=\appendix \def\appendix{\App\small} % tighten up the ending pages of the standard. \hbadness=9999 % Cut down the amount of annoying messages generated... % For file format descriptions: \def\res#1{{\bf #1}} \def\sty#1{{\it #1}} \begin{document} \maketitle \emergencystretch=\hsize \divide\emergencystretch by 10 % I think this will encourage 10 words/line \begin{abstract} The following represents a minimal standard (level~0) for {\tt DVI} drivers. The complete standard will be presented as a series of ``tiers'' requiring increasingly stringent control over the output of {\tt DVI} drivers. A trip test for {\tt DVI} drivers will be created which will allow developers of {\tt DVI} drivers to insure that their drivers meet the standards developed here. The specifications here should be considered minimal and driver developers are encouraged to write drivers whose capabilities are beyond these specifications. This version of the Level~0 Standard presented here is draft~0.03. It has been reviewed by the TUG Driver Standards Committee and is now being presented to the TUG membership at large for review. This will form one portion of the TUG {\tt DVI} Driver Standard. \end{abstract} \section{Purpose of the Level~0 standard} The Level~0 Standard is meant to be a base standard to which all drivers should adhere. It is intended to allow all reasonable applications to be printed on all drivers. The basis for many of the specifications in this standard is the possible output of \TeX82; functions which can be implemented via a pre-processor are generally omitted ({\em e.g.,\/} page selection and sorting). Footnotes beginning with a letter are implementation notes and are hints on handling difficult circumstances for printers. \section{The {\tt DVI} file} 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). \subsection{{\tt DVI} commands} The driver should be able to interpret every {\tt DVI} command listed in appendix~\ref{dvi-format}. % See file dvi.tex \subsection{Characters} \subsubsection{Number of characters in a {\tt DVI} font} The driver should be able to handle fonts which have characters at any code in the range $0\le c<256$.\impnote{Some output devices will require {\tt DVI} fonts with more than a given number of characters to be broken into two or more device fonts when downloaded to the printer.} \subsubsection[{\tt DVI} character size]{{\tt DVI} character size\footnote{The values presented here and in the following sections are preliminary and subject to modification.}} The driver should be able to print any character up to a size of 600pt (horizontal) by 800pt (vertical).\impnote{Note that some output devices will require breaking down such a character into smaller pieces or drawing the character in graphics mode.} \subsubsection{Number of {\tt DVI} characters per page} The driver should be able to print a page containing as many as 20,000 {\tt DVI} characters. \subsubsection{Unusual characters} The driver should correctly handle (a)~characters with empty bitmaps ({\em e.g.,\/} the \SliTeX\ fonts) including characters whose horizontal escapement is~0, (b)~characters whose printable image is wider than its horizontal escapement, and (c)~characters with a negative horizontal escapement. \subsection {Rules} \subsubsection{Rule size} The driver should be able to print rules of any size up to 600pt (horizontal) by 800pt (vertical). \subsection{Number of rules per page} The driver should be able to print a page containing as many as 1000~rules. \subsection{Stack} The driver should have, as a minimum, a stack depth of 100 for {\tt DVI} {\it push\/} and {\it pop\/} commands. \subsection{Positioning on the page} \subsubsection{Location of the origin} The point $(0,0)$ in {\tt DVI} co\"{o}rdinates should be located at a point one inch from the top of the page and one inch from the left side of the page. \subsubsection{Changes in position due to characters and rules} The driver should accurately track movement using the pixel width from the font raster file and the {\tt TFM} width from either the font raster file or {\tt TFM} file with the {\tt TFM} width from the font raster file taking priority. This is described in appendix~\ref{rounding-algorithim}. Positioning of rules is handled similarly with the rounding done using the algorithim in appendix~\ref{rounding-algorithim}. The {\tt TFM} format is described in appendix~\ref{tfm-format}. \subsubsection{Range of movement} The driver should be able to handle movements in the {\tt DVI} file up to a total of $2^{31}$ {\tt DVI} units in any direction from the origin. \subsubsection{Objects off of the page} Any printable object which would lie entirely off the physical page should not be printed but any changes to positioning should still be taken into consideration. Any printable object which would lie partially off the physical page should either be clipped so that portion of the object that lies off the page is not printed or omitted entirely. \subsection{Fonts} \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$. \subsubsection{Distinct {\tt DVI} fonts} The driver should be able to handle any document containing 64 or fewer distinct {\tt DVI} fonts. \subsection{Specials} The Level~0 Standard requires no support for specials. Specials not officially defined by the {\tt DVI} driver standards committee should be flagged with a warning when read from the {\tt DVI} file. If any specials are ignored by the driver, the driver must issue a warning message. \section{Configuration} It should be possible for the installer of a driver to configure such things as the location and naming scheme of fonts, default paper size, etc.\ without having to recompile the driver. \section{Font files} \subsection{Font formats} The driver should be able to read {\tt PK} fonts with the location specifiable at run time. The {\tt PK} format is given in appendix~\ref{pk-format}. {\tt GF} support is optional. The {\tt GF} format is given in appendix~\ref{gf-format}. \subsection{The scaling number} The magnification and resolution of a font are incorporated into a scaling number of one of two types: \begin{description} \item[Magnification number] The magnification number is given by $5\times {\it resolution} \times {\it magnification\/}$ where the resolution is given in dots per inch (on devices with a non-unit aspect ratio, the horizontal resolution should be used) and a magnification of 1 indicates no magnification. This is an old naming scheme derived from the old 200~dpi \item[Resolution number] The resolution number is given by ${\it resolution} \times {\it magnification}$ where both values are as above. This is the preferred specification for {\tt GF} and {\tt PK} files. \end{description} \subsection{Magnifications} \subsubsection{Minimum set of magnifications} At the minimum, the driver should be able to load fonts at the following magnifications of its target resolution: 1.0 (magstep0), 1.095 (magstephalf), 1.2 (magstep1), 1.44 (magstep2), 1.728 (magstep3), 2.074 (magstep4), 2.488 (magstep5), 2.986 (magstep6), 3.583 (magstep7), 4.300 (magstep8), and 5.160 (magstep9). However, driver authors are encouraged to support all possible magnifications. \subsubsection{Margin of error} If a {\tt DVI} file requests a magnification within 2\,\% of a supported magnification, the driver should use that font without warning. \subsection{Missing fonts} If a font is missing the driver should continue processing and deal with the missing font in one of three ways: \begin{enumerate} \item Insert appropriate white space where the font would appear, \item Insert black rectangles of the size of the font given in the {\tt TFM} file, \item Print the characters from that font at a different size or from another font at the same size after issuing a warning. \end{enumerate} If methods 1 or 2 are used and the driver is unable to locate size information for the font in question, then the driver may simply ignore any {\it set\_char\/} or {\it put\_char\/} commands that occur while the current font is that font. Under no circumstances should a missing font cause a fatal error. \appendix \input{dvi.tex} \input{gf.tex} \input{pk.tex} \input{tfm.tex} % \input{vf.tex} %Since VF files are not referenced in level 0, % this is omitted for brevity's sake. \end{document} ========================================================================= Date: Thu, 19 Jul 90 18:44:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: How we're proceeding from here Since I'd like to have the final draft of the standard finished for publication in TUGboat 11#3(or is it 4?), as I mentioned before we will need to move quickly. The way we will handle the remaining changes to be made to the level 0 standard is through an ammendment process. The following is a modified version of the ammendment process I've used in various pseudo-parliamentary groups in which I've participated: 1. The voting members are as follows: --Nelson Beebe --Bart Childs --Bernard Gaulle --John Gourlay --Robert McGaffey --Tom Rokicki --Jan Michael Rynning --Joachim Schrod --Ralph Youngen 2. Additional voting members may be added by the chair as deemed necessary. The chair will be considered a voting member, but only in the case of a tie vote. 3. Anyone may propose an ammendment, but an ammendment not proposed by one of the voting members of the group needs a second by one of the voting members of the group (voting members are listed below). An ammendment by a voting member does _not_ need a second. An ammendment should be clearly labelled as such and sent to DRIV-L@TAMVM1. If the chair does not recognize the ammendment within 36 hours of its posting, a copy should be sent directly to him (this is to cover cases of network non-functioning). 4. While an ammendment is on the floor, voting members may vote "Yes", "No" or "Abstain" a reminder will be sent out once every 36 hours for every ammendment they have not yet voted on. 5. An ammendment will be considered "on the floor" until (a) it has received (a) a number of "Yes" votes greater than half the total number of voters, (b) a number of "No" votes greater than half the total number of voters, (c) has been explicitly withdrawn by its original proposer or (d) all voting members of the group have voted on it. 6. If two ammendments are submitted which would modify the same portion of the draft, the second received at driv-l@tamvm1 will be tabled while the first is on the floor. In the event of the passage of the first, the proposer will be asked if they want to withdraw the ammendment before it is submitted for a vote. 7. All ammendments *must* be received prior to August 31 to be considered. Any ammendment still on the floor on September 8 will be considered failed. ----- I hope these procedures are clear and workable. I'm unlikely to make any changes to the procedural rules unless a problem arises. ========================================================================= Date: Thu, 19 Jul 90 19:11:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: File Format descriptions On a side note... I will *not* be distributing the file format descriptions to this list (at least not right now). They will be placed in [anonymous.tex.dvi-standard] in the near future. Since they don't have any substantive differences from the equivalent sections in the respective programs, their omission is not critical at this time. -dh ========================================================================= Date: Fri, 20 Jul 90 10:57:49 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: DVI draft #003 Don, what's the style option mf? Just the definition of the METAFONT logo? By the way, that's already covered in fileform.sty -- perhaps fileform.sty should be renamed to dvistd.sty and all additional markups needed should be put into? Joachim ========================================================================= Date: Fri, 20 Jul 90 12:16:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: DVI draft #003 My definition of \MF requires Frank & Rainer's font selection macros and has some neat features like automatically bolding or slanting to match the surrounding text. It also resizes itself to match the surrounding text which your definition does not. (As an aside each of the three style options defines \MF(!)). The file as it stands can be run through LaTeX with simply \documentstyle[ltugboat]{article} and commenting out the \input statements for the appendices. Anyone who wants my mf.sty may obtain it by FTPing it from ymir.claremont.edu in [anonymous.tex.inputs.latex-contrib] or sending a message to mailserv@ymir.claremont.edu containing the line SEND [TEX.INPUTS.LATEX-CONTRIB]MF.STY -dh ========================================================================= Date: Sat, 21 Jul 90 17:50:21 -0700 Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Tomas G. Rokicki" Subject: How we're proceeding from here In-Reply-To: Don Hosek's message of Thu, 19 Jul 90 18:44:00 PDT <9007200201.AA01923@Sunburn.Stanford.EDU> I'll pass it as is . . . -tom ========================================================================= Date: Sun, 22 Jul 90 13:30: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 Date: Sun, 22 Jul 90 11:42:22 CDT From: mcdonald@aries.scs.uiuc.edu (Doug McDonald) Subject: RE: The Level 0 Draft standard (v 0.03) -- Request for comments In article <7895@jarthur.Claremont.EDU> you write: >Below is the Level 0 standard (draft 0.03) which will be in its >final form for publication in the last regular issue of TUGboat >for 1990. > I agree except for one EXTREMELY IMPORTANT point, and one quibble. > >\subsection{Number of rules per page} > >The driver should be able to print a page containing as many as >1000~rules. > This should be 20,000, just as for characters. Gnuplot generates Latex files with that many rules, and more. This is very important. This should be always doable, as they can always be done by making a font of rules, - and you already specify 20000 characters. Perhaps you might want to specify a maximum total number of rules and characters, say 30000. > >\subsubsection{Location of the origin} > >The point $(0,0)$ in {\tt DVI} co\"{o}rdinates should be located >at a point one inch from the top of the page and one inch from >the left side of the page. > This brings up the question of screen previewers. Presumably they will have a virtual page, panned around on, for most size screens. It might not be desirable to have the default 0,0 at one inch from the physical corner of the window, as this wastes valuable space. It might be good to add that this would apply to the virtual page. Doug McDonald ========================================================================= Date: Sun, 22 Jul 90 13:32: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 >The driver should be able to print a page containing as many as >1000~rules. > This should be 20,000, just as for characters. Gnuplot generates Latex files with that many rules, and more. This is very important. This should be always doable, as they can always be done by making a font of rules, - and you already specify 20000 characters. Perhaps you might want to specify a maximum total number of rules and characters, say 30000. The problem is that on some output devices (e.g., the Xerox printers), rules are more expensive than characters. A rule .5pt wide, 14pt high and 2pt deep can take a surprising number of characters to print. -dh ========================================================================= Date: Sun, 22 Jul 90 14:37:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Specification of algorithim for handling rounding to device units (v0.01) -- Request for Comments \documentstyle{article} \begin{document} \def\abs{{\rm abs}} \def\DVI{{\tt DVI}} \section{Handling rounding to device units---modified {\tt DVItype} algorithim} The algorithims presented here are adapted from {\tt DVItype}; they represent the base algorithim for handling rounding of co\"ordinates and widths of objects to device units. \subsection{Rounding \DVI\ units to device units} Whenever it is necessary to round some dimension given in \DVI\ units to the corresponding quantity in device units\footnote{For raster-oriented devices, this would be the distance between spots in the output. For other devices, this refers to the minimum addressable distance change, {\em e.g.,\/} on a pen-plotter, it would be the minimum pen step. Device units do not necessarily correspond to dot size and this distinction should be respected in writing a \DVI\ driver.} the conversion should be done as $\lceil Kn\rceil$ where $n$ is the dimension in \DVI\ units and $K$ is a constant which converts from \DVI\ units to device units.\footnote{Devices with non-unit aspect ratios will need to maintain separate constants for vertical and horizontal dimensions.} This description will use ${\it pixel\_round}(n)$ to refer to $\lceil Kn\rceil$. \subsection{Keeping track of the current horizontal and vertical position} The definition of \DVI\ files refers to six registers, $(h,v,w,x,y,z)$, which hold integer values in \DVI\ units. In practice, we also need registers ${\it hh}$ and ${\it vv}$, the pixel analogs of $h$ and $v$, since it is not always true that ${\it hh}={\it pixel\_round}(h)$ or ${\it vv}={\it pixel\_round}(v)$. Whenever the \DVI-reading program encounters an instruction that changes the current position, it should update $h$ and $v$ using pure \DVI\ units. If the change in position is due to a {\it set\_char} command, the driver should add the x-escapement value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the new value for $hh$. 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. For a vertical movement, ${\it vv}$ is set similarly except that $\it vv$ is set to ${\it vv}+{\it pixel\_round}(y)$ if $-0.8{\it quad}{\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. \end{document} ========================================================================= Date: Sun, 22 Jul 90 14:43:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list Comments: W: Invalid RFC822 field -- "SPECIFICATION OF ALGORITHIM FOR HANDLING ROUNDING TO DEVICE UNITS (V0.01) -- REQUEST FOR COMMENTS:". Rest of header flushed. From: Don Hosek Subject: Notes on: Under separate cover has been sent the outline of the algorithim for handling rounding to device units for the Level 0 DVI driver standard. It differs from the DVItype algorithim in three significant ways: (1) the distances where hh and vv are set to pixel_round(h) and pixel_round(v) have been changed slightly; (2) the check for whether maxdrift correction should be applied has been modified slightly to give slightly better results in some cases (suggestion courtesy John Hobby). (3) max_drift has been given a more specific value. Again, comments are requested, please send them to dhosek@ymir.claremont.edu -dh ========================================================================= Date: Sun, 22 Jul 90 15:04:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Ammendment: Change margin of error tolerance (S4.3.2) Currently says: If a DVI file requests a magnification within 2% of a supported magnification, the driver should use that font without warning. Change to read: If a DVI file requests a magnification within 0.2% of a supported magnification, the driver should use that font without warning. Reason for change: In discussion on DRIV-L, it was shown that rounding errors would not cause a variation greater than 0.2% (and that only in extreme cases at high resolutions). Tom Reid, in his mail of 3-July-1990 gives the numerical proof of this as well as a simple algorithim for handling locating the font when calculations are off slightly as indicated. The purpose of the rounding error calculation is *not* to do things like take care of the case where a user requested cmr10 at 11pt instead of cmr10 at 10.95pt. ========================================================================= Date: Sun, 22 Jul 90 15:34:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Notes on appendices For reference purposes, the appendices of the DVI standards document are: A Device-independent file format B Generic font file format C Packed file format D Font metric data E Handling rounding to device units--modified DVItype algorithim -dh ========================================================================= Date: Sun, 22 Jul 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: Ammendment: Change padding to end of DVI files (appendix A) Currently says: This curious way to finish off a DVI file makes it feasible for DVI-reading programs to find the postamble first, on most computers, even though TeX wants to write the postamble last. Most operating systems permit random access to individual words or bytes of a file, so the DVI reader can start at the end and skip backwards over the 223's until finding the identification byte. Change to read: This curious way to finish off a DVI file makes it feasible for DVI-reading programs to find the postamble first, on most computers, even though TeX wants to write the postamble last. Most operating systems permit random access to individual words or bytes of a file, so the DVI reader can start at the end and skip backwards over any 0's that may have been added to the end | of the file due to file transfers, then skip over the 223's | until finding the identification byte. [vertical bars indicate the changed portion] Reason for change: As noted above, when moving files between computers, additional 0's may be tacked on to the end of the file due to file transfers. This modification to the DVI file format requires drivers to deal with this appropriately. ========================================================================= Date: Sun, 22 Jul 90 15:54:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Addendum to ammendment on DVI format: Also to be changed as part of the ammendment to the DVI format is the "picture" of the postamble. Was: post p[4] num[4] den [4] mag [4] l[4] u[4] s[2] t[2] post_post q[4] i[1] 223's [>=4] Change to: post p[4] num[4] den [4] mag [4] l[4] u[4] s[2] t[2] post_post q[4] i[1] 223's [>=4] 0's [>=0] This is still part of ammendment 2. ========================================================================= Date: Sun, 22 Jul 90 16:08:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Ammendment: Change padding to end of GF files (appendix B) Currently says: post p[4] ds[4] cs[4] hppp[4] vppp[4] min_m[4] max_m[4] min_n[4] max_n[4] post_post q[4] i[1] 223's[>= 4] [and later] Most operating systems permit random access to individual words or bytes of a file, so the GF reader can start at the end and skip backwards over the 223's until finding the identification byte. Then it can back up four bytes, read q, and move to byte q of the file. Change to read: post p[4] ds[4] cs[4] hppp[4] vppp[4] min_m[4] max_m[4] min_n[4] max_n[4] post_post q[4] i[1] 223's[>= 4] 0's [>=0] | [and later] Most operating systems permit random access to individual words or bytes of a file, so the GF reader can start at the end and skip backwards over any 0's inserted due to file transfer then | skip over the 223's until finding the identification byte. Then it can back up four bytes, read q, and move to byte q of the file. [vertical bars indicate the changed portion] Reason for change: As noted above, when moving files between computers, additional 0's may be tacked on to the end of the file due to file transfers. This modification to the GF file format requires drivers to deal with this appropriately. ========================================================================= Date: Sun, 22 Jul 90 16:25:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Ammendment: Change padding to end of PK files (appendix C) Currently says: pk_post 245 Beginning of the postamble. This command is followed by enough pk_no_op commands to make the file a multiple of four bytes long. Zero through three bytes are usual, but any number is allowed. This should make the file easy to read on machines which pack four bytes to a word. Change to read: pk_post 245 Beginning of the postamble. This command is followed by enough pk_no_op commands to make the file a multiple of four bytes long. Zero through three bytes are usual, but any number is allowed. This should make the file easy to read on machines which pack four bytes to a word. The pk_no_op commands may further be | followed by a number of 0's which will be a multiple of 4 (these | are generally added during a file transfer operation). | PK-writing programs should never add 0's to the end of the file. | [vertical bars indicate the changed portion] Reason for change: As noted above, when moving files between computers, additional 0's may be tacked on to the end of the file due to file transfers. This modification to the PK file format requires drivers to deal with this appropriately. - ========================================================================= Date: Mon, 23 Jul 90 16:07:32 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: home position of previewers > This brings up the question of screen previewers. Presumably they > will have a virtual page, panned around on, for most size screens. > It might not be desirable to have the default 0,0 at one inch > from the physical corner of the window, as this wastes valuable space. > It might be good to add that this would apply to the virtual page. No. Previewers are used for two purposes: (i) To proofread the text. Here the author wants to see the whole text width on the screen. (ii) To check the layout. Here the author wants to see how the text is placed on a sheet of paper. This leads to the concept that the corner of the virtual page and the home position on the screen is distinct. The user should be able to specify his home position on startup, but the placement of the text on the virtual page should be the same as with the printer driver. There are a lot of good previews out there with this concept. Let's stay with it. Joachim ========================================================================= Date: Mon, 23 Jul 90 12:36:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: The Level 0 Draft standard (v 0.03) -- Request for comments Date: Mon, 23 Jul 90 12:40:16 PDT From: cwitty@csli.Stanford.EDU (Carl Witty) Subject: The Level 0 Draft standard (v 0.03) -- Request for comments The draft DVI standard seems to require that if a DVI driver supports a \special which is not standardized, it must issue a warning when the user uses that \special. Is this correct? I would prefer that the driver not issue warnings unless it finds a \special it doesn't know how to handle. Carl Witty cwitty@cs.stanford.edu ========================================================================= Date: Mon, 23 Jul 90 12: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 >The draft DVI standard seems to require that if a DVI driver supports >a \special which is not standardized, it must issue a warning when the >user uses that \special. Is this correct? I would prefer that the >driver not issue warnings unless it finds a \special it doesn't know >how to handle. Yes, that in fact is correct. In the short run, it may seem annoying, but it will stop being the case once the base set of \special commands has been defined by the driver standards committee has been defined. I would expect that once the standard \specials are defined, driver authors will probably retain their old \specials temporarily for compatibility purposes, but it would be preferrable that people use the new \specials. Rather than change the level 0 standard at that point, I'd just as soon have the requirement for the warning now. -dh ========================================================================= Date: Mon, 23 Jul 90 16:49:38 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Ammendment: Change margin of error tolerance (S4.3.2) In-Reply-To: Message of Sun, 22 Jul 90 15:04:00 PDT from On Sun, 22 Jul 90 15:04:00 PDT Don Hosek said: >Currently says: >If a DVI file requests a magnification within 2% of a supported >magnification, the driver should use that font without warning. > >Change to read: >If a DVI file requests a magnification within 0.2% of a supported >magnification, the driver should use that font without warning. I agree with this change. However, there are still some problems with the wording: What is meant by "that font"? Presumably, it should be "the supported magnification." Also, I propose another change: For items of this sort, the guidelines should state the problem which is to be overcome. In this case, the wording could be something like: TeX and METAFONT compute font magnifications with different precisions. Further, calculations done by TeX and/or a DVI driver are subject to roundoff errors. As a method of accomodating these differences, if the magnification requested for a font is within 0.2% of a supported magnification, the driver should use the supported magnification without warning. The problem statements do not need to give the details, but they do need to make clear what is trying to be accomplished. This is important so that a driver author does not interpret the workaround as being a solution to something else. Also, the wording "As a method of ..." leaves open the possiblility of other workarounds for the problem which, while correcting for the stated problem, may not be compliant with the suggested workaround. The goal of these guidelines should be to resolve problems. ---Tom Reid ========================================================================= Date: Mon, 23 Jul 90 15:09: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 Date: Mon, 23 Jul 90 15:11:13 PDT From: Carl Witty Subject: RE: The Level 0 Draft standard (v 0.03) -- Request for comments To: Don Hosek Yes, but what if the DVI driver implements a \special that you don't standardize? Are you going to standardize all of the following: * colored text, by name of color * colored text, by RGB * inclusion of printer commands for arbitrary printers (not only postscript) * conditionals (if printing on a color printer, print the following in red; else print it in italics) * specials to define the user interface of a previewer (as in Grunwald's Xtex, which has extensions for hypertext links) * printer paper specification ("Please print this on paper that's at least 11x14--that's the paper size this was formatted for") * a "today" special--print the current date at the current position in the current font ? All of the above seem like they could be useful, and if somebody's DVI driver supports them and somebody else writes documents that use them, it doesn't seem like that DVI driver should be required to give warnings. However, I doubt if you will standardize all of the above functionality. (If you are planning to standardize all possible specials that anybody proposes--that is, become a registry for specials--then this objection loses its force.) Carl Witty cwitty@cs.stanford.edu ========================================================================= Date: Mon, 23 Jul 90 15:31: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 >Yes, but what if the DVI driver implements a \special that you don't >standardize? Are you going to standardize all of the following: >* colored text, by name of color yes. >* colored text, by RGB Yes. >* inclusion of printer commands for arbitrary printers > (not only postscript) Yes. More than that, a set of graphics primitives will be provided. >* conditionals (if printing on a color printer, print the following in > red; else print it in italics) Conditionals of some sort will probably be implemented BUT, the particular example you indicated should be handled by TeX (after all, the font metric information will be different) >* specials to define the user interface of a previewer (as in > Grunwald's Xtex, which has extensions for hypertext links) We haven't debated this point, but we'll probably standardize it. It's a sufficiently desirable application that it would be nice if the same special would be used for any device that handled hypertext extensions. >* printer paper specification ("Please print this on paper that's at > least 11x14--that's the paper size this was formatted for") more than that... please print this on Pebble-grained light blue A4 paper in inverse portrait orientation with an imagable area of the whole sheet less 1/8" on each side. >* a "today" special--print the current date at the current position > in the current font Possibly. >All of the above seem like they could be useful, and if somebody's DVI >driver supports them and somebody else writes documents that use them, >it doesn't seem like that DVI driver should be required to give >warnings. However, I doubt if you will standardize all of the above >functionality. Why not? Isn't the whole point of DVI standards to enforce uniformity across all drivers? I'd look at the list above as a rather minimal list of functionality. >(If you are planning to standardize all possible specials that anybody >proposes--that is, become a registry for specials--then this objection >loses its force.) I wouldn't say that we'd standardize anything someone proposes, but I would hope that our special standard is comprehensive enough to cover most cases. -dh ========================================================================= Date: Mon, 23 Jul 90 17:45:25 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: DVI origin ( from Level 0 Draft 0.03) In-Reply-To: Message of Thu, 19 Jul 90 18:24:00 PDT from On Thu, 19 Jul 90 18:24:00 PDT Don Hosek said: >\subsubsection{Location of the origin} > >The point $(0,0)$ in {\tt DVI} co\"{o}rdinates should be located >at a point one inch from the top of the page and one inch from >the left side of the page. In Klaus Guntermann's and Joachim Schrod's paper "High Quality DVI Drivers" presented at TeX88 (and posted to DRIV-L in January 89), they state: \item Placement of the output on the page: values for top and left margin. The default margins must depend on the paper format. In the US the standard margins are 1\,in for legal paper. For the European A4 paper 2\,cm margins have proved reasonable. What is the current position of the non-US users of TeX concerning the location of point (0, 0)? ---Tom Reid ========================================================================= Date: Mon, 23 Jul 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: Re: DVI origin ( from Level 0 Draft 0.03) Tom Reid said: >On Thu, 19 Jul 90 18:24:00 PDT Don Hosek said: >>\subsubsection{Location of the origin} >> >>The point $(0,0)$ in {\tt DVI} co\"{o}rdinates should be located >>at a point one inch from the top of the page and one inch from >>the left side of the page. >In Klaus Guntermann's and Joachim Schrod's paper "High Quality DVI >Drivers" >presented at TeX88 (and posted to DRIV-L in January 89), they state: > \item Placement of the output on the page: values for top > and left margin. The default margins must depend on the > paper format. In the US the standard margins are 1\,in for > legal paper. For the European A4 paper 2\,cm margins have > proved reasonable. >What is the current position of the non-US users of TeX concerning >the location of point (0, 0)? At level 1, we can make the position settable. LaTeX users generally have some extra margin anyway and deal with it appropriately. the 1in,1in is awkward, but no more awkward than any non-zero default offset. What I generally do is something along the lines of: \oddsidemargin=2cm \advance\oddsidemargin=-1in (and similar things for other margins being set). -dh ========================================================================= Date: Tue, 24 Jul 90 09:23:03 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 on specials > Conditionals of some sort will probably be implemented BUT, the > particular example you indicated should be handled by TeX (after all, > the font metric information will be different) > > [...some lines deleted...] > > >* a "today" special--print the current date at the current position > > in the current font > > Possibly. No. With the same reason as explained above by Don. A driver should not be forced to handle kernings and all such stuff -- let's use TeX for such purposes. If you just align characters you will get horrible results. A similar problems occurs while producing sheet numbers (in German: `Bogensignaturen') on book sheets. Please note that book sheets are in almost no case identical with book pages. On one sheet are many pages which are not placed side by side but in a way that will result in the correct order after the sheet is folded. You will find those numbers if you look at bound books. What you don't see then are small rules on the folded border of the sheet which mark the relative position of the sheet for the bookbinder (in German: `Flattermarken'). This looks the following way: -------------------------------------------------- sheet 1 MMMMMMMMMM -------------------------------------------------- sheet 2 MMMMMMMMMM -------------------------------------------------- sheet 3 MMMMMMMMMM -------------------------------------------------- sheet 4 MMMMMMMMMM -------------------------------------------------- (The M's are the rules.) This allows the bookbinder to see with one look if the sheets are in the correct order. That's all the same matter: How to print stuff somewhere out of pages. Well the solution is easy: Just let TeX prepare those stuff (e.g., the date or the sheet numbers) and support the merging of many pages (i.e., allow to place them freely -- perhaps with rotation -- on one sheet). > >(If you are planning to standardize all possible specials that anybody > >proposes--that is, become a registry for specials--then this objection > >loses its force.) > > I wouldn't say that we'd standardize anything someone proposes, but I > would hope that our special standard is comprehensive enough to cover > most cases. Yes, but remember one special which was not mentioned: The inclusion of device specific printing commands. (E.g., this is necessary for the inclusion of the output of many drawing systems; users at our University are very happy with the possibility to include graphics made with AutoCad, CorrellDraw, Tell-A-Graph, or similar systems.) Joachim P.S.: Does anybody know the English terms for `Bogensignaturen' or `Flattermarken'? I would be happy to learn them. }i ========================================================================= Date: Tue, 24 Jul 90 09:40:46 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: global specials A while ago, on the 19th May, Don has sent the following mail which I include in full to get the context: > We need to resolve the global \special syntax issue. There are several > alternatives that have been posed: > > (1) On the first page, preceded by the tag global: e.g., > \special{global: rotate 5898240} %5898240=90*65536 > PROS: Easy to implement from a TeX point of view. > CONS: Requires scanning the whole first page for specials. However, this > code > is not too difficult to write and will be necessary if we allow a > special affecting a page to appear anywhere on that page. > (2) On the first page, delimited by some pair of specials: > \special{beginglobals} > \special{rotate 5898240} > \special{endglobals} > PROS: easy for driver to know when to stop looking for globals > CONS: harder to implement than above syntax from TeX side plus the bulk of > cons for (1) > (3) On a page containing no other material > a. With the first special marking that page as a global specials page. > b. With that page marked by having a special page number. > COMMENTS: easy to parse from a DVI standpoint, however, one must know when > the last global has occurred or the document has begun which can be > difficult to implement under LaTeX. Also, the extra page can look ugly > > Discussion on this? I still recommend method 3a. It's very easy and efficient to parse from the drivers point of view AND IT'S VERY EASY TO IMPLEMENT IT IN LaTeX, if all global specials are given on the first page -- but they should be given at the start of a document anyhow because they concern the whole document. Principle LaTeX (and Plain) implementation algorithm: \nowtoks\global_special_toks \def\global_special#1{% } \let\@output=\output \def\output{% \shipout\vbox{\the\global_special_toks}% } Joachim ========================================================================= Date: Tue, 24 Jul 90 06:12:31 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Jan Michael Rynning Subject: Re: DVI origin ( from Level 0 Draft 0.03) In-Reply-To: Your message of Mon, 23 Jul 90 17:45:25 CDT Tom Reid asks: >What is the current position of the non-US users of TeX concerning >the location of point (0, 0)? Everyone that I'm aware of puts (0,0) 25.4 mm (1 inch) from the top and left hand margin of the paper, and some of them put things like \hoffset=-5.4(true)mm \voffset=-5.4(true)mm into their TeX files (or, more likely, into their format files). The natural thing would be to put (0,0) at the top left hand corner of the paper, and set hoffset and voffset to 25.4 mm in PLAIN.TEX, but for compatability reasons I think we should leave things the way they are: The default origin for the device drivers should be 25.4 mm from the top and left hand margin of the paper. One more thing, about inches and mm: Could you please make clearer what you mean by "1 inch", by adding "(25.4 mm)". An inch is not the same in all countries, and even the length of the U.S. inch has changed over the years. 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: Tue, 24 Jul 90 16:34:48 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: DVI origin ( from Level 0 Draft 0.03) > Tom Reid asks: > >What is the current position of the non-US users of TeX concerning > >the location of point (0, 0)? > > Everyone that I'm aware of puts (0,0) 25.4 mm (1 inch) from the top > and left hand margin of the paper, and some of them put things like > \hoffset=-5.4(true)mm \voffset=-5.4(true)mm > into their TeX files (or, more likely, into their format files). In our driver family the origin is installable (and changable at run time, of course); in Europe we use 2cm as the distributed default. I fully agree with Don Hosek that at level 0 the margin should be (1in,1in) and at some higher level it should be changeable. Joachim ========================================================================= Date: Tue, 24 Jul 90 16:52:28 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Specification of algorithim for handling rounding to device units (v0.01) -- Request for Comments In-Reply-To: Message of Sun, 22 Jul 90 14:37:00 PDT from On Sun, 22 Jul 90 14:37:00 PDT Don Hosek said: >\section{Handling rounding to device units---modified {\tt > DVItype} algorithim} > >The algorithims presented here are adapted from {\tt DVItype}; >... I applaud the use of the modified DVItype max drift algorithm as developed earlier on DRIV-L. However, the algorithm as presented here does not correctly reflect the algorithm which was derived. I have included the offending sections and give the corrections. >The definition of \DVI\ files refers to six registers, >$(h,v,w,x,y,z)$, which hold integer values in \DVI\ units. ... You seem to imply that hh and vv need to be stacked along with the other six variables. They do; this should be stated explicitly. >Whenever the \DVI-reading program encounters an instruction that >changes the current position, it should update $h$ and $v$ using >pure \DVI\ units. ... This is correct, but in the case of SET_CHAR commands, it should explicitly state that h should be increased by the TFM width from the PK or GF file (or optionally, the TFM file). Processing horizontal and vertical movements: >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. ... This is one point of confusion and/or error. The variable x (1) has either not been defined, or (2) is assumed to be the same as the x in (w,x,y,z). In the case of (1), the algorithm is not clear. In the case of (2), it is wrong: TeX uses Wn, Xn, and RIGHTn commands for horizontal motion. The above algorithm for updating hh should be done for all horizontal motions, not just for that produced by Xn commands. It would be best to use different variables for x and y or clearly define each at the start of the respective paragraphs so that they will not be confused with the x and y registers. >For a vertical movement, ${\it vv}$ is set similarly except that >$\it vv$ is set to ${\it vv}+{\it pixel\_round}(y)$ if $-0.8{\it >quad}otherwise. ... A similar argument applies here: "y" should be defined as the vertical distance indicated by the command. The drift correction step: >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$. No! Adding/subtracting max_drift to/from hh causes a motion by max_drift pixels. This is *not* what DVItype says to to and not what the DRIV-L algorithms did. When I first read Guntermann's and Schrod's changes to the max drift algorithm, I interpretted the DVItype algorithm as doing what Don says. I seem to recall that Guntermann and Schrod did as well since the correction is one thing that they changed. It would seem that the wording of the correction is prone to misinterpretation. Our guidelines need to clearly state how the correction is done. These algorithms all state that hh should be set to be max_drift pixels from $Kh$ in the same direction which it is presently off. The intent is to allow hh to deviate from $Kh$ by no more than max_drift pixels while advancing hh in a manner which minimizes visual disruption of the printed text. Drift correction: A refinement: Generally, the drift correction results in a shift in hh of 1 pixel. There are cases, however, where the shift in hh may be more than one pixel; up to three pixels, in fact. One case is if hh is currently max_drift pixels from $Kh$ and a lowercase m is set. For some font sizes, the pixel width of the m can be as much as three pixels different from $K\times TFM\_width$. If the two errors are in the same direction, a drift correction will be done which will result in a shift in hh of three pixels. (At 300 dpi, this will be most visible.) However, if the errors are in opposite directions, no correction at all will be done (assuming a max_drift value of 2). Such differences will be noticeable. Perhaps a better approach would be to limit hh corrections to a shift of one pixel. If a sudden drift is introduced which causes hh to be more than $max\_drift+1$ pixels from $Kh$, then single pixel corrections will be done for successive horizontal motions until (1) the drift tolerance is reached, or (2) a "large" horizontal space is reached which absorbs all of the drift. This change would minimize the disruption of drift correction for certain letter combinations throughout a document, but has the bad side-effect of allowing $\abs(Kh-{\it hh})$ to exceed max_drift by a potentially unbounded amount. I will look into running some tests to see how this algorithm performs on normal text as well as instances with characters with three-pixel differences in width. Limiting max_drift: >$\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. My first inclination to this was to question whether the upper limit should be 2 or 3 pixels. I do agree, however, that max_drift does not need to be more than a small number (2 or 3). After analyzing a particular case, I've decided that 2 would probably be better. The analysis has to do with alignment of the ends of words on successive lines of justified text. My feeling is that a max_drift value of 3 gives too high of a probability of visual misalignment between the ends of the lines. If anyone cares to see the analysis, I'll be glad to send it. Future work on a "max drift" algorithm: >\end{document} ... but not \end{development} I hope. :-) The algorithm given above may be good enough for Level 0, but there's still room for improvement for a Level 1 algorithm. I mention this now so that effort can be put into the development before we start Level 1 discussions. o Nelson Beebe posted a problem with misalignment occurring in listings done in a mono-spaced font. His solution was to set max_drift to 0 for the page/document. I posted a modified algorithm which uses a font-dependent value for max_drift: 2 or 3 for normal fonts, and 0 for mono-spaced fonts. There are two problems: -- Identifying mono-spaced fonts: The approach I use is to compare all of the TFM widths from the PK/GF (or TFM) file. If they are all equal, the font is considered to be mono- spaced. Otherwise, it is not. A better method is needed here. Joachim Schrod indicated that he does not want to be required to process TFM files, so use of a TFM-file-only parameter should be avoided. -- Single-pixel drift correction: If one restricts drift correction to one pixel (as I indicated earlier in this note), misalignment could still occur. The correction step could be changed to simply set hh to $Kh$ if max_drift is 0. o A completely new algorithm along the lines of what Robert McGaffey suggested should be investigated. The general idea is to prevent the ends of lines from drifting and preserve device spacing within words while distributing cumulative drift error as evenly as possible at the "large" gaps within the line. The problem areas here are: -- How does one define "a line of text"? At the DVI level, we don't know about hboxes or vboxes; they're reduced to commands between PUSH/POP pairs. -- Boxes within the "line of text" need to be allowed to drift. Only the ends of the "line of text" should be fixed. (This is so that subscripts, superscripts, and accents drift with the item/letter to which they belong.) -- Ideally, the cumulative error for centered text could be divided between the spaces before and after the line and the error for left-aligned text could simply be placed after the line. However, the DVI file does not contain information which explicitly indicates centered or left- aligned text. (This may not be practical.) -- The "large" gaps need to be identified. The method used for the present max drift algorithm can identify horizontal movements that should not be considered as "large" gaps. The following TeX code: a\hbox{b}c produces this DVI code: SET_CHAR_97 % "a" PUSH SET_CHAR_98 % "b" POP RIGHTn {width of "b"} SET_CHAR_99 % "c" The displacement for the RIGHTn command would probably make it function as a "large" gap. -- What do you do if there are no "large" gaps in a "line of text" and a non-zero amount of error to distribute? -- Some way of accomodating listings in mono-spaced fonts needs to be defined. -- Care should be taken so that this algorithm does not adversely affect complex mathematical equations and LaTeX/PiCTeX/etcTeX- style graphics. Is there anyone interested in taking on this new position correction algorithm? ---Tom Reid ========================================================================= Date: Mon, 23 Jul 90 22:26:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Ammendment: Change margin of error tolerance (S4.3.2) >>Currently says: >>If a DVI file requests a magnification within 2% of a supported >>magnification, the driver should use that font without warning. >> >>Change to read: >>If a DVI file requests a magnification within 0.2% of a supported >>magnification, the driver should use that font without warning. >I agree with this change. However, there are still some problems with >the wording: What is meant by "that font"? Presumably, it should be >"the supported magnification." >Also, I propose another change: For items of this sort, the guidelines >should state the problem which is to be overcome. In this case, the >wording could be something like: > TeX and METAFONT compute font magnifications with different > precisions. Further, calculations done by TeX and/or a DVI > driver are subject to roundoff errors. As a method of > accomodating these differences, if the magnification requested > for a font is within 0.2% of a supported magnification, the > driver should use the supported magnification without warning. >The problem statements do not need to give the details, but they do >need >to make clear what is trying to be accomplished. This is important so >that a driver author does not interpret the workaround as being a >solution to something else. >Also, the wording "As a method of ..." leaves open the possiblility of >other workarounds for the problem which, while correcting for the >stated >problem, may not be compliant with the suggested workaround. >The goal of these guidelines should be to resolve problems. Could you write this up in ammendment form? Thanks. -dh ========================================================================= Date: Wed, 25 Jul 90 12:39:08 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Trailing NULs and the DVI driver draft standard Re: proposed amendments to DVI driver draft standard: I think it is unwise to specify that `characters added by intermachine transfer' are trailing NULs. Block padding could be arbitrary garbage in a file system that stores a file length, ignoring characters past the length. I know of one such instance of this (Eunice, a UNIX-like system implemented on top of VAX VMS). Since trailing signature bytes are present in the font files, perhaps the standard should require that the files be backward to find an acceptable signature, ignoring any trailing bytes, whatever their value. ------- ========================================================================= Date: Wed, 25 Jul 90 13:13:02 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Trailing NULs and the DVI driver draft standard In-Reply-To: Message of Wed, 25 Jul 90 12:39:08 CDT from On Wed, 25 Jul 90 12:39:08 CDT Nelson H. F. Beebe said: >Re: proposed amendments to DVI driver draft standard: > >I think it is unwise to specify that `characters added by >intermachine transfer' are trailing NULs. Block padding >could be arbitrary garbage in a file system that stores a >file length, ignoring characters past the length. I know of >one such instance of this (Eunice, a UNIX-like system >implemented on top of VAX VMS). > >Since trailing signature bytes are present in the font >files, perhaps the standard should require that the files be [read] >backward to find an acceptable signature, ignoring any >trailing bytes, whatever their value. >------- By "garbage" I assume you mean whatever is left on the disk or in the I/O buffer. It could be possible that a "valid" signature is present in the garbage which could cause a false postamble to be located. (The garbage may be the remnants of a postamble from a previous version or different DVI/GF file.) Systems which do NUL padding are real common. How prevalent are systems which do "garbage" padding? If they are rare enough, we could require that some utility be used to clean up the end of the file. You say that the system "stores a file length." Does this length point to the end of the real file/beginning of garbage? Is this length available to a program? If yes to both, the driver could use it and would never see the garbage. ---Tom Reid ========================================================================= Date: Wed, 25 Jul 90 13:31:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Minor change to wording of Ammendment 1: Change margin of error tolerance (S4.3.2) At Tom Reid's request, I've made a change to the wording of Ammendment 1. Since there is no subtantive change, I'm assuming that there will be no changes in votes received. It now reads as follows: Ammendment: Change margin of error tolerance (S4.3.2) Ammendment number: 01 Submitted by: Don Hosek Date: 25 July 1990 Currently says: If a DVI file requests a magnification within 2% of a supported magnification, the driver should use that font without warning. Change to read: TeX and METAFONT compute font magnifications with different precisions. Further, calculations done by TeX and/or a DVI driver are subject to roundoff errors. As a method of accomodating these calculations, if the magnification requested for a font is within 0.2% of a supported magnification, the driver should use the supported magnification without warning. Reason for change: In discussion on DRIV-L, it was shown that rounding errors would not cause a variation greater than 0.2% (and that only in extreme cases at high resolutions). Tom Reid, in his mail of 3-July-1990 gives the numerical proof of this as well as a simple algorithim for handling locating the font when calculations are off slightly as indicated. The purpose of the rounding error calculation is *not* to do things like take care of the case where a user requested cmr10 at 11pt instead of cmr10 at 10.95pt. ========================================================================= Date: Wed, 25 Jul 90 14:45: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 Tom Reid... Date: Wed, 25 Jul 90 13:59:44 CDT From: "Thomas J. Reid" Subject: RE: The Level 0 Draft standard (v 0.03) -- Request for comments To: Don Hosek On Sun, 22 Jul 90 13:32:00 PDT you said: >>>The driver should be able to print a page containing as many as >>>1000~rules. >>> >>Doug McDonald said: >> >>This should be 20,000, just as for characters. Gnuplot generates Latex >>files with that many rules, and more. This is very important. >>This should be always doable, as they can always be done by making a >>font of rules, - and you already specify 20000 characters. Perhaps you >>might >>want to specify a maximum total number of rules and characters, say >>30000. > >The problem is that on some output devices (e.g., the Xerox printers), >rules are more expensive than characters. A rule .5pt wide, 14pt high >and 2pt deep can take a surprising number of characters to print. > >-dh Don, For portrait and inverse portrait, the rule requires 9 bytes (plus positioning). For landscape and inverse landscape, it only requires 5 bytes (plus positioning). It's still much more than 1 byte per printed character, but I have managed to get 1800 rules on a single page before. Of course, if the limit for rules were set higher, I could do the rules as graphics which does not cost anything toward the 9700F limit of 24K bytes. I'm perfectly content with the 1000-rule limit. This brings up another topic which should probably be in Level 0. For the example you give, the rule (at 300 dpi) would be 2.076dots wide by 66.42dots high. TeX calls for these numbers to be rounded to 3dots by 67dots. There are also some drivers which would compute the widths by computing the opposite corners of the rule in DVI coordinates, then independently round each to pixels. This causes single pixel variations in rules which actually have the same width or height+depth. If you want me to write up an ammendment for this, I will. But I seem to be spending more time on this than I can afford to. Something to consider for Level 1: When \specials for graphics primitives are added to the standard, consideration needs to be given to techniques for maintaining consistent stroke thickenesses. The algorithms published in the textbooks don't ever seem to address this problem. ---Tom ========================================================================= Date: Wed, 25 Jul 90 14:49: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 Tom Reid said... >There are also some drivers which would compute the widths by computing >the opposite corners of the rule in DVI coordinates, then independently >round each to pixels. This causes single pixel variations in rules >which actually have the same width or height+depth. This is wrong. The DVItype algorithim *does* state that rules should be positioned by their lower left corner with their size rounded as indicated. However, this should be stated explicitly. I'll put together an ammendment on this for the standard. -dh ========================================================================= Date: Wed, 25 Jul 90 17:06:36 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Need a Rationale document In some ANSI standards, notably the recently adopted C language standard, the standard itself is accompanied by a document in English prose (as opposed to gobbledygook `standardese') called `Rational for xxx'. Such a document is not itself part of the standard, but it has nevertheless a valuable purpose: to clarify the reasons behind each section of the standard. Each section, subsection, and paragraph of the standard has a similarly-numbered entry in the rationale. Where no additional commentary is provided, only the section/subsection/paragraph header appears in the rationale document. In the case of ANSI C, the standard is about 200 pages long, and the rational about 100 pages long. In view of the recent discussions on this list about the background for certain decisions, I suggest that the committee consider preparation of a rationale document to accompany the draft DVI standard. While this involves additional work now, it will save on work later, because it will help to prevent a barrage of questions from the TUG community after the draft is published, questions that can be answered by the Rationale, but are not evident to a skilled reader of standards, or to someone without considerable experience in writing DVI drivers. Quite likely, certain footnote items in the draft standard could be profitably moved to a Rationale document. If we proceed in the style of ANSI standards, once a standard has been adopted, it cannot be changed for a period of some years (5 for ANSI); the standards committee then reverts to issuing (non-binding) interpretations of the standard during that period. ------- ========================================================================= Date: Wed, 25 Jul 90 17:04:53 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Request for clarification on Amendment Number: 5 In-Reply-To: Your message of Wed 25 Jul 90 15:45:31-MDT On Wed 25 Jul 90 15:45:31-MDT you said: >The question is, ``Do we intend to permit a .dvi file to >use a larger stack than declared in the postamble?''. > >I suggest that the answer should be NO. Comments? I agree with Nelson (with one possible change). If the DVI file PUSHes more than it has declared in the postamble, then the DVI file is structurally incorrect. Level 0 should not have to contend with incorrect DVI files. (Although we may want to make some statement about what it can/should do if it detects an incorrect file.) However, we may need to allow the stack to be 1 more than what the postamble says: If the driver processes virtual fonts, isn't it suppossed to assume a PUSH/POP around each character? If so, the driver needs to add 1 to the stack depth value given in the postamble if it actually does the implied PUSH/POP. Are we addressing virtual fonts in Level 0? ---Tom Reid ========================================================================= Date: Wed, 25 Jul 90 16:13:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Need a Rationale document >In view of the recent discussions on this list about the >background for certain decisions, I suggest that the >committee consider preparation of a rationale document to >accompany the draft DVI standard. This sounds like a great idea. Having been doing a lot of work this summer on some rather interesting single-sourcing applications (so far the record is 5 documents plus statistics on the contents of the documents from one TeX file) I think I can put something together along these lines for the standard. We can probably leave the specifications of file formats alone. I'll write something up over the weekend and send it to the list (if you don't have it by, say, Tuesday, feel free to flood my mailbox like I've been flooding yours. -dh ========================================================================= Date: Wed, 25 Jul 90 16: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: Request for clarification on Amendment Number: 5 NB = Nelson Beebe, TR = Tom Reid NB>The question is, ``Do we intend to permit a .dvi file to NB>use a larger stack than declared in the postamble?''. NB> NB>I suggest that the answer should be NO. Comments? TR>I agree with Nelson (with one possible change). TR>If the DVI file PUSHes more than it has declared in the postamble, TR>then the DVI file is structurally incorrect. Level 0 should not TR>have to contend with incorrect DVI files. (Although we may want to TR>make some statement about what it can/should do if it detects an TR>incorrect file.) TR>However, we may need to allow the stack to be 1 more than what the TR>postamble says: If the driver processes virtual fonts, isn't it TR>suppossed to assume a PUSH/POP around each character? If so, the TR>driver needs to add 1 to the stack depth value given in the postamble TR>if it actually does the implied PUSH/POP. TR>Are we addressing virtual fonts in Level 0? Actually, it's worse than that... a VF character could use another VF character which could use another VF character which could use another VF character ad infinitum (although this boundary case would probably be an error). There are two issues here: One is explicit push/pops. This number should never exceed that in the postamble. If it does, we have a malformed DVI file which is not covered by the Level 0 standard. If we do specify that this should cause an error, we should also cover all other possible error conditions. Alternatively, we could make it explicit in S2 that Level 0 does not cover malformed DVI files. (Incidentally, the only cases of malformed DVI files that I have encountered have been either mis-blocked files or thoroughly corrupted files which don't even have a valid DVI ID byte. TeX takes great pains to insure that it always writes a valid DVI file (e.g., see fix #331 to TeX). As regards virtual fonts, the number of implicit push/pops should have *no* affect on how much stack is left due to the effect that I mentioned above (note also that VF characters can contain their own push/pops as well). -dh ========================================================================= Date: Wed, 25 Jul 90 16:50: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: Need a Rationale document Date: Wed 25 Jul 90 17:13:27-MDT From: "Nelson H. F. Beebe" Subject: RE: Need a Rationale document >>... >> The rationale statements could include (as needed): >>... >> Anything else? >>... One other thing the ANSI rationales sometimes discuss is alternatives that were not included in the standard, and why they were rejected. {This helps to answer the common question of the form ``But if you had only done ... then ....''; a standards committee has probably already considered that alternative.} ------- From: "Thomas J. Reid" Subject: RE: Need a Rationale document Date: Wed, 25 Jul 90 17:50:16 CDT Neslon and Don, I agree with this. The rationale statements could include (as needed): o Problem statement o Derivation/anayses of corrective measure given in the standard o Implementation suggestions o Statement of direction that a higher level of the standard will take (if we know enough about it at the time) o Statement of remaining problems or areas that should be researched Anything else? ---Tom ========================================================================= Date: Wed, 25 Jul 90 16:52: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 Date: 25 Jul 90 09:22:46 +0100 (Wednesday) From: Martyn Johnson Subject: RE: The Level 0 Draft standard (v 0.03) -- Request for comments I have one comment about the proposed DVI standard. It doesn't say anything about the treatment of "DVI units". The units are declared in the preamble and postamble of a DVI file, but I have met drivers which totally ignore the declaration and simply assume that the values in the file are scaled points. This causes me some problems because I make use of DVI files with different units. They arise from translating the output of a different paginator into DVI, and this leads to "num" and "den" being set to 25400 and 7227 respectively. Ideally I would like the standard to say that the conversion ratio should be properly interpreted. At the very least, it should specify that the driver must CHECK the declared conversion ratio, and give an error message if it cannot handle it. Martyn Johnson University of Cambridge Computer Lab Cambridge UK ========================================================================= Date: Wed, 25 Jul 90 17:05: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 >I have one comment about the proposed DVI standard. It doesn't say >anything about the treatment of "DVI units". The units are declared in >the preamble and postamble of a DVI file, but I have met drivers which >totally ignore the declaration and simply assume that the values in the >file are scaled points. >This causes me some problems because I make use of DVI files with >different units. They arise from translating the output of a different >paginator into DVI, and this leads to "num" and "den" being set to >25400 >and 7227 respectively. >Ideally I would like the standard to say that the conversion ratio >should >be properly interpreted. At the very least, it should specify that the >driver must CHECK the declared conversion ratio, and give an error >message if it cannot handle it. Any driver which assumed that one DVI unit is one scaled point is not correctly interpretting the pre and post commands in the DVI file. We will, at some point, be issuing a set of testing programs and this is one of the points which we will test. -dh ========================================================================= Date: Thu, 26 Jul 90 07:42:04 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 ; THU, 26 JUL 90 07:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster GOOD IDEA!!!!!!!! Stephan v. Bechtolsheim Computer Sciences Department svb@cs.purdue.edu Computer Science Building (317) 494 7802 Purdue University FAX: (317) 494 0739 West Lafayette, IN 47907 ========================================================================= Date: Thu, 26 Jul 90 07:49:18 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 ; THU, 26 JUL 90 07:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster You might consider writing one document containing both and then having a conditional at the top which specifies whether the rational stuff should be included or not. StvB ========================================================================= Date: Thu, 26 Jul 90 13:09:04 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: Trailing NULs and the DVI driver draft standard In-Reply-To: <5CACE7C683DF400325@CC.UTAH.EDU> Tom Reid observes: >>... >> By "garbage" I assume you mean whatever is left on the disk >> or in the I/O buffer. It could be possible that a "valid" >> signature is present in the garbage which could cause a >> false postamble to be located. >>... While it is true that it is possible that trailing garbage could hold a valid signature, this is less likely. The garbage arises because data is copied into a file block obtained from the buffer pool, without clearing the end of the block. In the case of Eunice, the O/S knows where the real end of file is. However, in VAX VMS, on which Eunice is hosted, the file system parameter (the offset into the last block) from which the true end-of-file can be determined is ignored when Eunice files are copied, so the trailing crud goes along with the file as valid data (most VMS utilities unfortunately assume fixed-length blocked binary files are multiples of 512 bytes long, even though this need not be the case). I therefore feel that the standard should NOT specify what trailing characters there might be, only observe that, because they might be there, the driver should read backwards over them to find the signature which marks the end of the file. This will require changes in my drivers too, but relatively small ones. ------- ========================================================================= Date: Thu, 26 Jul 90 11:35: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: level 0 device driver standard Date: Thu, 26 Jul 90 16:23:54 MET From: Friedrich Haubensak Subject: RE: level 0 device driver standard To: dhosek@YMIR.CLAREMONT.EDU Hi, I've just read the draft proposal for a device driver standard and I think it's fine (even finer, if all these drivers I've been struggling with would confine to these :-) Just two remarks: - Why not set the maximum vertical character (and rule) dimension to 850pt? This would cover the length of A4 paper (quite popular here in Europe, you know :-) - In section `Configuration', it should be made explicit that a driver should be able to search fonts in various locations, perhaps even according to different naming conventions. This is a point I had trouble again and again. It seems to me, that the people writing the proposal had only device drivers for print media in mind. There's an important other class of device drivers: screen previewers. Will some basic functionality requirements for these be discussed in some `level n+1' standard? Thanks for your work! Greetings from the river Rhine, Fritz - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | "Make a remark," |___ ___ | / said the Red Queen: | | |___ |\/ "it's ridiculous | | ___| | \ to leave all the conversation to the pudding." Friedrich Haubensak, Informatik, Uni Koblenz, W. Germany --- hsk@infko.UUCP ========================================================================= Date: Thu, 26 Jul 90 21:44:33 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: GOOD IDEA!!! Receiving the following mail: > Date: Thu, 26 Jul 90 07:42:04 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?e > ; THU, > 26 JUL 90 07:". Rest of header flushed. > Comments: E: "From:"/"Sender:" field is missing. > From: Undetermined origin c/o Postmaster > To: Joachim Schrod , > Klaus Guntermann > > Status: R > > GOOD IDEA!!!!!!!! > > Stephan v. Bechtolsheim > Computer Sciences Department svb@cs.purdue.edu > Computer Science Building (317) 494 7802 > Purdue University FAX: (317) 494 0739 > West Lafayette, IN 47907 I asked me -- what is a `GOOD IDEA?' ?? By the way, if the proposal of Nelson with the ANSI like procedure is ment it's really a good idea... Joachim ========================================================================= Date: Thu, 26 Jul 90 21:50:33 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Friedrich Haubensack writes: > - In section `Configuration', it should be made explicit that > a driver should be able to search fonts in various locations, > perhaps even according to different naming conventions. > This is a point I had trouble again and again. As I remember we already decided to cover this in a later level. > It seems to me, that the people writing the proposal had only device > drivers for print media in mind. There's an important other class > of device drivers: screen previewers. Will some basic functionality > requirements for these be discussed in some `level n+1' standard? No. The standards are not written with `drivers for print media in mind'. At least I always think about the consequences for previewers. Previewers are covered because they (1) simulate a virtuell sheet of paper and (2) the points discussed by now handle basic functionalities. (I would like to point again to my proposal for the structure of the standard which is available from LISTSERV@TAMVM1.) Joachim ========================================================================= Date: Thu, 26 Jul 90 14:08:18 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Trailing NULs and the DVI driver draft standard In-Reply-To: Message of Thu, 26 Jul 90 13:09:04 CDT from On Thu, 26 Jul 90 13:09:04 CDT Nelson Beebe said: >While it is true that it is possible that trailing garbage >could hold a valid signature, this is less likely. The >garbage arises because data is copied into a file block >obtained from the buffer pool, without clearing the end of >the block. But if lots of files are transferred at once, the buffer pool may have the end of some other file. (It depends upon how large the buffer pool is and how Eunice manages the buffers.) > In the case of Eunice, the O/S knows where the >real end of file is. However, in VAX VMS, on which Eunice >is hosted, the file system parameter (the offset into the >last block) from which the true end-of-file can be >determined is ignored when Eunice files are copied, so the >trailing crud goes along with the file as valid data (most >VMS utilities unfortunately assume fixed-length blocked >binary files are multiples of 512 bytes long, even though >this need not be the case). Can a utility be run under Eunice before copying the file with VAX/VMS to replace the crud with NULs or X'DF's? How does the trailing crud affect non-DVI and non-GF files? How do Eunice users cope with problems there? >I therefore feel that the standard should NOT specify what >trailing characters there might be, only observe that, >because they might be there, the driver should read >backwards over them to find the signature which marks the >end of the file. And what does the driver do if it does hits a false postamble? Do we just tell the user to try transferring the file again and wish him or her luck on how the I/O buffers fall? Or do we add additional checks (check for ID and POST_POST, read backpointer, seek to it, then check for POST) to the signature locator and continue searching backwards if those checks fail? (This would not be 100% reliable.) >This will require changes in my drivers too, but relatively >small ones. Unless false postamble checks are included. I'm still not convinced that this problem is one that should be addressed by DVI drivers. I feel that in the case of systems which pad files out with garbage, a separate clean-up utility is a more appopriate solution. ---Tom Reid ========================================================================= Date: Thu, 26 Jul 90 15:06:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Experience with Adobe While going over back logs of the driv-l discussion, I came across a comment from Tom Rokicki that one of the reasons that TeX has problems with Adobe fonts is that AFM files don't have all the metric information that TeX needs (a glaring omission is the lack of italic correction). Well, I decided that this was a sorry state of affairs and called up Adobe. They were very receptive to the idea of adding the necessary information to the AFM format. I'm sending a big pile of information about what TeX wants in terms of metric information to Adobe tomorrow morning and if all goes well, TeX and PostScript will be much better allied. Kind of makes me wonder why nobody did this before. Arre there any other type vendors we want to talk to? -dh ========================================================================= Date: Thu, 26 Jul 90 16:21:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Notes on: >From: "Thomas J. Reid" >On Sun, 22 Jul 90 14:43:00 PDT you said: >>(2) the check for whether maxdrift correction should be >applied has been >>modified slightly to give slightly better results in some >cases >>(suggestion courtesy John Hobby). >Don, >What is the suggestion made by John Hobby and what was it? >The drift >check in your note seems to imply that the drift amount is to >be >computed in non-integer pixel amounts as opposed to: > abs (pixel_round(K*h)-hh) >Since hh is always a whole number, this means that the maximum >drift >is kept in the range of (max_drift-1, max_drift]. If >pixel_round(K*h) >is used, the range of drift (from the true K*h) lies in the >range >[max_drift-0.5, max_drift+1.5]. >The net effect of this difference is to allow a half-pixel >increase >in drift. The setting is a fuzzy limit anyway, so I question >whether >it makes a big difference. >The implementation, however, is impacted: The pixel_round >form allows >the test to be done using whole numbers (ie, no floating point >or >scaled integers like TeX and METAFONT do). Since the check is >in an >inner loop of the driver, efficiency is an important concern. >I would like to see John Hobby's reasons for change to >convince >myself one way or the other on this. I believe John Hobby's suggestion was based on the assumption that pixel_round was the rounded value and not the ceiling. A close evaluation of the numbers might be in order (or Tom, perhaps some empirical experiments might be worth trying). John's suggestion, by the way, would run faster since it eliminates a function call. -dh ========================================================================= Date: Thu, 26 Jul 90 19:44:59 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Adobe Font Metrics and TeX In-Reply-To: Don, you might want to grab the recent update to the AFM descriptions; they are in the files AFM-16MAR90.TARZ.1 83 26-Apr-90 12:26:17 24-Jul-90 08:03:43,BEEBE AFMFORMAT3-0.PS.1 70 23-Apr-90 10:47:45 11-Jul-90 10:45:17,BEEBE on the science.utah.edu anonymous ftp directory. The .tarz file should be fetched in tenex mode, then uncompressed and untarred; it has font metric files for all the fonts in the Apple LaserWriter II, with instructions for how to get others from Adobe's file server. The .PS file is the AFM document itself, but requires a large-memory printer to handle it. ------- ========================================================================= Date: Thu, 26 Jul 90 19:44:06 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Notes on: In-Reply-To: Message of Thu, 26 Jul 90 16:21:00 PDT from On Thu, 26 Jul 90 16:21:00 PDT Don Hosek said: >>Since hh is always a whole number, this means that the maximum >>drift >>is kept in the range of (max_drift-1, max_drift]. If >>pixel_round(K*h) >>is used, the range of drift (from the true K*h) lies in the >>range >>[max_drift-0.5, max_drift+1.5]. ============= NOTE: The above should be "max_drift+0.5" instead of "max_drift+1.5." This is an error on my part. ---TJR > >>The net effect of this difference is to allow a half-pixel >>increase >>in drift. ... > >I believe John Hobby's suggestion was based on the assumption >that pixel_round was the rounded value and not the ceiling. A >close evaluation of the numbers might be in order ... See above. For a max drift value of 2, the first method sets the drift threshhold in the range (1, 2] while rounding K*h first gives the range [1.5, 2.5] depending upon where (K*h)-floor(K*h) happens to fall in the range [0, 1). > ... (or Tom, >perhaps some empirical experiments might be worth trying). At 300 dpi, the larger range in drift seems appropriate. For lower resolutions where max drift is set to 1, the ranges become (0, 1] and [0.5, 1.5], respectively, for the two methods. The first form would have a tendency to correct more often then the later. Of course, this could be offset by increasing max_drift by 1. >John's suggestion, by the way, would run faster since it >eliminates a function call. > >-dh This assumes that the driver and/or compiler actually do a function call to implement pixel_round; my driver does not. DVItype defines pixel_round as a macro involving round. Whether or not a function call is done for that depends upon what functions the compiler handles as in-line functions. ---Tom Reid ========================================================================= Date: Thu, 26 Jul 90 18:57:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Notes on: >> ... (or Tom, >>perhaps some empirical experiments might be worth trying). > >At 300 dpi, the larger range in drift seems appropriate. For >lower >resolutions where max drift is set to 1, the ranges become (0, >1] >and [0.5, 1.5], respectively, for the two methods. The first >form >would have a tendency to correct more often then the later. >Of >course, this could be offset by increasing max_drift by 1. I presume that "the larger range in drift" refers to John Hobby's method. Perhaps Joachim can try some experiments with his previewer to see if there which algorithim works better (we don't have any 100dpi output devices around here). >>John's suggestion, by the way, would run faster since it >>eliminates a function call. >> >>-dh >This assumes that the driver and/or compiler actually do a >function >call to implement pixel_round; my driver does not. Mea culpa. I was thinking of rule_pixels when I wrote that (which also modifies some of my other comments). However, this means that the performance difference is between casting an integer into a real data type or rounding a real into an integer data type. My gut instinct is the former is still faster, but that relies largely on the compiler and hardware. -dh ========================================================================= Date: Fri, 27 Jul 90 07:57:28 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 ; FRI, 27 JUL 90 07:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster If I remember correctly the italics correction and some spacing parameters (default interword space) are not in the afm files. Please tell me whether I should look into my files and dig out that information. I would be happy to do so. StvB ========================================================================= Date: Fri, 27 Jul 90 17:00:54 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Trailing NULs and the DVI driver draft standard I fully support the statement of Tom Reid about the NUL padding: > I'm still not convinced that this problem is one that should be > addressed by DVI drivers. I feel that in the case of systems > which pad files out with garbage, a separate clean-up utility > is a more appopriate solution. Let's support the most common case of transporting DVI files with NUL's padded; the rest of the files should be correct. Joachim [12~ ========================================================================= Date: Fri, 27 Jul 90 11:07:07 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: AFMs do not have italic correction or interword space In-Reply-To: <5B6843350EDF400A3E@CC.UTAH.EDU> StvB observes ``the italics correction and some spacing parameters (default interword space) are not in the afm files.''. I've just checked the AFM 3.0 document, dated March 8, 1990, and that observation appears to be correct. There is support for kerns and ligatures, and specification of an italic angle, but neither the italic correction nor the interword space is present. ------- ========================================================================= Date: Fri, 27 Jul 90 11:15:37 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Padding characters While I don't deny that NULs are the commonest form of extraneous padding in binary files, I still feel strongly that it is inappropriate for a standard to specify what those padding characters might be. Each of the file types which we are concerned about has a trailing signature that identifies where the file data really ends. Yes, it is possible that this signature could be found in trailing garbage characters, but in most cases, that is unlikely. It seems better to me for the driver to search backwards for the signature, ignoring whatever trailing garbage there is, since that will work in more cases than the algorithm that says just to ignore trailing NULs; the increased generality is worthwhile. My drivers under two operating systems currently ignore trailing NULs; I intend to change them to search instead for signatures, whatever the trailing bytes might be. So, you see, I too have to do some code changes because of this part of the draft standard. ------- ========================================================================= Date: Fri, 27 Jul 90 12:02:14 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Comments on ``Handling rounding...'' Technical points about the draft of ``Handling rounding to device units---modified DVItype algorithm'' have already appeared. These comments are smaller: (1) In two places, fix a spelling error: algorithim -> algorithm (2) In 1.1, the rounding uses the ceil() function. This assumes that the values to be rounded are positive, which is not the case for some movements produced by TeX (I know about this, because I'm responsible for a bug in at least one of my DVI drivers where positive values were assumed in the PIXROUND() macro; that bug was fixed early in the 3.0 DVI driver development in the fall of 1988). I believe that it would be better to rephrase the section to speak in terms of round-to-larger-in-absolute value. (3) In 1.2, paragraph 2, `x-escapement' would be better phrased as `horizontal escapement'. (4) In the last paragraph, I was unclear about the application of the maxdrift correction; was it to be applied at once, or only max_drift pixels at a time. Other readers have also noticed this, and enlarged upon it, noting that the idea is to spread the correction in max_drift pixel chunks. Note, however, that lines in verbatim mode (i.e. fixed-width font) like ****************************************************************************** * * ****************************************************************************** will exhibit the maxdrift problem, and the proposed algorithm will not fix it (I think the problem for such extreme cases probably is insoluble). The example is not a wild one; it is typical of text found in program comments that is exhibited in computer-related documents. We have discussed this example before; I don't want to precipitate new discussion on it, but perhaps the draft could note that such problems are not solved by the proposed maxdrift algorithm. [I've had the spacing problems produced by such examples reported as a driver `bug' a great many times by users of my drivers; consequently, the DVI 3.0 drivers permit maxdrift to be set by the user, possibly to 0, so each character is positioned separately.] ------- ========================================================================= Date: Fri, 27 Jul 90 17:51:25 BST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: root@NSFNET-RELAY.AC.UK Subject: Mail Delivery Failure to uk.ac.ou.acsvax - Rejected The NIFTP process was unable to deliver your mail to host uk.ac.ou.acsvax over janet. The reason given by the remote host was: Invalid value in command: invalid attribute - filename "FTP$NETWELL:MAILTMP.TMP". File open failure reason - error in file name. Username ignored. VAX/VMS FTP (80) Version 5.2. Your message was not delivered to the following addresses: ca_rowley@uk.ac.open.acs.vax Your message begins as follows: Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id ac09451; 27 Jul 90 16:41 GMT Received: from relay.cs.net by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa11581; 27 Jul 90 17:31 BST Received: from tamvm1.tamu.edu by RELAY.CS.NET id aa12161; 27 Jul 90 12:16 EDT Received: from TAMVM1.TAMU.EDU by tamvm1.tamu.edu (IBM VM SMTP R1.2) with BSMTP id 7468; Fri, 27 Jul 90 11:16:10 CDT Received: by TAMVM1 (Mailer R2.03B) id 5400; Fri, 27 Jul 90 11:16:09 CDT Date: Fri, 27 Jul 90 11:15:37 CDT Reply-To: The TUG DVI driver standards discussion list Original-Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Padding characters X-To: driv-l@science.utah.edu To: Chris Rowley Sender: DRIV-L%edu.tamu.tamvm1@net.cs.relay While I don't deny that NULs are the commonest form of extraneous padding in binary files, I still feel strongly that it is inappropriate for a standard to specify what those padding characters might be. Each of the file types which we are concerned about has a trailing signature that identifies where the file data really ends. Yes, it is possible that this signature could be found in trailing garbage characters, but in most cases, that is unlikely. It seems better to me for the driver to search backwards for the signature, ignoring whatever trailing garbage there is, since that will work in more cases than the algorithm that says just to ignore trailing NULs; the increased generality is worthwhile. My drivers under two operating systems currently ignore trailing NULs; I intend to change them to search instead for signatures, whatever the trailing bytes might be. So, you see, I too have to do some code changes because of this part of the draft standard. ------- ========================================================================= Date: Fri, 27 Jul 90 17:46:09 BST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: root@NSFNET-RELAY.AC.UK Subject: Mail Delivery Failure to uk.ac.ou.acsvax - Rejected The NIFTP process was unable to deliver your mail to host uk.ac.ou.acsvax over janet. The reason given by the remote host was: Invalid value in command: invalid attribute - filename "FTP$NETWELL:MAILTMP.TMP". File open failure reason - error in file name. Username ignored. VAX/VMS FTP (80) Version 5.2. Your message was not delivered to the following addresses: ca_rowley@uk.ac.open.acs.vax Your message begins as follows: Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id ah05523; 27 Jul 90 16:18 GMT Received: from relay.cs.net by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa11223; 27 Jul 90 17:09 BST Received: from tamvm1.tamu.edu by RELAY.CS.NET id aa11748; 27 Jul 90 12:08 EDT Received: from TAMVM1.TAMU.EDU by tamvm1.tamu.edu (IBM VM SMTP R1.2) with BSMTP id 7461; Fri, 27 Jul 90 11:07:47 CDT Received: by TAMVM1 (Mailer R2.03B) id 5245; Fri, 27 Jul 90 11:07:46 CDT Date: Fri, 27 Jul 90 11:07:07 CDT Reply-To: The TUG DVI driver standards discussion list Original-Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: AFMs do not have italic correction or interword space X-To: DRIV-L@science.utah.edu To: Chris Rowley In-Reply-To: <5B6843350EDF400A3E@CC.UTAH.EDU> Sender: DRIV-L%edu.tamu.tamvm1@net.cs.relay StvB observes ``the italics correction and some spacing parameters (default interword space) are not in the afm files.''. I've just checked the AFM 3.0 document, dated March 8, 1990, and that observation appears to be correct. There is support for kerns and ligatures, and specification of an italic angle, but neither the italic correction nor the interword space is present. ------- ========================================================================= Date: Fri, 27 Jul 90 11:34:45 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: Experience with Adobe > They were very receptive to the idea of adding the necessary > information to the AFM format. Congratulations! Now that tyey no longer have a monopoly of the EP font world, perhaps they will be more amenable in many ways: eg releasing the Lucida Maths Fonts! > > Arre there any other type vendors we want to talk to? There seems to me to be a new font format appearing about once a month at present! But even for "Postscript fonts" there are a very large number of suppliers: you could do worse than starting with Monotype and Linotype, and ask them when they are going to make their "mathematical sorts" geberally available to the TeX world! chris ========================================================================= Date: Fri, 27 Jul 90 18:23:29 BST Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: root@NSFNET-RELAY.AC.UK Subject: Mail Delivery Failure to uk.ac.ou.acsvax - Rejected The NIFTP process was unable to deliver your mail to host uk.ac.ou.acsvax over janet. The reason given by the remote host was: Invalid value in command: invalid attribute - filename "FTP$NETWELL:MAILTMP.TMP". File open failure reason - error in file name. Username ignored. VAX/VMS FTP (80) Version 5.2. Your message was not delivered to the following addresses: ca_rowley@uk.ac.open.acs.vax Your message begins as follows: Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id ac15565; 27 Jul 90 17:17 GMT Received: from relay.cs.net by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa12224; 27 Jul 90 18:07 BST Received: from tamvm1.tamu.edu by RELAY.CS.NET id aa14417; 27 Jul 90 13:03 EDT Received: from TAMVM1.TAMU.EDU by tamvm1.tamu.edu (IBM VM SMTP R1.2) with BSMTP id 7485; Fri, 27 Jul 90 12:02:39 CDT Received: by TAMVM1 (Mailer R2.03B) id 5703; Fri, 27 Jul 90 12:02:38 CDT Date: Fri, 27 Jul 90 12:02:14 CDT Reply-To: The TUG DVI driver standards discussion list Original-Sender: The TUG DVI driver standards discussion list From: "Nelson H. F. Beebe" Subject: Comments on ``Handling rounding...'' X-To: driv-l@science.utah.edu To: Chris Rowley Sender: DRIV-L%edu.tamu.tamvm1@net.cs.relay Technical points about the draft of ``Handling rounding to device units---modified DVItype algorithm'' have already appeared. These comments are smaller: (1) In two places, fix a spelling error: algorithim -> algorithm (2) In 1.1, the rounding uses the ceil() function. This assumes that the values to be rounded are positive, which is not the case for some movements produced by TeX (I know about this, because I'm responsible for a bug in at least one of my DVI drivers where positive values were assumed in the PIXROUND() macro; that bug was fixed early in the 3.0 DVI driver development in the fall of 1988). I believe that it would be better to rephrase the section to speak in terms of round-to-larger-in-absolute value. (3) In 1.2, paragraph 2, `x-escapement' would be better phrased as `horizontal escapement'. (4) In the last paragraph, I was unclear about the application of the maxdrift correction; was it to be applied at once, or only max_drift pixels at a time. Other readers have also noticed this, and enlarged upon it, noting that the idea is to spread the correction in max_drift pixel chunks. Note, however, that lines in verbatim mode (i.e. fixed-width font) like ****************************************************************************** * * ****************************************************************************** will exhibit the maxdrift problem, and the proposed algorithm will not fix it (I think the problem for such extreme cases probably is insoluble). The example is not a wild one; it is typical of text found in program comments that is exhibited in computer-related documents. We have discussed this example before; I don't want to precipitate new discussion on it, but perhaps the draft could note that such problems are not solved by the proposed maxdrift algorithm. [I've had the spacing problems produced by such examples reported as a driver `bug' a great many times by users of my drivers; consequently, the DVI 3.0 drivers permit maxdrift to be set by the user, possibly to 0, so each character is positioned separately.] ------- ========================================================================= Date: Fri, 27 Jul 90 11:07:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Some comments from John Gourlay Some comments from John Gourlay regarding my proposal to allow x'00's to be included on the ends of the records of TeX binary files. Date: Fri, 27 Jul 90 10:18:58 EDT From: jsg@arbortext.com Subject: Votes on ammendments 1---yes 2---no I think that changes to the file formats is beyond the scope of driver standards. Also, I think that there are too many variations on the file transfer problem to handle, and trying to handle one of them will open the floodgates of demands for more. 3---no Ditto. 4---no Ditto. 5---yes ========================================================================= Date: Fri, 27 Jul 90 11:20:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: AFMs do not have italic correction or interword space Nelson Beebe said: >StvB observes ``the italics correction and some spacing >parameters (default interword space) are not in the afm >files.''. >I've just checked the AFM 3.0 document, dated March 8, 1990, >and that observation appears to be correct. There is >support for kerns and ligatures, and specification of an >italic angle, but neither the italic correction nor the >interword space is present. I've pointed all of this out to Adobe. They are getting all of Appendix G, the first six or so pages of Appendix F (both from the TeXbook) the TFM format from TFtoPL, and some general comments on how best to obtain some numbers for the other parameters (I have noticed a definite lack of comprehensive documentation on these topics and may put something together in the quasi-near future... unless someone is willing to take that task off my hands). -dh ========================================================================= Date: Fri, 27 Jul 90 15:38:08 EDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: jsg@ARBORTEXT.COM Subject: Re: AFMs do not have italic correction or interword space Surely it's not as if they haven't heard about this stuff before! I spent many hours talking with someone from Adobe about the TFM information and why their AFM files wouldn't suffice for the Lucida Math fonts. ``I've pointed all of this out to Adobe. They are getting all of Appendix G, the first six or so pages of Appendix F (both from the TeXbook) the TFM format from TFtoPL, and some general comments on how best to obtain some numbers for the other parameters (I have noticed a definite lack of comprehensive documentation on these topics and may put something together in the quasi-near future... unless someone is willing to take that task off my hands).'' John Gourlay jsg@arbortext.com ========================================================================= Date: Fri, 27 Jul 90 17:23:37 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: hh=pixel_round(h)+/-max_drift versus hh=hh+/-1 The tests which I have run concerning how drift correction could be done have not been very conclusive. The fonts which I have found which have a three-pixel error on "m" include: cmr8 scaled\magstep5 (19.9) tested cmr9 scaled\magstep5 (22.4) cmr10 scaled\magstep5 (24.9) cmr12 scaled\magstep5 (29.9) cmr17 scaled\magstep5 (42.3) tested cmbx5 scaled\magstep4 (10.4) cmbx6 scaled\magstep3 (10.4) cmbx6 scaled\magstep5 (14.9) cmbx8 scaled\magstep2 (11.5) cmbx9 scaled\magstep1 (10.8) cmbx9 scaled\magstep2 (13.0) cmbx9 scaled\magstep3 (15.6) cmbx9 scaled\magstep4 (18.7) cmbx9 scaled\magstep5 (22.4) cmbx10 scaled\magstephalf (11.0) tested cmbx10 scaled\magstep1 (12.0) cmbx10 scaled\magstep3 (17.3) The numbers in parentheses give the effective point sizes including the scale factor. (All fonts are 300 dpi fonts for a writes-white device.) Tests were run with both drift corrections for the three indicated fonts. For the larger effective sizes, the gaps between letters is larger, so any effects of drift correction are less noticeable. The test using cmbx10 scaled\magstephalf, however, did show some differences. The test text I used consisted of: mmmmmmmmmm mmmmmmmmmm mmmmmmmmmm mmmmmmmmmm mmmmmmmmmm \par mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm \par This is some sample text to test intra-word spacing algorithms within DVI drivers. The need for such testing is to reduce the visual disruption to intra-word spacing caused by the character widths of fonts used by \TeX\ not being exact multiples of the device resolution. The basic idea is to space characters within a word according to their ``ideal'' spacing (``ideal'' being defined by the font designer) and place any accumulated roundoff errors between words. However, kerning within words as well as overprinting of accents complicates matters. Further, it is necessary to periodically synchronize the positioning error so that accumulated error from unusually long words such as ``supercalifragilisticexpialidocious'' does not adversely affect the inter-word space. \par DRIV-L Committee discussions \par a-committee discussions \par b-committee discussions \par c-committee discussions \par ab-committee discussions \par ac-committee discussions \par abc-committee discussions Labelling the two techniques #1 (set hh = pixel_round(h) +/- max_drift) and #2 (increment or decrement hh to bring it closer to K*h), the following are some of the [mixed] results: o The word "multiples" printed differently: #1: the m and the u were closely spaced (although it didn't look too bad) #2: the m and the u had normal spacing while the l and t were too close together The differences are slight, but #1 looked better. o The word "accumulated" was also different: #1: the m and the second u were too close together #2: the m and the second u appeared more naturally spaced In this case, #2 worked better. o For the "committee" tests, method #2 was better except in the case of "ab-committee" where the two es were one pixel closer together than the es of the other committees. o Method #2 was unacceptable on the ten-m and five-m tests. In the case of the ten ms, the total drift was more than the width of the space. This resulted in overprinting of successive ten-m groups. In the five-m test, the gap was almost completely closed-up. (Of course, these m-groups are hardly representative of realistic words.) There does not seem to be a clear winner between the two for normal words. However, for words with ms very near the end, method #1 would likely be better since it avoids pushing letters too far into the word space. Therefore, it is best to stick with method #1. ---Tom Reid ========================================================================= Date: Fri, 27 Jul 90 16:34:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: hh=pixel_round(h)+/-max_drift versus hh=hh+/-1 Thank you for the report, Tom. Since the change for allowing drift was never discussed by the committee, I'm going to go ahead and just change that section back to conformance with DVItype. -dh ========================================================================= Date: Fri, 27 Jul 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: Rounding in typewriter type Nelson Beebe brought up the question of handling the typesetting of: ******************************************* * * ******************************************* correctly in the output. We had discussed this issue previously and toyed with various ideas on how to get the optimum results for this case. Nelson's current solution is to allow users to change the max_drift for the whole document to 0 at run time. While this might "improve" the verbatim sections, I suspect that the rest of the document's appearance would be worsened. Perhaps a better approach would be to provide a \special with a scope of ``box'' (see our report in TUGboat 10#2) which changes max_drift to 0 for the scope of that box only. Adding this into the new verbatim macros for LaTeX would be fairly trivial. Sensibly implemented plain TeX verbatim macros could also handle this without too much difficulty. -dh ========================================================================= Date: Fri, 27 Jul 90 17:11:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Structure of the standards Since Joachim mentioned his proposed structure of the standard fairly recently, I thought that I'd at least mention who I think the standard will best unfold itself. First, after much thought, it occurred to me that a linear tiered standard is obviously going to be worthless. As an example, suppose that color support falls under level 3 and graphics primitives fall under level 1. Does this mean, then, that someone who wants to implement color in their driver must also provide graphics primitives if their color support is to be "standard"? I hope not. Instead, it has occurred to me that a more diversified standard is necessary. The "Level 0 standard" will be required of all drivers (and perhaps should be relabelled, "base requirements for DVI drivers"). From here, what we can do is put together standards on various topics that are deemed important. Thus we will have, for example, a standard on printer-specific fonts, a standard on graphics primitives (perhaps multi-tiered), a standard on graphics inclusion (again, multi-tiered most likely), a standard on color support, user interfaces, etc. Some items will require conformance to other items (e.g., graphics primitives cannot be implemented without also implementing the base standard on \special commands, etc.) Somewhere along the line, I'll put together a list of topics that we should consider (by no means exhaustive) and set up some procedures for dealing with this, but first, we really need to get the level 0 driver standard in order. I would like to be able to have this available at Cork. -dh ========================================================================= Date: Fri, 27 Jul 90 19:07:21 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: "Thomas J. Reid" Subject: Re: Rounding in typewriter type In-Reply-To: Message of Fri, 27 Jul 90 16:42:00 PDT from On Fri, 27 Jul 90 16:42:00 PDT Don Hosek said: >Nelson Beebe brought up the question of handling the typesetting >of: > >******************************************* >* * >******************************************* > >correctly in the output. We had discussed this issue previously >and toyed with various ideas on how to get the optimum results for >this case. Nelson's current solution is to allow users to change >the max_drift for the whole document to 0 at run time. While this >might "improve" the verbatim sections, I suspect that the rest of >the document's appearance would be worsened. Perhaps a better >approach would be to provide a \special with a scope of ``box'' >... > >-dh I'm not opposed to using a \special; but I think that we should consider other methods first. The technique which I use in my driver is to check all of the TFM widths of the characters for having the same value when the font info is first loaded. This works for cmtt fonts, but if someone has a "mono-spaced" font with even one character different (such as ff, fi, fl, ffi, and ffl ligatures with double or triple widths) the method will fail. I don't like the idea of exposing max_drift to the end user. I think that it is a detail that the user should not be bothered with. ---Tom Reid ========================================================================= Date: Fri, 27 Jul 90 23:07: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 rounding algorithm Date: Fri, 27 Jul 90 23:11:29 PDT From: cwitty@csli.Stanford.EDU (Carl Witty) Subject: DVI rounding algorithm My reaction: Grody. Sickeningly ad-hoc. But, if it works well most of the time, it's good enough, I guess... Sigh. Carl Witty cwitty@cs.stanford.edu ========================================================================= Date: Sat, 28 Jul 90 09:42:14 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 ; FRI, 27 JUL 90 17:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster Don: Very good idea to get in touch with Adobe. I do appreciate it. StvB ========================================================================= Date: Sun, 29 Jul 90 22:26: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: rounding RFC Date: 28 Jul 1990 16:09:17 CDT From: Scott.Allendorf@IOWASP.PHYSICS.UIOWA.EDU Subject: RE: rounding RFC To: dhosek@YMIR.CLAREMONT.EDU Message-id: X-Envelope-to: dhosek X-VMS-Original-To: INET%"dhosek@ymir.claremont.edu" Don, I just recently picked up a copy of the specification for handling rounding to device units v0.01 and have just a few comments. 1) algorithim should be algorithm (unless my American English bias is showing). 2) Section 1.1 You state that the conversion should be done as ceil(Kn). The current DVITYPE does do this for calculating the size of rules, but all other conversions are done via the PASCAL round function, i.e., everything is rounded to the nearest integer via the following set of rules: round(x) = trunc(x + 0.5) (x >= 0) trunc(x - 0.5) (x < 0) where trunc(x) = "greatest integer <= x" (x >= 0) "smallest integer >= x" (x < 0) 3) Section 1.2 In order to have the max_drift correction applied at the same place (e.g., between the same letters) regardless of the device resolution, it would seem to me that one would want the max_drift parameter defined to be an actual distance rather than a number of pixels. Since 2 pixels was the original value of max_drift in the days of 200 dpi devices, perhaps max_drift should be defined as 0.01 inches (or 1% of the dpi value). This would, unfortunately, change the max_drift value on most current printers to 3. Cheers, Scott Allendorf Department of Physics and Astronomy The University of Iowa P.S. How close are you to releasing the entire set of VMS change files? ========================================================================= Date: Mon, 30 Jul 90 17:32:05 MES Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: XITIJSCH@DDATHD21.BITNET Subject: Re: Rounding in typewriter type Comments on Tom's comments: > I'm not opposed to using a \special; but I think that we should > consider other methods first. I am opposed to the fact that a \special is invented for every new thing we want to implement. This will lead in ca. 245 different operating codes (many of them redundant!) and >245 different specials to implement. As Nelson has said about a year ago: Four DVI Commands that yield 90% of the code of a driver is not appropriate. > The technique which I use in my driver is to check all of the TFM > widths of the characters for having the same value when the font > info is first loaded. This works for cmtt fonts, but if someone > has a "mono-spaced" font with even one character different (such > as ff, fi, fl, ffi, and ffl ligatures with double or triple widths) > the method will fail. We will switch to this method, too. We will not allow double and triple widths because typewriter fonts usually don't have ligatures. (E.g., in cmtt10.mf you find the statement ligs:=0 to suppress ligature generation.) > I don't like the idea of exposing max_drift to the end user. I > think that it is a detail that the user should not be bothered > with. YES!!!! Joachim ========================================================================= Date: Tue, 31 Jul 90 06:17:05 CDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: UCIR001@FRORS31.BITNET HELO FRORS31.BITNET TICK 0001 VERB ON MAIL FROM: RCPT TO: DATA Date: 90/07/31 at 12H24M33 (French time) To: DRIV-L@TAMVM1 From: UCIR001@FRORS31.BITNET (Bernard GAULLE of CIRCE CNRS) Return-Receipt-To: UCIR001@FRORS31.BITNET Subject: my vote Coming back from vacation after a tumultuous (non-ended) era regarding the (un)need of printing facilities in a computing center... I can now respond briefly to the enormous amount of mail I received in few days. My vote first: Amendment 1: YES Amendment 2: NO Amendment 3: NO Amendment 4: NO Why? I agree with Nelson's arguments. I can't figure that we standardize what is elsewhere a bug (X'00'). Garbage isn't a normal thing in a DVI a PK or a GF file and must be eliminated before becomming a DVI, PK or GF file. Drivers work normally on healthy files| Amendment 5: YES About, a- margin: 1 inch (the standard one) is the standard margin. My XEROX driver don't use this default and automatically center the DVI page on the sheet. Since it's often fine this is a big error for many reasons i've no time to discus now. But i'd be glad if on option a page/document might be centered. Also ok for an origin changeable at run time (proposed by Joachim). b- rules: Tom's opinion/argument is right c- ? (I forgot it) Congratulations for the good job done here on this list. This is a little lengthy but efficient. Fine| Bernard GAULLE . QUIT ========================================================================= Date: Tue, 31 Jul 90 12:11:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Amendment 1 Amendment 1 has just received the minimum number of votes to pass and is now officially part of the standard. The vote total was:5 votes for, 0 votes against, 4 votes not received. The amendment is duplicated below: Amendment: Change margin of error tolerance (S4.3.2) Amendment number: 01 Submitted by: Don Hosek Date: 25 July 1990 Currently says: If a DVI file requests a magnification within 2% of a supported magnification, the driver should use that font without warning. Change to read: TeX and METAFONT compute font magnifications with different precisions. Further, calculations done by TeX and/or a DVI driver are subject to roundoff errors. As a method of accomodating these calculations, if the magnification requested for a font is within 0.2% of a supported magnification, the driver should use the supported magnification without warning. Reason for change: In discussion on DRIV-L, it was shown that rounding errors would not cause a variation greater than 0.2% (and that only in extreme cases at high resolutions). Tom Reid, in his mail of 3-July-1990 gives the numerical proof of this as well as a simple algorithim for handling locating the font when calculations are off slightly as indicated. The purpose of the rounding error calculation is *not* to do things like take care of the case where a user requested cmr10 at 11pt instead of cmr10 at 10.95pt. ========================================================================= Date: Tue, 31 Jul 90 12:16:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: A new member in the voting committee The international representation on the committee has been expanded by one member; Adrian Clark has been submitted as the representative for UKTUG on this committee. For amendments that Adrian does not vote on, only five yes or no votes are required to seal its fate. He is not required to vote on amendments 2-5, but may do so if he chooses. For any future amendments or amendments on which he votes, six yes or no votes are required to seal that amendment's fate. A representative for NTG will be named in the near future. Does anybody have an e-mail address for the contact for the Japanese group? Am I correct in understanding that their leader is now also a vice-president on the board? ========================================================================= Date: Tue, 31 Jul 90 18:35:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Amendments 3,4,5 Amendment 3 failed, 1 vote for, 5 against, 3 votes not received Amendment 4 failed, 1 vote for, 5 against, 3 votes not received Amendment 5 passed, 5 votes for, 4 votes not received Amendment 2 currently stands at 2 votes for, 4 votes against, 3 votes not received. -dh ========================================================================= Date: Tue, 31 Jul 90 19:54:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Re: Amendment summaries and max_drift+rule thickness Tom Reid asked me: >When you post summaries of voting, could you add a short title of the >amendment? -- ie, Amendment 1 (font mag tolerance). This would help >clarify things for people (like me) who don't care to memorize the >amendments by number. The titles don't need to be long. When I post amendment voting results in the future, I'll post the full voting chart to the list; I'll send that to the list shortly. >Also, has the max_drift algorithm been submitted as an amendment? Or >are people suppossed to vote on it as an appendix? What about the rule >thickness amendment? Actually the max_drift algorithm should be considered adopted and ready to be amended (and I wish somebody other than Tom and I would start righting amendments...) I don't think I've seen the rule thickness amendment unless that refers to the comments on how pixel_rule should be best defined. -dh ========================================================================= Date: Tue, 31 Jul 90 19:57:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: Summary of voting to date. |Amendment Number | | | | | | |0000|0000|0111|1111|1112|2222 |1234|5678|9012|3456|7890|1234 --------------------------+----+----+----+----+----+----- Nelson Beebe |YNNN|Y | | | | Bart Childs |YYYY|X | | | | Adrian Clark |ZZZZ|Z | | | | Bernard Gaulle |YNNN|Y | | | | John Gourlay |YNNN|Y | | | | Robert McGaffey |X XX|X | | | | Tom Rokicki |YNNN|Y | | | | Jan Michael Rynning |X XX|X | | | | Joachim Schrod |YYNN|Y | | | | Ralph Youngen |X XX|X | | | | --------------------------+----+----+----+----+----+----- Pass/Fail: |P FF|P | | | | Legend: ------- A Abstain F Failed f failed with chair's tie-breaker N No P Passed p passed with chair's tie-breaker Y Yes W Withdrawn X No vote received Z Not on committee when amendment submitted Amendment 1: Change margin of error tolerance (S4.3.2) Amendment 2: Change padding to end of DVI files (appendix A) Amendment 3: Change padding to end of GF files (appendix B) Amendment 4: Change padding to end of PK files (appendix C) Amendment 5: Change to wording of minimum stack depth (S2.5) ========================================================================= Date: Tue, 31 Jul 90 21:49:00 PDT Reply-To: The TUG DVI driver standards discussion list Sender: The TUG DVI driver standards discussion list From: Don Hosek Subject: FWD: font names yet again For those who might not have seen this... Date: Tue, 31 Jul 90 14:47:53 EDT From: Karl Berry Subject: font names yet again To: tex-archive@SCIENCE.UTAH.EDU I don't know if my last message made it out, but anyway. In preparing the PostScript fonts, I found that things would be nicer if the font names end with weight-shape-expansion instead of weight-expansion-shape, because the expansion is so often ``normal''. If there are no problems with this, perhaps I will write a brief note to TUGboat about this. ::= FTTWSEDD where F = foundry TT = typeface family W = weight S = shape/variation (omitted when normal and expansion is normal) E = expansion (omitted when normal) DD = design size (omitted for scaled fonts) foundry: a = Autologic b = Bitstream c = Compugraphic g = Free Software Foundation (i.e., GNU) h = Bigelow&Holmes (with apologies to Chuck) i = ITC p = Adobe (i.e., PostScript) s = Sun typeface families: ag = Avant Garde ao = Antique Olive at = American Typewriter bb = Bembo bd = Bodoni bg = Benguiat bk = Bookman bv = Baskerville bw = Broadway cb = Cooper Black cr = Courier cs = Century Schoolbook hv = Helvetica gm = Garamond gs = Gill Sans lc = Lucida nc = New Century Schoolbook op = Optima pl = Palatino rw = Rockwell tm = Times un = Univers uy = University zc = Zapf Chancery special: symbol = PostScript Symbol zdingbt = Zapf Dingbats weight: (hairline thin extra light light book regular medium demibold semi bold extra bold heavy black ultra) a = hairline b = bold c = black d = demi h = heavy i = extra light k = book l = light m = medium o = extra bold r = regular s = semi t = thin u = ultra shape/variation: r = normal (roman) (omitted when the expansion is normal, also) b = bright c = small caps h = shadow i = (text) italic l = outline o = oblique \equiv slanted s = sans serif t = typewriter u = unslanted italic expansion: (extra condensed condensed narrow extended expanded wide) c = condensed (by hand) e = expanded (automatic) n = narrow (automatic) o = extra condensed regular (normal, medium) (always omitted) w = wide x = extended (by hand) Univers translation table: 45 = light (unl) 46 = light italic (unli) 47 = light condensed (unlrc) 48 = light condensed italic (unlic) 49 = light extra condensed (unlro) 53 = medium extended (unmrx) 55 = medium (unm) 56 = medium italic (unmi) 57 = medium condensed (unmrc) 58 = medium condensed italic (unmic) 59 = medium extra condensed (unmro) 63 = demibold extended (undrx) 65 = demibold (und) 66 = demibold italic (undi) 67 = demibold condensed (undrc) 68 = demibold condensed italic (undic) 73 = bold extended (unbrx) 75 = bold (unb) 76 = bold italic (unbi) 83 = extra bold extended (unorx)