From: weingart@wesley.imagen.com (Phil Weingart)
Newsgroups: comp.periphs.printers
Subject: Re: QMS's ESP brain-dead?
Date: 14 Sep 92 15:33:34 GMT


Replying to baldwin@csservera.scs.usna.navy.mil (J.D. Baldwin) Message-ID: <BALDWIN.92Sep11135258@csservera.scs.usna.navy.mil> Date: 11 Sep 92 17:52:58 GMT

jdb> Is it me, or is QMS's so-called "ESP" brain-dead?  
jdb> 
jdb> But we have a new QMS PS1700 and without a logical queue to force PS or
jdb> ASCII recognition (which is less than desirable in many situations),
jdb> and even sometimes with the logical queues, it fails about 20-30% of
jdb> the time.
jdb> 
jdb> For example, it was "eating" most C files I would send it.  
jdb> 
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.  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.

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.  Until the upgrade is released, you have several options:

	1) logical queues which force the emulation at the printer;
	
	2) use the "qpr" utility supplied with the host software, with
	a command line switch to force the emulation;

	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;

	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.  It works pretty
	well.  You can get this by logging into gatekeeper.imagen.com
	(161.33.3.1) with anonymous ftp, changing to
	pub/cts/QMSoft_release, and getting QMSesp.tar with binary
	ftp.  If you don't have ftp access, send me email and I'll
	email the software back to you.

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.
The single occurrence on "%!" is not sufficient to exceed the threshold
and force ESP to postscript.  I do not think ESP assigns any positional
weights.

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.

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.

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.


Phil Weingart, Senior Application Support Specialist                   QMS Inc.
QMS Customer Technical Support                                    1 Magnum Pass
Phone: 205-633-4500    Fax: 205-633-3716                       Mobile, AL 36618
weingart@imagen.com                                                         USA