[comp.periphs.printers] Strange problems with HP LaserJet IIID and Adobe PostScript cartridge - help?!

jjsc@inf.rl.ac.uk (John Cullen) (05/03/91)

There seem to be a lot of people out there with HP LaserJet IIID printers so
I'm sure *someone* must have seen or heard about the problems we are having!

Firstly a little background:

We have 3 HP LaserJet IIID printers with Adobe PostScript cartridges, connected
to Sun 3 hosts running OS4.1.1.

Now the problems:

(We use the printers in double sided mode all the time)

1. Odd paged documents have one page printed on the back of the banner page.

- we seem to have partially fixed this by modifying the banner.pro routine
  so it does a "showpage" before the banner is printed. However, see below.

2. Sometimes when printing documents (both standard text and using enscript)
   *part* of the *second* page appeared on the back of the banner, with the
   rest being printed partway down the correct page. Similar things happen
   to documents that have embedded form-feed characters too. This seems to
   be a feature of whether the document is odd or even paged.

3. On rare occasions, "bites" seem to be taken out of documents - a nice
   jagged mask seems to be applied at random across a page leaving "holes"
   in the document. The mask is then dumped to the back of the banner page!

I cannot see how/why these problems should occur, however if anyone knows about
them or can offer any solutions, we would be eternally grateful!

Oh, the other problem is with the printer jamming at the slightest opportunity,
usually because a draught moves the page as it's squirted out of the back of
the printer - anyone found any way to make it more robust?

Many thanks in advance if *anyone* is able to offer *any* help at all!!

John
-- 
===============================================================================
John Cullen                     || JANET : jjsc@uk.ac.rl.inf
System Support Group            || ARPA  : jjsc%inf.rl.ac.uk@nsfnet-relay.ac.uk
Informatics Department          || BITNET: jjsc%inf.rl.ac.uk@ukacrl
Rutherford Appleton Laboratory  || UUCP  : {...!mcsun}!ukc!rlinf!jjsc
Chilton, Didcot, Oxon. OX11 0QX || VOICE : +44 (0)235 44 6555 (Direct line)
===============================================================================

edler@jan.ultra.nyu.edu (Jan Edler) (05/09/91)

In article <11172@nfs4.rl.ac.uk> jjsc@inf.rl.ac.uk () writes:
>1. Odd paged documents have one page printed on the back of the banner page.
>
>- we seem to have partially fixed this by modifying the banner.pro routine
>  so it does a "showpage" before the banner is printed. However, see below.

You must be printing pages in reverse order, or at least
you must be printing the banner after the job.  We print them in forward
order, using the top exit (I guess the top exit goes without saying,
given that we're talking about duplex mode).  We also don't
print banners, but I think you can solve your problem by putting

	statusdict begin false setduplexmode end

at the beginning of your banner page stuff (to print the banner in simplex
mode).  If you decided to print the banner first, you would also put

	statusdict begin true setduplexmode end

at the end of the banner stuff (to switch into duplex mode right before
the job itself).

In my experience, switching between simplex and duplex printing seems
to work fine.  Furthermore, it stands to reason that printing in
simplex mode whenever a blank side is required might speed things up as
well, and reduce engine wear (since such a page makes only one pass
through the engine instead of two) but I don't have any real data.  I
was disappointed that the machine doesn't do this optimization
automatically, but we whipped up a filter to automatically insert the
above commands to switch into simplex mode before the final page of a
mildly-conforming document with an odd number of pages.

>2. Sometimes when printing documents (both standard text and using enscript)
>   *part* of the *second* page appeared on the back of the banner, with the
>   rest being printed partway down the correct page. Similar things happen
>   to documents that have embedded form-feed characters too. This seems to
>   be a feature of whether the document is odd or even paged.

We've never had any problems like this.  Have you fully checked out you
expansion memory?  We had problems with non-HP expansion memory that
passed the printer's self-test, but failed to print non-trivial
postscript.  The symptoms were very wierd.  We returned one such board,
and the replacement had similar problems.  This time, we just made sure
all the chips were well seated, and the problems went away.

>3. On rare occasions, "bites" seem to be taken out of documents - a nice
>   jagged mask seems to be applied at random across a page leaving "holes"
>   in the document. The mask is then dumped to the back of the banner page!

Haven't seen this either, but again I'd be suspicious of the memory.
Does it happen on more than one printer?

>Oh, the other problem is with the printer jamming at the slightest opportunity,
>usually because a draught moves the page as it's squirted out of the back of
>the printer - anyone found any way to make it more robust?

We have jamming problems too.  All the jams are alike in the following way:
1) Duplex mode only.
2) One page in the bottom section, with side 2 correctly printed.
3) One page hanging out the back, where it would switch direction.
   only about 1 or 2 inches at the top of this page (side 4) is printed,
   the rest is blank.
4) There is no "real" jam; no pages are crinkled or anything.
5) It happens on average every hundred or two pages.
6) It happens with paper coming from either input tray in either position.
7) Many but not all the jams occur on the first pages of a document.
8) Repeat jams are common.

Is this like what you've been experiencing?  The local on-site
warranty repair person can't find anything wrong, and the HP
technical assistance number people can't explain it.  Has anyone
else seen this?

Jan Edler
edler@nyu.edu
(212) 998-3353