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

Problem with czech accents



Thank you for bringing this problem to my attention.

As far as I can determine, the problem is not with dvips---at least, dvips
is playing by the rules it grew up with.  Let me explain what is going on.

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.

The virtual character for the d-accent looks like

(CHARACTER O 203
   (CHARWD R 0.5)
   (CHARHT R 0.677)
   (CHARDP R 0.0135)
   (MAP
      (PUSH)
      (PUSH)
      (MOVERIGHT R 0.35)
      (MOVEDOWN R -0.1085005)
      (SETCHAR O 47)
      (POP)
      (SETCHAR C d)
      (POP)
      )
   )

So dvips sees a couple of pushes followed by a moveright by 0.35 of
the design size.

Dvips breaks horizontal movements according to the maxdrift algorithm.
That is, movements greater than thinspace, defined as scaledsize/6,
are considered `large' movements and allow correction for drift.
Movements less than thinspace are small movements and accumulate drift.
Since this 0.35 is greater than 0.1667 (by more than a factor of two),
dvips performs a drift correction.  This, of course, slams the accent
into the `d'.

A solution in this case would be to redefine the virtual character to
set the `d' followed by a push, slight backwards movement (in this case,
0.5 - 0.35, or -0.15, less than thinspace if only barely) and then set
the accent (with a putchar rather than a setchar) and perform a pop.
But in general, this does seem to present a difficulty with maxdrift.

Lessening thinspace is probably not a good solution, as already thinspace
is very close to the minimum separation between words.

Another possibility is to carefully go through the .vf files, making sure
each movement is less than thinspace.  If it is more than thinspace, one
possibility is to decompose it into a sequence (maybe a Fibanocci sequence)
of smaller moves less than thinspace.  (I suggest Fibanocci because we
do not want the small moves to have the same drift effect.)

Sometimes I think the maxdrift algorithm causes more problems than it is
worth . . .

Suggestions?

-tom