From: baldwin@csservera.scs.usna.navy.mil (J.D. Baldwin)
Newsgroups: comp.periphs.printers
Subject: Re: QMS's ESP brain-dead?
Date: 15 Sep 92 20:53:33 GMT
Organization: Comp. Sci. Dep't., U.S. Naval Academy, Annapolis, MD
In-reply-to: weingart@wesley.imagen.com's message of 14 Sep 92 11:33:34 -0400

For those of you not reading to the end of this long (with much
included text) post, please note that at the end I extol the virtues
of the wonderful QMS PS1700, which I wouldn't trade away despite the
annoying problems I'm having with it.  I AM A SATISFIED QMS CUSTOMER
and they'll take this printer away from me when they pry it from my
cold, dead fingers.  That said, let the bitchfest begin:

weingart@wesley.imagen.com (Phil Weingart) writes, replying to me:
>jdb> Is it me, or is QMS's so-called "ESP" brain-dead?  

Phil's answer seems to be, "Both, sorta."  (I know he'd disagree with 
this summary.)

[Summary of my problem:  QMS dumps PS code and eats some text, notably
 C code.]

>jdb> So, of course, I called tech support and the explanation amounted to,
>jdb> "It is a very hard problem to determine input language, and ESP is an
>jdb> Artificial Intelligence [hahahaha!--the rep's exact words, I swear]
>jdb> program to do so.  There will always be files that will 'fool' the
>jdb> program and there's just nothing to do about it.  Such problems,
>jdb> however, are rare."
>
>ESP scans the first 256 characters of the incoming document, parses out
>Document Option Commands which control the printer's features, then
>takes a statistical sample of character pairs and compares that sample
>against profiles of samples taken from files of known language.  If the
>occurrence of certain characteristics exceeds certain thresholds, a
>choice is made; if no choice can be made, a default language
>(user-configurable) is selected.  
>
>Clearly, the choices made by ESP will be determined by the files
>included in the training suite.  For Release 1 of the PS 1700, the
>training suite included PCL4 files, HPGL files, postscript files, LN03+
>files, but regretably DID NOT include email files, UNIX database files
>(/etc/hosts, e.g.), or C program listings.  

"Regrettably," is right!  I'm not going to flame this "training" regimen,
because I've done dumber things than this in my life.  But not many.  
"Email files, UNIX database files, [and] C program listings" make up
about 80% of text stuff that gets printed around here.  Sure, we're a
Computer Science department and not a business, but we're hardly unique.

>These excluded types of
>files are problematic for a statistical approach because they contain
>stylized characters or formats which are not characteristic of raw text
>files.

Mmm-hm.  More about this below.

>In the new Crown Architecture releases (Release 4.x for the PS 2000,
>Release 2.x for the PS 1700) ESP has been trained with UNIX flat files
>of various sorts, and will print your C programs and email listings
>reliably.

"Reliably"?  I know a thing or three about pattern-matching myself and
the original tech was right:  there will always be cases in which such an
algorithm fails.  I'm sure the new release will be much better, maybe
even "good," but don't use words like "reliable" unless you really mean
"reliable."

And can you give me a hint as to when this new release will be out?
And how is it implemented?  A new ROM?

>Until the upgrade is released, you have several options:
>
>       1) logical queues which force the emulation at the printer;

Not satisfactory.  Various DOS and OS/2 platforms mount this printer
(or would, if it worked right) as "LPT3:" using Sun's PC-NFS or IBM's
LPRMON.  If I have to split PS and text into logical queues, I have to
split them between LPT3: and a non-existent LPT4: and even that's not
much of a solution--users shouldn't have to pay attention to that.
        
>       2) use the "qpr" utility supplied with the host software, with
>       a command line switch to force the emulation;

Worse than the above suggestion for a similar reason:  I have to use
"lpr."

>       3) configure the port to interpret all files as postscript, and
>       filter all your text files to postscript using "prtpost" which
>       was supplied with the host software, or any other
>       ascii-to-postscript converter;

It's a kludge, but . . . it just . . . might . . . work!  I think I'll
give this one a try.

>       4) install a version of the host software which I modified to
>       scan the first line of the incoming file and append a command
>       to force the correct emulation at the printer.   [Instructions
>       on obtaining this were deleted and will be mailed to anyone 
>       who asks.]

I'll look into this, but I'm going to run with option #3 first.

>A few comments about your original post:
>
>jdb> As for PostScript, there's no excuse for dumping PS code to output!  The
>jdb> documentation says that ESP scans the first 256 characters to try to
>jdb> determine the language.  For PostScript files, that should require TWO
>jdb> characters:  the "%!" at the beginning of any non-brain-damaged app's
>jdb> generated PS.
>
>If "magic number' sorts of tests were the only approach to the problem,
>your comment would be correct.  We're not scanning for a magic number.

You make it sound as if it's an either-or proposition.  What's wrong
with the following?

        if (first_two_chars_are_%!) 
                set_postscript_mode;
        else
                do_all_the_ESP_hoo_ha;

This can't possibly be hard to implement in a program billed as
"Artificial Intelligence."

>Whether we *should* be using a magic number approach is debatable.  If
>we attempted to decide based on the start of the file we would be
>subject to failure due to language ambiguity.  My personal opinion is
>that the ambiguities are few enough to make a good magic number
>algorithm possible, but the QMS organization disagrees with me.

Well, if they can pull off this ESP trick, they'll be vindicated.
There is nothing ambiguous about "%!" though.  Well, okay, you can 
contrive a text file that starts with those characters, but then you
deserve what you get (or rather, what you don't get:  a printout).

>jdb> We have been using an Apple LaserWriter for three years, and it very,
>jdb> very rarely burps on PostScript / ASCII recognition.  Once in a long
>jdb> while, it will spit out PS code, and I've never seen it "eat" an ASCII
>jdb> file.
>
>Apple Laserwriter has no postscript/ascii recognition logic that I know
>of.  You must have a script which checks for "%!" and says, "if
>present, postscript, if not, ascii."  The same logic would produce the
>same results on the PS 1700, or on any other postscript/ascii printer.

You are correct, and I was wrong about this one.  I checked, and our
LaserWriter was installed using Sun's TranScript before I became
sysadmin three years ago, and I have never even noticed.  If a
three-year-old program (probably considered obsolete now; our print
server is a Sun 3/50) can do it with a program whose executable is
only 24K, why can't this state-of-the-art-Artificial-Intelligence-insert-
your-favorite-buzzword-here wonder of modern technology?  Never mind.
Rhetorical question.

>jdb> EVEN SOMETIMES WITH THE LOGICAL QUEUES, it fails about 20-30% of
>jdb> the time.
>
>This would never happen if your queues were set up properly.  Call me
>if you need help.

I have no idea why this was working this way, but reboots all around
and a printer reset fixed the problem.  The text files in question
were e-mail files, I believe (which I didn't know was a problem).
Further testing on my part shows that some e-mail files get eaten,
some don't.  PS code getting dumped was code that included %! but not
the words PS-Adobe (yes, some applications leave this off).

Anyway, thanks for the help.  I think it will be . . . helpful!  And,
by the way, this *is* a great printer.  It's really unfortunate that
it has this design flaw (really rather serious but fortunately
correctable), because the print quality (600 dpi!), processing speed
and printing speed are fantastic.  The duplex printing (of which I was
highly skeptical when we ordered it) works wonderfully.  The
documentation and installation procedure are simple, straightforward
and easy to understand and do.  (Well, we did have two CS M.S.'s and a
Ph.D. installing it, but even the Ph.D. understood it, so it must be
simple.)

I did get several e-mail responses to the original post, most of which
suggested logical queues (which I discounted in my original post) and
some of which had a much lower opinion of ESP than I did!

I consider myself a fairly satisfied QMS customer, overall.  If your
suggestion above about prtpost works, I'll be totally satisfied.
--
 From the catapult of:              |+| "If anyone disagrees with anything I
   _,_  J. D. Baldwin, Comp Sci Dept|+| say, I am quite prepared not only to
 _|70|___:::)=}-  U.S. Naval Academy|+| retract it, but also to deny under
 \      /   baldwin@usna.navy.mil   |+| oath that I ever said it." --T. Lehrer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~