a27@nikhefh.nikhef.nl (Marcel Prins) (12/08/89)
Hello TeXperts (thanks to D.E.Knuth), We're in trouble and we hope that one of you can help us. We installed TeX on a GOULD NP-1. It passed the trip-test succesfully. There's only one problem left. We have got two dvi2ps programs. The one distributed with TeX and w_dvi2ps from J.B. Wang. When we're printing a dvi-file with the first dvi2ps everything works fine. But.... When we want to print a dvi-file with w_dvi2ps, there seems to occur some problems with the inter-letter spacing. This causes a ragged right margin. In plain text it's difficult to see it, but in the table of contents it looks awfull. Analyses of the two ps files showed a differences in relative movement. Does anybody else noticed this or are we the only one. We like to use w_dvi2ps because the font-scaling, the psfig option and the use of postscript fonts. Can someone help us???? Please! Thanks in advance, Greeting from Holland, Marcel Prins a27@nikhef.nl Gertjan Stil stil@nikhef.nl
pallas@Neon.Stanford.EDU (Joe Pallas) (12/09/89)
In article <583@nikhefh.nikhef.nl> a27@nikhefh.nikhef.nl (Marcel Prins) writes: >But.... When we want to print a dvi-file with w_dvi2ps, there seems >to occur some problems with the inter-letter spacing. This causes >a ragged right margin. In plain text it's difficult to see it, but >in the table of contents it looks awfull. There is an error in the original Neal Holtz version of dvi2ps that has been carried along into most of its descendents. The error is in the character definition section, where it tells PostScript that the character has a non-integral width (x-escapement). The rest of the code does calculations in typical DVI-to-whatever style using the integral pixel width, and so the PostScript interpreter's current position drifts away from what dvi2ps thinks it is. Usually things average out so the difference is not more than a pixel or two. But a long string of repeated characters, like the dots in a table of contents, will accumulate the same error n times. Ordinarily this is easy to fix (change cw to an int, and use PixRound(ce->tfmw, hconv)), but I'm not sure how the PostScript-scaled offsize fonts fit in to this solution. joe
piet@cs.ruu.nl (Piet van Oostrum) (12/13/89)
In article <1989Dec8.184638.13891@Neon.Stanford.EDU>, pallas@Neon (Joe Pallas) writes:
`
`There is an error in the original Neal Holtz version of dvi2ps that
`has been carried along into most of its descendents. The error is in
`the character definition section, where it tells PostScript that the
`character has a non-integral width (x-escapement). The rest of the
`code does calculations in typical DVI-to-whatever style using the
`integral pixel width, and so the PostScript interpreter's current
`position drifts away from what dvi2ps thinks it is.
`
`Usually things average out so the difference is not more than a pixel
`or two. But a long string of repeated characters, like the dots in a
`table of contents, will accumulate the same error n times.
`
`Ordinarily this is easy to fix (change cw to an int, and use
`PixRound(ce->tfmw, hconv)), but I'm not sure how the PostScript-scaled
`offsize fonts fit in to this solution.
`
This does NOT work for Postcript fonts, because the laserprinter keeps its
coordinates as reals (it does not round yhe current position to pixels). So
for these you should keep the position also in reals in the driver program.
This can mess up the whole program. The ``solution'' I used in my dvi2ps
was to ``forget'' the laserwriter position at each DVI POP operation. This
operation is used a lot in things like the table of contents (actually in a
\leaders) and this helps for most cases. If you are driving a real
phototypesetter you probably will want to be more accurate.
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-531806 Uucp: uunet!mcsun!hp4nl!ruuinf!piet
Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete')