Network printer: remote jobs hang,print if requeued locally

Frnak McKenney frank_mckenney at
Sat Jun 23 06:29:30 PDT 2007


Thank you for joining in.

>I didn't have time to follow this threat in detail.

Ah! A man with respect for his eyesight. <grin!>

>However, one question:  could it be....
>....that the original job is passing CUPS unfiltered (your Windows
>client + Samba server + CUPS setup makes the job print as "raw"),
>which format is not what your print device is able to consume?

I know I _intend_ to send Postscript to CUPS, since (a) that's what
worked before and (b) that's my understanding of what the Brother
PPD file from

is expecting.  Here's part of the header from the PPD file:

*PCFileName: "MFC420CN.PPD"
*Manufacturer: "Brother"
*Product: "(MFC-420CN)"
*1284DeviceID: "MFG:Brother;MDL:MFC-420CN"
*cupsVersion: 1.1
*cupsManualCopies: False
*cupsFilter: "application/vnd.cups-postscript 0 brlpdwrapperMFC420CN"
*cupsModelNumber: 6
*ModelName: "Brother MFC-420CN"
*ShortNickName: "Brother MFC-420CN"
*NickName: "Brother MFC-420CN CUPS v1.1"
*PSVersion: "(3010.106) 3"

(I just noticed its "cupsVersion" is 1.1.  Could that be relevant?)

The spool data file (e.g.  d00082-001) created by the original
sumbission from 'office' _looks_ like good Postscript, at least to
the untutored eye.  It even ends with

  %%+ font Courier Bold

I've tried enabling the driver option to append a *NIX EOF (ctl-D
a.k.a ^D), but this doesn't seem to make a difference.

Or am I responding to the wrong question?  Is there something in the
spool control file (e.g.  c00082) that affects how the data file is
processed _after_ the data has been received?  If so, is there a way
of displaying this intelligibly (e.g.  other than in raw hex)?

If it's relevant, here's the relevant section of my printers.conf

  <DefaultPrinter mfc420cn>
  Info Brother MFC-420CN Printer / Scanner / FAX
  Location Computer Lab
  DeviceURI socket://brn_60fb75:9100/
  State Idle
  StateTime 1182472928
  Accepting Yes
  Shared Yes
  JobSheets none none
  QuotaPeriod 0
  PageLimit 0
  KLimit 0
  OpPolicy default
  ErrorPolicy stop-printer

>....that your 2nd shoot, where you submit the spool file from the
>CUPS server triggers the CUPS "auto-typing" function for jobs and
>that leads to the correct filtering chain applied?

Certainly a possibility, in this "best of all possible worlds".  In
fact, "Murphy" practically guarantees it.  <grin!>

>I'd advice you to monitor your error_log for the filters that get
>applied by CUPS for each job.  Also, you may be able to open the
>first job (the spool file) in an editor and look at the PostScript

Where would I look to figure out how my installed copy of CUPS was
making its "type" decision?

>You could use my primitive "2file" CUPS backend which I posted here
>some days ago
>  (
>to setup another queue with the same PPD, but which "prints to
>file", and then use "sdiff -sbB" to compare the files for
>significant differences.

Thanks for the pointer.

I _suppose_ I could even do a diff to compare the two spool data
files, couldn't I?  (loud THWACK as hand hits forehead)

I have to go shortly, but I'll take a look at your backend later on
today. Thanks again for the help.

    Experience is a hard teacher because she gives the test first,
    the lesson afterward.    -- Vernon Law, baseball pitcher
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut minds pring dawt cahm (y'all)

More information about the cups mailing list