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 Stoeckenius 

	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.
-------