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

dvicopy problem?



Here Jiri Zlatuska's quick reply to my proposal:

 --------------------- 

>From zlatuska@glingol.ics.muni.cz Mon Mar 21 11:48:06 1994
Date: 21 Mar 94 11:46:13+0100
From: Jiri Zlatuska <zlatuska@glingol.ics.muni.cz>
Subject: your article ``A TeX Atomic Character Encoding for VF and DVI
Standardi
zation''
To: lcs@topo.matups.fr
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

dear laurent:

i would like to turn your attention to one minor point which potentially
creates problems with the idea you expose in the article of yours mentiond in
the subject line.

if one composes charaters with separate glyphs, there should be a very
fool-proof precautions taken by the dvi driver so that no inappropriate
rounding to device pixels takes place in the course of putting separate glyphs
together. i don't think dvi standard addresses this, and indeed some care
should be taken when setting `max_drift' when using characters composed
together on the level of dvi processing, otherwise there is a danger that this
tolerance is exceeded between placement two parts of a character, resulting in
a totally unacceptable result.

without this, i'm afraid the scheme may not be really useful for high-quality
typesetting :-(

i don't think that you addressed this in your article, and i'm sending this
note to your attention just in case this aspect skipped out of your attention
:-)

all the best,

--jiri

 --------------------- 

    Jiri's cluch of objections (pixel rounding, drift, no hints...) were
100% present since 1982--9 in all TeX 2 installations.  They are equally
an objection to the use of BlueSky type1 Adobe CM/PS fonts to this day.
Why is is that people do not sigh with extasy at the improved quality of
the Cork fonts over the CM fonts, while they do just that when they see
middle resolution Blue Sky type1 CM's hinted by Mrs. Horn?  Are Jiri's
objections theory or practice?

    Jiri's drift objection is, if I understand it correctly, quite subtle.
(Please correct me.) It seems to be directed against dvicopy's expansion of
vf's and not (I surmise) against say dvips' mode of exploiting vf's. Almost
all compound characters are two-atom compounds and Rokicki remarks that
ignoring drift seems to work fine when there are few atoms; that is how
dvips stays out of trouble within each virtual character.  Once dvicopy has
acted there arises in principle the possibility of the drift limit being
hit in a long word between a character and its accent where
small hickups are visually disturbing. Could or does dvicopy
prevent this by injecting some sort of standard or special signals into the
expanded .dvi?

     Who is willing on the basis of practical experience to comment on the
gravity of these problems at various resolutions and with various devices?
Dvicopy users and CM/PS users have been constantly exposed to the hazard.

     In particular do the problems presist to the resolution of quality
publishers ie 1200dpi?  I bet not.

      Are driver experts and Peter Breitenlohner worrying about these
problems?

      Thanks to Jiri for his thoughts.

      Comments invited.

      Laurent Siebenmann