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

dvicopy+



Reply to Jiri Zlatushka

Dear Jiri,

      The questions you raised about the use of atomic fonts seem
to reduce to a single one: Do max_drift corrections intervening
within a virtual character seriously compromise the quality one
can obtain using atomic fonts at low resolutions?

      For Latin languages we have evidence that only horizontal
drift is problematic.  And TeX as it stands (what of TeX--XeT?)
does privilige horizontal mode (eg there is no vertical kerning).
I will therefore address only the horizontal drift problem.
Note that vertical typesetting can be done in rotated horizontal
mode.

     As I guessed from the outset, your max_drift problem applies
only to .dvi's output by Peter Breitenlohner's dvicopy (and
similar programs such as OzTeX's recent effort) that expands
dvi's involving virtual fonts into dvi's involving only
non-virtual fonts.  Here is documentation from Knuth's VF article
PROVING that your problem does NOT arise when VF's are exploited
as Knuth recommends.

     Device drivers processing \.{VF} files treat the sequences of
  |dvi| bytes as subroutines or macros, implicitly enclosing them
  with |push| and |pop|. Each subroutine begins with |w=x=y=z=0|, and
  with current font~|f| the number of the first-defined in the
  preamble (undefined if there's no such font). After the |dvi|
  commands have been performed, the |h| and~|v| position registers of
  \.{DVI} format are restored to their former values, and then |h| is
  increased by the \.{TFM} width (properly scaled)---just as if a
  simple character had been typeset.

   This leads to the observation that if there were push and pop
commands in standard .dvi format (at least for horizontal and
vertical positioning) and implementation thereof by drivers, your
problem would evaporate. There does not seem to exist anything of
the sort (please correct me).  But perhaps some day driver
standards committees will extend the .dvi standard to include
them.  Since in any case new standards for graphics and color are
inevitable this sort of reform seems possible in the long term.
Unfortunately it cannot be counted on in the short term (say for
the next decade).

       A possibly problem arises with the above push-pop
solution. It is alleged that the push and pop routines cause
many VF previews to be slow. Textures VF preview is *half* the
speed of non-VF preview, apparently because virtual characters
are posted to the screen one-by-one and not by blocks.  Such
slowing will be intolerable for the next decade.  Fortunately,
Rokicki uses "special casing" to get a practical solution for
his Amiga VF driver --- which runs at 20% off non-VF speed.
The benchmark criterion is preview of English in virtual DM
versus CM.
 
    The chief *current* remedy we have to your phenomenon of
inapprortune drift correction is:

 (*)  Set max_drift exceedingly low, (say .6 pixel).  

My impression is that OzTeX does something like this. This
solution is *iconclastic* because it flies in the face of
prevalent and plausible opinion that allowing substantial drift
improves quality (in the absence of dvicopy). I must say that I
am perfectly happy *thus far* with the quality of OzteX 1.6
preview.  The objective performance of this OzTeX solution should
be examined and debated.  Perhaps I have not run the right tests.
Comments please.

     Does "drift zeroing" slow the preview appreciably?
That would be bad news.  Comments please.

     It is interesting to note that Textures, which follows
Knuth, seems to set max_drift=infinity.  Textures' bitmaps seem
to frequently accumulate drift heavily, while the ATM bitmaps
seem to involve less drift than expected.  I conjecture that
Textures bitmaps are always rounded *down* and indeed often "too
far down", while ATM may have a deterministic randomization
mechanism to prevent the buildup of drift; drift does build up
eventually but typically 10 times as slowly as for bitmaps.  (At
very high values of drift (words longer then pagewidth) Textures
has bugs...)

    I recall your informative comments:

 > 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).

   Incidentally what is normally the threshold beyond which
negative hskip allows drift zeroing? (1em?)

   There is an important further means available to suppress
inopportune drift zeroing, namely implicit kerns.  It seems that
at the .dvi level they are treated both notationally and
operationally much like blank characters of arbitrarily large
(??) positive or negative width. In particular drift zeroing is
forbidden at implicit kerns.  

   It seems to me that that this opens the way to a new solution to
your drift problem. It should be possible to produce a new version
"dvicopy+" of dvicopy that will insert "artificial" or "fake"
implicit kerns in place of any given "dangerous" hskip it has to
translate inside a virtual character.  This may require careful
reprogramming since there seems to be a highly efficient protocol
for representing implicit kerns in the dvi by a single eight bit
character. For all I know just now there may be a silly limit to 128
or less implicit kern values.  But that can be gotten around in the
rare cases the process might run out of available implicit kerns by
simply "overshooting" and using a (less than threshold) negative kern
to correct.

    I believe the resulting expanded .dvi's could provide optimal
performance.

    The great advantage of this approach over the remedy (*) is
that the resulting dvi will provide good results with ALL
drivers. This is of capital importance for my idea of using
dvicopy to produce (for electronic archiving) standard atomic
.dvi's in essentially all Latin alphabets. A single font set of
CM typeface will be adequate for essentially all scientific
literature just as Knuth's CM is already adequate and in use for
scientific literature using English. Such an idea is in trouble
if some drivers foul up the accents.

    For example, with approach (*), although OzTeX users will be
very happy, Textures users with bitmapped fonts will find that
umlauts toward the end of *long* German words are misplaced.
(With use of the accent primitive, the whole accented letter is
misplaced, which is perhaps twice as tolerable as accent
misplacement.)  With my "faked implicit kern" approach the results
for Textures should be still better; indeed the drift will be
absorbed between words as Textures clearly intends; and the
results will usually be as good as those obtained using virtual
fonts.

    There are still problems to be faced.  

    In the extreme case where the virtual character is a page
from another TeX job, replacement of all hskips by 
fake implicit kerns would be disastrous.  Accumulated drift 
would cause right justification to become ragged.

    To avoid such disasters dvicopy must be discriminating in
substituting fake implicit kerns for hskips.  It might well to do
such substitution only in virtual characters that have less than
a certain complexity depending on the number of component
characters rules and specials. The complexity function could well
be influenced by items found in the virtual font header. For
instance, when it is dealing with a virtual font that indicates
that its encoding is T_n (Cork being T_1) and that includes a
further comment that its (only) raw font is of type AT_1 the
basic standard latin atomic encoding, then dvicopy might blindly
make a maximum of substitutions. It could also be influenced by
the depth of virtualization. In sum, dvicopy+ is both obliged and
able to make an intelligent choice of hskips to be replaced by
fake implicit kerns.  And standard fonts involved in .dvi archiving
schemes can help by suitably identifying themselves.

    There may be oversights; there may be other ideas to examine.
Thanks again for raising a sensitive matter.

      Cheers,

        larry siebenmann


PS    Since Peter Breitenlohner has not yet intervened, I wonder
if he feels I or we are picking on him.  But the contrary is true.
I am trying to find firm ground for accepting dvicopy's services.