[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
drift zeroing
- To: math-font-discuss@cogs.susx.ac.uk
- Subject: drift zeroing
- From: ls@mathp7.jussieu.fr (Larry Siebenmann)
- Date: Sat, 23 Apr 94 03:56:33 +0200
-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.