Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!tektronix!sequent!mntgfx!gssc!jdm
From: jdm@gssc.UUCP (John D. Miller)
Newsgroups: comp.graphics,comp.windows.misc
Subject: Re: PostScript standard?
Message-ID: <532@gssc.UUCP>
Date: Wed, 7-Oct-87 12:16:29 EDT
Article-I.D.: gssc.532
Posted: Wed Oct  7 12:16:29 1987
Date-Received: Sat, 10-Oct-87 18:02:15 EDT
References: <535@micas.UUCP> <15085@topaz.rutgers.edu> <255@tut.cis.ohio-state.edu> <170@viper.Lynx.MN.Org> <1757@gryphon.CTS.COM>
Reply-To: jdm@gssc.UUCP (John D. Miller)
Organization: Graphic Software Systems, Beaverton Or
Lines: 44
Xref: mnetor comp.graphics:1236 comp.windows.misc:74

sure, you could write your own page-description language (ala PostScript) or
your own document-description language (ala nroff/troff, TeX, etc.).  i think
that a document description PROTOCOL is appropriate.  if you have ever tried
to interface PostScript to another graphics or text interface, you know how
frustrating it is to have to REASON with the stupid thing because it wants to
hide too much from you, the device driver writer.  a language is not the right
interface here.  how many times do you sit down at the terminal and write a 
program that describes the page you want printed?  this is the job of a user-
level app, not a device.  device drivers are supposed to be much lower level
than that - i.e. ESCmumble mumble should be all i have to send across the
serial line to the device to get it to do what i want, NOT "newpath 0 0
moveto 0 0 1 0 45 arc closepath" which is what i would have to send to a 
PostScript device, which would run it through it's Forth-like interpreter,
deal with numbers as FLOATING-POINT and run them through a 3x3 matrix to
finally draw the fricking dots.  no doubt about it, PostScript printers are
SLOOOOOOOOWWWWWWWW, especially for graphics.  

Adobe fonts are nothing to write home about, either.  examine the Adobe
Helvetica, comparing it to "real" Helvetica, and you can see that it is a very
crude approximation.  the "o"s are squished, etc.  blow these fonts way up
and see the flat spots on the arcs and poorly joined lines.  this is not good
stuff.

on the other hand, Bitstream makes WONDERFUL software fonts.  i have been to
their facility in Cambridge and took their little course on their patented
"smart" font technology and it is truly impressive.  a REAL artificial 
intelligence application!!  they also have over 1000 software font faces and
are working their way up to over 2500.  (disclaimer - i have no ties to
Bitstream).

anyway, the point of this whole posting is to strongly encourage you to design
a new document-description protocol that combines the best of all the existing
partial solutions.  ideally, the protocol will have various levels - device,
device-driver, language binding, user-interface, etc.  make your font model
flexible enough to accomodate most any font machinery, but i truly hope that
you encourage Bitstream fonts. :-)  

let me know how it turns out!!

-- jdm
-- 
John D. Miller
Graphic Software Systems (GSS), 9590 S.W. Gemini Dr., Beaverton, OR, 97005
...!{tektronix!verdix}!sequent!gssc!jdm                     (503) 641-2200