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

Re: huh?



Perhaps the best solution is to have the dvi driver save the current
value of drift when it hits a VF (PUSH), then zero the drift inside
the (PUSH)...(POP), and restore the value of drift at the (POP).  So
unless the virtual characters are particularly complex, the maxdrift
algorithm won't affect the placement of the components of the
composite character.

There is another problem here for the fontinst fonts, which produce
composite characters as:

   (PUSH) ... set the accent ... (POP)
   (PUSH) ... set the letter ... (POP)
   (MOVERIGHT ... the escapement ...)
 
(Yes, I know this isn't quite what you'd expect, but generating
anything else from the CC instructions in an AFM file is tricky).

So the problem here is the escapement MOVERIGHT, which will almost
always be more than thinspace, and so the drift algorithm kicks in.

If the MOVERIGHT were missing, then would the drift algorithm still be
used?  Since semantics of a VF character are meant to be 

   (PUSH) ... (POP) (MOVERIGHT ... the escapement ...)

then will this escapement MOVERIGHT cause the drift algorithm to be
used?

The reason why fontinst generates this last MOVERIGHT is because it
*always* leaves the typesetter in the correct position.  Rather
ironically, this means that in the case of composites, fontinst issues
the appropriate MOVERIGHT, then the dvi driver performs a POP followed
by exactly the same MOVERIGHT.  Sigh...

One possible algorithm for using a VF character is to check to see if
it leaves the current position in the correct position for its
escapement, and if so then just to use the VF code directly, without
surrounding it by (PUSH) ... (POP) (MOVERIGHT ...).  In 90% of cases
(and in 100% of fontinst-generated VFs) this will save an extra level
of PUSHing and POPing.  Do any/all of the current VF drivers perform
this check?

Oh what fun...

Alan.