Large cups systems?

[Kurt Pfeifle]

Seth Galitzer wrote:

> OK, now we seem to be getting somewhere.  Thanks to the changes I made
> yesterday, now only jobs are getting stopped without blocking the whole
> queue.
> 
> I had seven jobs stopped overnight, all plain PS files, all most likely
> sent from Windows.  Of those seven, three were in the queue that I had
> tried to use beh on and was stopped this morning.  When I resent them to
> another printer, they all printed fine.

And what happened when sending to the same printer? And what's the
difference between these two printers?

> So that tells me, either I
> didn't use beh correctly or at the very least, I just shouldn't use it.

It shouldn't be needed in most cases any more, now that you can set
an ErrorPolicy in CUPS (which was not the case in CUPS 1.1).

> The other four were on two different queues/printers (two each).  They
> are all pdf files, all generated by Acrobat 8.0. 

And sent to what type of target printer?

(Ah, it may be a "LaserJet 5 M" according to the %%TargetDevice line.)

> Here's a sample PS
> header from one of them:

Try to get hold of the original PDF so you can do some more experiments.

There is an UI option in most Acrobat (Reader) version that lets you
determine the PostScript level it spits out.

You may have more luck if you (your users) set this to Level 2 (or even
Level 1?).

Also, there may be other settings to try: "save printer memory" or
"download asian fonts" or "optimize for portability/speed" or "print
document" or "print document and markups and notes and annotations
other crappy stuff my printing system can't handle" (last one is just
kidding).

Also look for "page scaling", "rotate and resize" and similar settings.

If you can't use a Windows/Acrobat8 workstation and take some time for
testing, you could go to the user and "print to file" with various
settings, and use these files to testprint them from a unix command
line.

> %!PS-Adobe-3.0
> %cupsJobTicket: job-hold-until=no-hold
> %cupsJobTicket: job-sheets=none,none
> %!PS-Adobe-3.0
> %%Title: ProjectCalendar[1].pdf
> %%Creator: PScript5.dll Version 5.2.2
> %%CreationDate: 10/12/2007 14:25:21
> %%For: dag
> %%BoundingBox: (atend)
> %%Pages: (atend)
> %%PageOrder: (atend)
> %%DocumentNeededResources: (atend)
> %%DocumentSuppliedResources: (atend)
> %%DocumentData: Clean7Bit
> %%TargetDevice: (LaserJet 5M) (3010.000) 550

I'm wondering where Acrobat got this info from. Never noticed this
before. Does version 8 now read the driver used (from the PPD), and
puts this into the above line?

Someone in the know here?

(Also, AFAIK, laserJet 5M doesn't support PostScript LanguageLevel
3, only 2. But this may be handled by foomatic-rip, which may be
knowing that from the PPD and attempt to downlevel it when running
its gs commandline.)

> %%LanguageLevel: 3
> %%HiResBoundingBox: 18 23.2942 594 768.7059
> %%CropBox: 18 23.2942 594 768.7059
> %ADO_BeginApplicationHeaderComments
> %%Creator: Adobe Acrobat 8.0
> %%For: foo
> %%LanguageLevel: 3
> %ADO_EndApplicationHeaderComments
> %%DocumentProcessColors: (atend)
> %%DocumentCustomColors: (atend)
> %%EndComments
> %%BeginDefaults
> %ADO_BeginApplicationDefaultsComments
> %%ViewingOrientation: 1 0 0 1
> %ADO_EndApplicationDefaultsComments
> %%ViewingOrientation: 1 0 0 1
> %%EndDefaults
> 
> Looking at the logs, I get errors with KID3 at some point, causing it to
> fail early.  Here's a sample from the log for the above file after all
> three pages get processed:

What would also be of interest is the Ghostscript commandline
used by foomatic-rip. It's in the log, further above...

> D [16/Oct/2007:11:03:10 -0500] [Job 2115] %%[Page: 1]%%
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] GPL Ghostscript 8.54:
> Unrecoverable error, exit code 1
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] renderer return value: 1
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] renderer received signal: 1
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] Process dying with "Possible
> error on renderer command line or PostScript error. Check options.",
> exit stat: 3
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] error: Illegal seek (29)
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] Possible error on renderer
> command line or PostScript error. Check options.
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] tail process done writing data
> to STDOUT
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] KID4 finished
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] End of Embedded document,
> nesting level now: 0
> D [16/Oct/2007:11:03:10 -0500] [Job 2115]
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] Closing renderer
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] KID3 exited with status 3
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] Renderer exit stat: 3
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] Renderer process finished
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] Killing process 17976 (KID3)
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] Process dying with "Error
> closing renderer", exit stat: 3
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] error: Illegal seek (29)
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] Error closing renderer
> D [16/Oct/2007:11:03:10 -0500] [Job 2115] File 0 is complete.
> D [16/Oct/2007:11:04:00 -0500] Unloading job 2115...
> 
> At this point, the first page has been printed, but the last two are
> not, 

If you look at the PDF in Acrobat, do you see any "weird" parts on
it, such as "transparency" areas? Asian or other (to us) foreign
fonts?

> and the job goes into "stopped" status.  Other failed pdf jobs
> exhibit the same behavior: partial printing (seems to be approximately
> half the document) and then KID3 exits with status 3 and kills the process.
> 
> My next test will be to reprint the original document from another
> version of acrobat (or other pdf reader) and see if I get the same
> errors.  I'll keep you posted.

Yes, please.

Don't forget with the print settings in Acrobat's print dialog.

> I feel like we're getting closer to an answer here.  Is it possible
> acrobat is behaving badly?  Should I try a different engine (eg *not*
> hpijs)?

Well, hpijs is officially supported by the HP folks, and the
foomatic-rip path is too (which invokes hpijs), and the PPD
you installed is maintained by them, so....

But yes, you could try to grab the Mac or MS Windows version
of the PS driver's PPD for that model, and simply install that
on CUPS (you'll have to see if the PPD supports all the print
options you need).

> You want me to provide more of the jobfile and error_log?  I can
> pastebin them somewhere.  Just let me know if that would be helpful.

I'd be interested to have short look at it (but won't necessarily
respond with another comment).

Just make sure that you past the snippet for the complete job
(starting with "print_job: auto-typing file...")

> Thanks for your continued help.

I'm just expecting that in return you'll publically retract your open-
ing statement where you said about CUPS "the whole system seems so
flaky that if you sneeze too hard it falls apart", and bow three times
towards Maryland (CUPS' birth place) to make up for your sins...

:-))

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany