Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!think!nike!ucbcad!ucbvax!apolling.UUCP!geof From: geof@apolling.UUCP (Geof Cooper) Newsgroups: mod.computers.laser-printers Subject: Re: Quick first impressions of Imagen's 3320 (Canon 20ppm engine) Message-ID: <8610141829.AA00033@apolling.imagen.uucp> Date: Tue, 14-Oct-86 14:29:12 EDT Article-I.D.: apolling.8610141829.AA00033 Posted: Tue Oct 14 14:29:12 1986 Date-Received: Thu, 16-Oct-86 02:41:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@DECWRL.DEC.COM Organization: The ARPA Internet Lines: 106 Approved: laser-lovers@washington.arpa Some quick comments on Mabry's well written product overview. > ...version 3.3 of the Imagen software (which wouldn't talk to > our 8/300 (now 2308?)) so we are going to have to live with 2 different > protocols for awhile... Well, 2 different versions of the IMAGEN software. The protocols (TCP-IP, etc) are the same). > ....The machine will take paper up to B4 size but we > didn't get anything but letter size cassettes.... I'm sure you can order the bigger cassettes. We use them here in R&D. > My first impression of the output was that it was distinctly less dense > than what we were getting on the 8/300. The output from our in-house LBP-20 is about the same as our 8/300. The LBP-20 uses a new drum developed by Canon. It is the first laser printer to have that drum, and the drum was the last element of the printer to be debugged. I seem to remember that we found that copy darkened after the drum was "broken in" (a few thousand copies). But complain if it doesn't happen to yours in a month or so (I'm sure SRI will put enough copies through it in that time!), maybe there is some tweaking to be done. Anyway, it is a write-black machine (like the LBP-CX). Try it out on textures to really see this. > I haven't yet gotten a chance to see if the ethernet-dies-in-6-minutes > bug/misfeature is still in version 3.3. It looks like there might be some > change there (but is it just a hack?) so there is hope. The timer is still there. Its function is to make sure that the printer is not "bated" into diminished service by a host that sends data at a very slow rate (or a spooler that gets into a loop not sending data at all). Or maybe (if my memory serves me) you are referring to the misfeature in TOPS-20, Apollo's, some BSD's, etc., that causes a TCP connection to be reset if it is held in zero window for more than a certain amount of time? Tops-20's timer was 5 or 6 minutes. The apollos crap out after about 30 seconds. The printer now plays some tricks to try and get around this problem. Primarily, it forces the window open one byte every 25 seconds (as memory permits -- it can do this for a few hours) to convince such brain-damaged hosts that there is still some point in continuing the connection. Hope this improves things for you. > ....They reduced the size > of the USER, etc lines to just 14pt ... The 14 pt characters <> harder to see. Actually, the reason we changed the size was that the old, larger font was so large it would not fit into the disk buffer area, so it was being re-read from floppy every page. We found that we could dramatically increase the speed of printing of job headers by using a smaller font. In the case of a 20 ppm printer, the delay caused by V2.2 job headers was about 3-4 LBP-20 page times. Needless to say, this changed the complexion of the printer at sites where most jobs contained 1-2 pages + header. V3.3 prints the headers faster. > ... and filled the rest of > the page with such useful info as the "at," "window," "imagespace," etc... I don't know whether you are being sarcastic, but we did find that customers were unable to debug problems with document control language (DCL) options, especially when a spooler or application was putting things into the stream for them. We added all this info to make this kind of debugging easier. > I was a little disappointed to find that when two letter trays were in > with one named "normal" and the other "letterhead", then if the "normal" > ran out of paper, the printer would switch to using the "letterhead" > tray. I hope Imagen will consider that a bug and not a feature.... (We > only have letter-sized trays. The documentation indicates that switch > will happen. I certainly hope that means that it won't happen if the second > tray has legal paper in it.) This is all "soft" -- check your manuals or call application support, there is a way to define what action the printer is to take. The default is to just switch trays when one is empty (this allows continuous printing). It is possible to arrange for a very flexible set of actions, including aborting or holding a job if the desired paper is not installed. > I did see one failure where a connection was left open with no data > transfered (I opened one of the engine's doors just as a connection > opened)..... (Are you listening, Imagen??).... Ooops, sounds like there's at least one bug left in the system. Probably that clever 3.3 TCP coaxed the other side into holding the connection open where 2.2 would have reset it. Sounds like there was a bug in interpretation (did the document have a legal DCL header, by the way?). I'll pass it on. > We were one of the first to have the Imprint-10, then the 8/300, and now the > 3320. Each time we have been pleased with our decision to go with Imagen. Thanks. Hope your 3320 lasts as long as your Imprint-10!! > (P.S. I would like to put my own fonts onto the Imagen system floppy. Call application support. I think that they can help you. - Geof Cooper IMAGEN