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

Re: Another technical question about arrow-building

> 1) Are there many dvi drivers that will correct for drift between
>    glyphs that have no space or kerning between them?
> 
> 2) Does the dvi driver standard say anything about correcting for
>    drift between glyphs?

Normally, dvi drivers shouldn't compensate for digitization errors
between glyphs which have no space or kerning between them, but if
the actual position (in pixels) is off from the ideal position by
more than maxdrift (a parameter which is usually set to 2 pixels),
then they should.  That's also what the most frequently used dvi
drivers do, I think.

> 3) Composite arrows are subject to digitization errors by the dvi
>    drivers.  For example, MF can guarantee that $\nleftrightarrow$ is
>    rotationally symmetric, whereas if TeX puts
>    <leftarrowhead><arrownegate><rightarrowhead> into the dvi file, some
>    dvi drivers may adjust for drift between <leftarrowhead> and
>    <arrownot> or between <arrownot> and <rightarrowhead>, and this may
>    cause the composite glyph not to be rotationally symmetric.

MF can guarantee that \nleftrightarrow is rotationally symmetric at
any resolution, by making the raster up to one pixel too narrow or too
wide.  The same goes for <arrownot>.  However, the tfm width will remain
the same, so the arrows which you build may come out asymmetric even if
the dvi driver hasn't adjusted for drift between the pieces.

Let me show you an example.

  *        *       *
 *         *        *
******  ******  ******
 *         *        *
  *        *       *

----->  ----->  ----->

We're working at low resolution, so each piece is six pixels wide and
the tfm width, indicated by the arrows below the raster, happens to
be the same, to make things simpler.  The middle piece is assymetric,
so let's make it symmetric at this resolution by making its raster one
pixel wider.

   *
   *
*******
   *
   *

----->

The tfm width has to be the same for all resolutions, so it can't change
just because we change the raster at this resolution.  Now, let's put
the pieces together.

  *      *     *
 *       *      *
******************
 *       *      *
  *      *     *

----->----->----->
            ^
            Pixel overlap

The result is asymmetric.