Cups 1.3.7 and Sieko SLP450 Label Printers

Tue Jul 5 11:37:14 PDT 2011

> Scott Hallenbeck wrote:
>
> >> > Scott Hallenbeck wrote:
> >> >
> >> > >> Scott Hallenbeck wrote:
> >> > >>
> >> > >> >> Scott Hallenbeck wrote:
> >> > >> >>
> >> > >> >> > I am tasked with the getting these SLP450 label printers
> >> > >> >> > working with CUPS
> >> > >> >> > 1.3.7.  We have 2 other cups servers (v 1.1.22rc1) we are
> >> > >> >> > phasing out, and
> >> > >> >> > they both print to the label printers without any issues.  It
> >> > >> >> > hasn't always been this way, and there was a large amount of
> >> > >> >> > time spent by another technician, who is no longer here,
> >> > >> >> > getting it to work, but unfortunately was never documented.
> >> > >> >> >
> >> > >> >> > The default siislp450.ppd is identical on all the servers, and
> >> > >> >> > the printer specific ppd's are also the same, as well as the
> >> > >> >> > configurations in these printer specific ppd's.
> >> > >> >> >
> >> > >> >> > I have turned on debug2 on all the servers and ran the same job
> >> > >> >> > through all 3 server, originating from the same place and
> >> > >> >> > printing the same thing.
> >> > >> >> >  In the logs, a few lines before I see "Printing page 1, 0%
> >> > >> >> >  complete..."
> >> > >> >> > and so on, I see a similar line on all 3 servers, with the
> >> > >> >> > newest being different.
> >> > >> >> >
> >> > >> >> > Server 1 - running cups 1.1.2rc1
> >> > >> >> > [Job 15] S3: gDotsPerLine 576.000000, cupsHeight 568,
> >> > >> >> > [margInInMM 0 (Negative will be 0)
> >> > >> >> >
> >> > >> >> > Server 2 - running cups 1.1.2rc1
> >> > >> >> > [Job 7273716] S3: gDotsPerLine 576.000000, cupsHeight 568,
> >> > >> >> > [margInInMM 0 (Negative will be 0)
> >> > >> >> >
> >> > >> >> > and server 3, the newest running v 1.3.7:
> >> > >> >> > [Job 520042] S3: gDotsPerLine 576.000000, cupsHeight 3300,
> >> > >> >> > [margInInMM -115 (Negative will be 0)
> >> > >> >> >
> >> > >> >> > This stood out to me as being an obvious deviation.  The first
> >> > >> >> > 2 print the label correctly, while the 3 one just pushes
> >> > >> >> > through an empty label.
> >> > >> >> >
> >> > >> >> > I have attempted to change *LandscapeOrientation in the
> >> > >> >> > specific printer ppd file from Any to Plus90 and Minus90 in
> >> > >> >> > hopes this would help, but seemed to make no difference.
> >> > >> >> >
> >> > >> >> > I even attempted to command line print with options
> >> > >> >> > -o orientation-requested=3 (4,5,6)
> >> > >> >> > to see if this would fix the issue, and still blanks.
> >> > >> >> >
> >> > >> >> > When I do a 'print test page' from the cups GUI it prints a
> >> > >> >> > perfect little test page on the label.
> >> > >> >> >
> >> > >> >> > The labels being sent are in PDF format, and I know the test
> >> > >> >> > page is in a plain text format, so this leads me to believe
> >> > >> >> > there is some sort of filtering missing or something, but I am
> >> > >> >> > really at a loss where to go from here.
> >> > >> >> >
> >> > >> >> > Anyone have any suggestions?
> >> > >> >> >
> >> > >> >> > Thanks!
> >> > >> >> > Scott
> >> > >> >>
> >> > >> >> Please tell how your label printer has been configured with CUPS,
> >> > >> >> and, for a test print, set the log level to debug, do a test
> >> > >> >> print, and post (an URL to) both the PPD used and the portion of
> >> > >> >> the error_log file that contains the messages related to the test
> >> > >> >> job.
> >> > >> >>
> >> > >> >> Helge
> >> > >> >>
> >> > >> >
> >> > >> >
> >> > >> > Unfortunately I was not the one who set this up to start with.  I
> >> > >> > was told that the drivers (which you linked to in your second
> >> > >> > post) were downloaded
> >> > >> > and freshly compiled on the the new cups server.  I do see a
> >> > >> > directory in root home where the file has been extracted and
> >> > >> > appears to have been compiled.
> >> > >> >
> >> > >> > Right now I do not have a record of a cups test page print from
> >> > >> > the to the printer, but I did make files from test page prints
> >> > >> > from our application server that is sending the label both on the
> >> > >> > old (working) server and the new server. Both servers were set to
> >> > >> > debug2 level before capturing them. Old Server that works :
> >> > >> > http://hellandback.net/cups/devlabeltest-02.txt New Server:
> >> > >> > http://hellandback.net/cups/devlabeltest-03.txt
> >> > >> >
> >> > >> > Once one of the developers gets here and sets up the QA machine I
> >> > >> > have been testing with, I can print a cups test print and capture
> >> > >> > that as well, if you would still like to see that.
> >> > >> >
> >> > >> > Thank you for any assistance in this matter.
> >> > >> > Scott
> >> > >>
> >> > >> In your second log file I found some strange messages:
> >> > >> D [27/Jun/2011:14:02:57 -0400] [Job 520042] Updating PageSize to
> >> > >> [271 136]... which seems to be correct, but some messages later:
> >> > >> D [27/Jun/2011:14:02:57 -0400] [Job 520042] Updating PageSize to
> >> > >> [612 792]... which means Ghostsdcript's cups device forgot the
> >> > >> correct page size and reverted to the default letter page size.
> >> > >>
> >> > >> To further trace it down I'd need the repsective PPDs from both
> >> > >> machines.
> >> > >>
> >> > >> Helge
> >> > >>
> >> > >
> >> > > Placed the PPD from the server printing blank labels here:
> >> > > http://hellandback.net/cups/devlabelprinter.ppd
> >> > >
> >> > > and the one that does work from the older server here:
> >> > > http://hellandback.net/cups/devlabelprinter.ppd-02
> >> > >
> >> > > Let me know if you have any issues getting to them.
> >> > > Scott
> >> >
> >> > I suspect the culprit is your pdftops filter, which is, in cups 1.3.7,
> >> > based
> >> > on  xpdf/pdftops 3.00 . That filter tries, on start, to read a
> >> > configuration file named xpdfrc (don't know in what directory it should
> >> > lie, it depends on the buidling options, but probably in /etc or
> >> > /etc/cups). That file should contain the directive
> >> > psPaperSize match
> >> > (the default is letter). This directive forces the generated PostScript
> >> > to retain the page size defined by the (first page) of the PDF file.
> >> >
> >> > If that won't work, you could try one of the following options:
> >> > (1) replace the pdftops filter by the alternate pdftops filter as
> >> > described on the links at www.cups.org
> >> > (2) replace the pstoraster filter by the gstoraster filter as described
> >> > on the links at www.cups.org (you need to adapt your /etc/cups/*.convs
> >> > file accordingly).
> >> >
> >> > Helge
> >> >
> >>
> > Thank you for this response.
> > I could not locate xpdfrc or anything related to that.  However I do no
> > believe xpdf is even installed, and most likely because X is not installed
> > on the server either.
> > I wasn't sure what the alternate pdftops filter was that you were
> > referring to, as all I could find was a wrapper script.  Is that what you
> > meant?
> >
> > I DID replace the pstoraster filter, as I found that and I could easily
> > follow the instructions.  This seems to have corrected the issues with the
> > SLP450 Label printers.  I am hoping it has no negative effect on the other
> > printers we are using, but so far, I do not see it being used a lot.
> >
> > ___< It did fix the issue, the labels print, but the jobs don't clear the
> > job queue, and cups displays "Ghostscript exited with value 1" for the
> > printer after each label prints...  Any suggestions here? ___>
> >
> > Can you send me a link to the "alternate pdftops filter as described on
> > the links at www.cups.org" please?  I am curious if that would resolve and
> > issue I am having with p3005 printers.
> >
> >  Thanks again for your help!
> >
> > Scott
>
> Thanks for the log and the PS file. My e-mail reply has been blocked (why?).
> I'll dig into it.
>
> Helge
>

Emailed you from my gmail account, please feel free to reply there.
Thanks.
Scott