Subject: RE: MISC.

From: "J.B. WANG" <[email-masked]>
Date: Tue, 1 May 90 10:09:00 EDT

Hah, I think Pitt's mailer is in trouble again. C.Q. Cheng became
Christophe N. Christoff, which made me wander why I did not know this
individual who is also interested in Chinese computing.

To answer Cheng's question:

 1) PostScript or not is not really the choice of CCNET. It is really the
   choice of computer world, just as if people would accept ASCII some time
   back. Computer text was standardized after ASCII, now it is the time for
   computer graphics and typographics to have a standard. Indeed, in principle,
   any device with graphics capability could display the same effects as
   PostScript, but so far no enough success. It is why Adobe become popular.
   Before PostScript, non-text output depend on some escape sequences more or
   less close to ANSI ones, and each graphics terminal (such as Tektronix),
   and printer (such as QMS, Xerox, HP, LN03P, EPSON and LA75) had there own
   graphics language which is essentially made of escape sequences to
   incorporate multi-byte commands (ASCII single bytes). Also, all the graphics
   and typographic packages have their own output formats. No compatibility
   at all. It pushes computer world to have one de facto standard, and it is
   already known to be PostScript.

   It is not true that a non-PostScript printer (such as HP III) can do
   whatever PostScript can do with equal amount of effort, but if you put in
   100 times effort to program those escapements, you might end up in some
   close effects. A simple example is GoScript which emulates a HP as a
   PostSCript printer.

 2) I had a PostScript device driver in Ch-series, i.e., chtex -w. That I
   develop from scratch, but I also support a version of dvi2ps which is indeed
   a modified version of MIT dvi2ps. In TeX there were similar problems because
   cmfonts are all bitmap fonts, if any font library file were missing, some
   device driver substitute a font of wrong size and/or style. I first pushed
   out a dvi2ps which automatically finds a font of close size and scale it to
   exactly the TFM (TeX Font Metric). Ch-series is all virgin codes, don't
   be confused.

 3) PostScript 1000x1000 font space is only a measuring standard, and the
    detailed scaling and mapping algorithm is far more complicated than that.

 4) Cheng has his own experience in HP device support, he is right about the
   64x64 bitmap fonts, it can at most give you 4 sizes according to the
   4 available resolutions you choose, with the highest resolution, i.e.,
   300dpi, the output font size is 64 x 72.27/300 = 15.4176 pt. PostScript is
   device resolution independent, but there is an optimal bitmap font size
   for a physical font size at 300 dpi.

Yesterday, I received a preliminary version of Byx 2.0 from Dr. Yan, together
with a page of sample HP output. I should say that he has done a good job in
at least two aspects:

1) CiZu input, and full-support of EMACS editing functions

2) Generating smooth fonts.

He put in lots of intensive labor manually smoothed fonts which were rough
after scaling. The printout quality is impressive. There are problems, though,
which we will go over when he is here this weekend.

Oops, I forgot to answer a question Cheng posed, i.e., the accuracy of
pattern matching with scanned bit string (such as 32 x 8 bits for 16x16 fonts)
can be close to 0%. The explanation is simple, how can you have exact
sizes in the real world to match your library files? Again, it should be
resolution independent. In my font scaling mechanism, in principle, the bit
map information is scaled linearly, but there is a lot of round off, thus
bip string matching method won't work.

Sincerely yours,

JB Wang

p.s.: I am seeing duplicated efforts in CCNET, I would really suggest
      alternatives if there exist.