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

rounding and drift

Clarifications from Jiri Zlatushka

    The following is extracted from a recent reply to me.



To: ls@mathp7.jussieu.fr (Larry Siebenmann)
>From zlatuska@glingol.ics.muni.cz Mon Mar 28 10:39:18 1994
Subject: Re: rounding and drift
Organization: Masaryk University, Brno, Czech Republic
Postal-Address: Institute of Computer Science, Buresova 20, 602 00 Brno
Telephone: +42-5-41213125
Fax: +42-5-41212747

hi larry:


    A fairly general point in my view is that tex as it stands
generates device independent code [for the dvi file] BUT a
decent-looking output [derived from the .dvi file] depends on
certain assumptions one may easily break when adding some layers
to dvi code which break them. In particular: when using the code
for a virtual character, there might be some previously
accumulated drift [causing] maxdrift [to be] exceeded somewhere
in the middle of the composite virtual character; compensation
is made there, and one gets relative misplacement of separate
glyphs of the composition.

    dvi code specifies placement in dvi units. The driver rounds
this to printer resolution, but does not compensate immediately:
if one prints out a consecutive sequence of characters, it is
better (and actually specified in dvitype in this way) to put them
adjacent within the printer resolution, accumulate rounding error
(=drift), and to compensate when something [comes along] which
looks [like] a point outside some word (any positive hskip,
negative hskip exceeding some treshold); [but also] when[ever]
your accumulated error has exceeded maxdrift value (2 pixels by
default in most cases).

    The drift issue is important for the *actual* appearance of
the resulting characters; drift is a result of rounding [from
precise .dvi units to less precise printer units.]

    I am aware of one point in which rounding is mentioned
explicitly, and that's inside of the code for dvitype where points
for eliminating drift are specified: there are three possibilities
for that: (i) one exceeds maxdrift allowed, (ii) positive hskip, and
(iii) negative hskip exceeding certain limit (the last one allows
the \accent primitive to generate code which would be independent of
rounding/drift control).

    I don't think verticlal drift [causes] an important problem:
one rounds once at the beginning of the current line and that's
it.  What matters is just the horizontal drift, allowing to
yield different horizontal relative positionng of the parts of a
composite character when printed in different places.

    I'm not aware of any [PostScript type1 format] hints going
across characters one puts together into a composite character
using the ps `seac' command. There is a limit built into the use
of `seac' and that's the unit of measurement one can use in
order to specify relative position of the parts within a
composite character. I think [the result] is inferior to when
this rounding is made by your rarsterizer (be it atm of

    I agree that apart from rounding, the other effects
(differnce between `seac'-positioning and
rasterizer-positioning) are presumably orders of magnitude less


 all the best,