[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

drift zeroing





     -D num
          Set the resolution in dpi (dots per inch) to num.  This
          affects  the choice of bitmap fonts that are loaded and
          also the positioning of letters in resident  PostScript
          fonts. Must be between 10 and 10000.  This affects both
          the horizontal and  vertical  resolution.   If  a  high
          resolution  (something  greater  than  400 dpi, say) is
          selected, the -Z flag should probably also be used.

     -e num
          Make sure that each character is placed  at  most  this
          many  pixels  from  its  `true'  resolution-independent
          position on the page. The default value of this parame-
          ter is resolution dependent.  Allowing individual char-
          acters to `drift' from their  correctly  rounded  posi-
          tions  by  a few pixels, while regaining the true posi-
          tion at the beginning of each new  word,  improves  the
          spacing of letters in words.


It appears then that -e2 -D300 will set maxdrift=2. The meaning
is fairly clear for .pk fonts since dvips handles the bitmaps and
knows exactly how many pixels wide the characters are.

     However it is difficult to imagine what this amounts to in
case of PostScript type 1 fonts whose bitmaps will be generated at
a later time by a PostScript interpreter whose exact rasterization
algorithms are unpublished and known to vary.  I suspect that that
the only settings that could be guaranteed are

 (i) zero drift (by ordering reasonably global recalculation of
the insertion point) after every item causing displacement (such
as a atomic character)

 (ii) zero drift after no more than n items have been placed.

 (iii) never zero drift

     It seems to me that apart from the above drift zeroing
commands from the driver, there is an elaborate deterministic
drift limitation mechanism operated independantly by the
Postscript intrepreter.  If there were none, one would expect that
on repeating a single character n times the expected drift would
be n/2 pixels when maxdrift is set to infinity.  But the drift
seems to be very much smaller--- although not bounded above; 
it looks much as if there is a pseudorandom process at work 
to trim or augment the advance in pixels for the character. That
is a bit hard to believe because the interpreter has the means
do better, ie. to run a maxdrift control operation like 
dvips does with .pk fonts.  One possibility is that the 
observed accumulated drift of say 6 pixels after 60 characters 
x have been printed is not due to a pseudo gaussian process but
to disagreement between what the interpreter thinks the real 
character width is and what TeX thinks it is. If this latter
is the true state of affairs, do drivers dispose of commands
to communicate desired maxdrift values to the Postscript
interpreter, and do they actually do so? 

                Laurent Siebenmann

                       
PS.  Andy Trevorrow indicates that (at least with .pk fonts)
he enforces maxdrift=2 in OzteX.