laser-lovers@uw-beaver (laser-lovers) (10/11/84)
From: ihnp4!cbosgd!ulysses!mb2c!uofm-cv!doug@uw-beaver.arpa With regards to Mr. Stoekenius' reply to my bug report, my name is Douglas Orr, not David. Also, why are the calculations done first converting to the resolution of the target device? Don't you lose a lot of precision this way? While we are at it, am I correct in my surmise that catdvi does an absolute positioning before each character? Is there some reason for this? I am currently writing a program that produces a dvi format file as its output (from a macwrite file) and want to make sure that I am not missing something. -Douglas Orr ihnp4!uofm-cv!umich!doug doug@umich (csnet)
laser-lovers@uw-beaver.UUCP (10/12/84)
From: Jan Stoeckenius <STOECKENIUS@SU-SCORE.ARPA> David Orr's analysis of the bug in Imagen's dviimp is completely accurate. We blew it. The reason this bug was not discovered much sooner is that there is an alternate way to calculate character widths: by first translating them into machine units (pixels) and then back to rsu's. This method is invoked with the -a switch, and works well under the assumption that whatever filter came ahead of dviimp knew the resolution of the target printer (this is the case with catdvi, at least for 240 dpi printers). This is the method we usually use with the program, thereby missing this bug. Jan Stoeckenius Imagen -------
laser-lovers@uw-beaver.UUCP (10/20/84)
From: Jan Stoeckenius <STOECKENIUS@SU-SCORE.ARPA> My apologies for not using Douglas Orr's correct first name in my earlier note. When I blow it I do it in grand fashion. (I can't resist noting, however, that my name was misspelled in the reply.) I also did not mean to suggest that TeX should know the resolution of the target device. We usually don't run TeX and the distribution software on the same machine, and the other software which does use dviimp usually knows the resolution of the output device. To explain why we would want a dvi file generator to know the resolution of the target printer, consider the case of catdvi. Catdvi accepts input from troff, which is expressed in a 432 x 144 dpi coordinate system. It has to fit this input as best it can into a 240 x 240, 300 x 300, or 480 x 480 coordinate system. This problem is made more difficult in that all character widths in troff are calculated from a value expressed in 432 dpi precision for the 6 pt size. If you are using a font not expressly designed for this purpose, you may be off by as much as 1/864 of an inch at 6 point, or about 7 mils at 36pt (which is quite noticeable). To have a chance of doing a reasonable job, catdvi makes full use of the knowledge of how wide every character will be in the output, and how wide troff thought it was. Dviimp could not do this job because it does not, and should not, know that its input came from troff. We want dviimp to use the exact pixel widths of characters so that it does not try to do its own correction for the resolution of the target printer. Yes, catdvi does do an absolute move before each character. This is a historical artifact from the days when we did not have the feature alluded to above. We place characters with the HORZCHAR rather than VERTCHAR commands, and thus had to make explicit advance motions at each character. This mimics the C/A/T typesetter fairly closely, as its character placement commands also did not advance the position (I understand this to have been a common property of analog phototypesetters). We haven't gotten around to having catdvi take advantage of the new feature. Jan Stoeckenius Imagen Corp. -------