manly@UMASS.BITNET (06/08/87)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hello everyone. I am submitting this both to LASER-LOVERS and INFO-VAX, so my
apologies to those who get it twice.
I have just spent the last week reviewing all the LASER-LOVERS entries since
March 1986, and have been impressed with the amount and usefulness of the
information which has been contributed. As I might have expected, however, I
have not yet located precisely the information I am looking for, so I am
posting the following request for information.
The facts -- we need a printer to do the following:
A) Print 10-15K pages per month usually
B) Not die if pushed to 30K for one month a year (final exams)
C) print standard ascii text files
D) either be supported by WordPerfect, or have a simple enough printing
language (escape chars for underlining and subscripts and so on) that
a printer definition could be written.
F) have support for printing TeX DVI output files
G) have support for determining page counts, either through modified
print symbionts or some other mechanism.
Amherst College has been running two LN03+'s for over a year now. We have been
doing an average of 10,000 pages per month between them, although at finals
time (when students are printing their theses) that has gotten as high as
60,000 pages printed in one month. The LN03's really are not designed to handle
this load continuously, and so we are planning to purchase additional laser
printing hardware. We will probably purchase two of whatever printer we
finally decide upon.
Basically whatever printers we buy should be able to print 10 to 15 thousand
pages a month and not explode if they are pushed to twice that for a few weeks
a couple of times a year. If they need to be serviced or cleaned following
such abuse, fine -- but they MUST NOT be prone to failure during such high
volume work.
The language the printers use is not tremendously important, so long as it
works and does all things we require, and our requirements are fairly modest,
since it will be primarily a word processing support machine.
The printers must be able to print standard ascii text files, must either be
supported by Wordperfect, or use an escape sequence language (not a page
description language like Postscript) so we can write our own Wordperfect
printer definition.
The printer must have support for TeX DVI files. A preprocessor would be fine,
although a special symbiont (such as the Talaris font manager) would be better.
Whichever method is used, it MUST be able to read PK files directly (no
conversion to PXL, GF, or device specific font formats.) We have far to many
fonts to have to duplicate the information in a special form.
But here is the BIG ITEM. PAGE COUNTING. There MUST be a way to track the
page counts of jobs printed without parsing the entire output stream. I simply
cannot believe that we are the only installation that charges for pages
printed, so someone else must have dealt with this problem before.
We have so far investigated only the QMS 1500, Talaris 1500, and HP 2000
machines, each of which has its advantages and disadvantages. We are
particularly interested in the 1500 model of each, which uses the new, upgraded
Ricoh engine. Does anyone have any experience with these units?
In general, I will listen to whatever anyone has to say, but I am much more
interested in listening to people who are actually using the equipment they
want to talk about. As usual, I will post a summary of responses to the net.
Remember, though, we need higher volume machines, not variations on the LN03 or
the Apple Laserwriter.
Actually, while I'm on the subject of Laserwriters and Postscript, I must say
in advance that, after reading LASER-LOVERS, I am somewhat skeptical of
Postscript in an environment like ours. Many of the messages have expressed
difficulty with printing simple ascii text documents and Wordperfect output,
not to mention the attendant accounting difficulties. Several of the notes also
suggested that at this point, TeX DVI output on postscript machines is not all
it could be either. So Postscript seems to lose across the board on this one,
although if someone would care to refute (drawing on experience of course)
these objections, I'd love to hear them.
As an addendum, I should point out that the LN03's have proven to be very
robust despite the abuse they have taken running unattended in a sometimes
hostile student environment. Only when we pushed them to nearly ten times
their recommended duty cycle did they start to fail. And even then, most of
the problems were the result of inexperienced (and harried) student handling
and not due to intrinsic mechanical limitations. The engines, as far as I have
been able to ascertain, DO NOT overhead. Ever. One of them withstood 20,000
pages printed out in one weekend with no mechanical problems of any kind. But
they simply are TOO SMALL for the kind of demands which will be placed on them
next year.
Thank you all for your attention.
- jwm
John W. Manly Telephone: (413)-542-2526
System Manager BITNET: JWMANLY@AMHERST
PO BOX 1801
Amherst College
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~stevesu@copper.UUCP (06/14/87)
(I am cross-posting this to comp.laser-printers and comp.text, because it doesn't have much to do with VMS.) In article <8706120255.AA08855@ucbvax.Berkeley.EDU>, manly@UMASS.BITNET writes: > The printers must be able to print standard ascii text files, must either be > supported by Wordperfect, or use an escape sequence language (not a page > description language like Postscript) so we can write our own Wordperfect > printer definition. > > But here is the BIG ITEM. PAGE COUNTING. There MUST be a way to track the > page counts of jobs printed without parsing the entire output stream. > > Actually, while I'm on the subject of Laserwriters and Postscript, I must say > in advance that, after reading LASER-LOVERS, I am somewhat skeptical of > Postscript in an environment like ours. Many of the messages have expressed > difficulty with printing simple ascii text documents and Wordperfect output, > not to mention the attendant accounting difficulties. Several of the notes > also suggested that at this point, TeX DVI output on postscript machines is > not all it could be either. So Postscript seems to lose across the board on > this one, although if someone would care to refute (drawing on experience of > course) these objections, I'd love to hear them. Actually, LaserWriters are great little devices. However, since page description languages (such as PostScript) and printers that accept them (such as the LaserWriter) are new and radical ideas, they require some adjustments in the way you think about hardcopy. Page counting is a good example. Counting pages in the host has been an arbitrarily hard problem ever since printers could do more than simply printing characters, line feeds, and form feeds. A PDL (page description language) printer merely shows you that it is impossible, instead of just hard, to count pages on the host. The solution is obvious, in hindsight--count pages in the printer (which has a perfect picture of what is going on) and transmit it back to the host somehow. The LaserWriter has a few facilities specifically for page counting, and the (Unix) driving software distributed by TranScript has an accounting mode in which it asks the printer, at the end of each job, for the number of pages printed, and records that number in an accounting file along with the name of the submitting user. (I don't know if the DEC Postscript printers, the LPS-40 and the LN03R, have this sort of functionality.) Doing page counting in the printer leads to the second major adjustment: you can no longer think of a printer as an output- only device, or of its driving software (print symbiont) as a one-way filter. The driving software must be able to carry on a little dialog with the printer, by reading characters back. The third adjustment is to realize how much more text processing can be done on the processor down in the printer, and to stop working so hard in the host software. Traditional text- formatting software, that expects to talk to "dumb" output devices using low-level escape sequences, cannot make use of the more powerful features of a PDL printer. Use the right tool for the job! If you just want listings, get a line printer--don't ask your fancy laser printer to accept unformatted input. If you want to make all of the formatting decisions in host software, you don't need a PDL printer. The PDL printer can be coaxed into doing the job, by using a fraction of its capabilities, but it's like doing your grocery shopping with a Formula IV race car. It's not cut out for city driving. (I would suspect that this sort of mismatch between requirements and printers leads to the problems you've heard about with simple ascii text, Wordperfect output, and DVI format.) Of course, if you only buy one printer but you want it to do multiple jobs, you're going to end up with some incompatible requirements, and the machine that "fits" your "needs" is going to embody some bizarre design tradeoffs. The LN03 is a perfect example: it was clearly designed for people who want a laser printer but don't need, and aren't ready, for any of its advantages (except quiet printing, and the LN03 is no star there). The LN03 has 7 or so built-in fonts, all of them monospaced typewriter fonts. I believe that this is because, at the time it came out, DEC had no text formatting software other than RUNOFF. People could therefore hop on the laser printer bandwagon by buying an LN03 but not change any of the ways they were doing things. However, if you want to use an LN03 to do some proportionally-spaced computer typesetting, which really does require laser printing or some other non-impact technology, you have to download the fonts from the host, which adds several hundred blocks of extra output to every job you print. So, to refute your concerns, PostScript is nearly an across-the- board win, as long as you lay it across the right board. It is remarkably good at doing what it is designed to do, which is producing high-quality renditions of all kinds of images (not just simple text) from a relatively high-level description. Steve Summit stevesu@copper.tek.com