[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- Subject: huh?
- From: email@example.com (Larry Siebenmann)
- Date: Sat, 14 May 94 04:19:03 +0200
- Content-Length: 2275
> At the point at which the d-accent is being typeset, the `h' position is
> 557.66 pixels, and the `hh' position is 560 pixels. (This was verified
> with dvitype, and is for 300 dpi.) So the drift at this point is more
> than two pixels right here.
I am still utterly puzzled. It seems to me we have to
account for a measured leftward shift of the \v by about 5 pixels
at 300dpi. Your theory claims to explain 2 pixels, the sort of
error I measure for OzTeX. I suspect a bug more than ever. Might
it be a disagreement of .tfm widths with Adobe widths?
Nevertheless it is probably worth understanding the drift
theory. Please contradict anything I say that seems wrong.
The threshhold for drift zeroing:
LS>> Incidentally what is normally the threshold beyond which
LS>> negative hskip allows drift zeroing? (1em?)
JZ> in positive direction it's the value font_space, in the negative direction
JZ> it's 4*font_space of the current font.
TR> Dvips breaks horizontal movements according to the maxdrift
TR> algorithm. That is, movements greater than thinspace, defined as
TR> scaledsize/6, are considered `large' movements and allow
TR> correction for drift. Movements less than thinspace are small
TR> movements and accumulate drift.
It would be better if Jiri and Tom agreed. There is utter disagreement
for negative skips.
One might be tempted to interpret Knuth's view of virtual font
characters as subroutines as implying:
The Principle of congruence (#) One should use push
and pop operations (ie suitable grouping notions) to assure that
two copies of the same virtual character be identical up to a
translation on the pixel grid.
Note that (#) more or less obviates the danger of big drift zeroing
jumps within a virtual character with few components.
However, so far I have seen no driver has either attempted or
achieved this. Nevertheless I see no obstacle to achieving it.
On the contrary, all driver algorithms i have heard about seem to
just plough straight through as if applying a simple-minded
version of dvicopy and then a non-virtual driver. (Well, on
second thought, I cannot really prove this, eg. for Textures; its
true by construction for Oz.)
- Re: huh?
- From: firstname.lastname@example.org (Alan Jeffrey)