Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 UW 5/3/83; site uw-beaver Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!houxm!hogpc!houti!ariel!vax135!cornell!uw-beaver!laser-lovers From: laser-lovers@uw-beaver.UUCP Newsgroups: fa.laser-lovers Subject: Bug in Imagen dviimp Message-ID: <1921@uw-beaver> Date: Sat, 20-Oct-84 01:07:00 EDT Article-I.D.: uw-beave.1921 Posted: Sat Oct 20 01:07:00 1984 Date-Received: Tue, 16-Oct-84 06:16:06 EDT Sender: daemon@uw-beave Organization: U of Washington Computer Science Lines: 40 From: Jan StoeckeniusMy 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. -------