Cups 1.3.7 and Sieko SLP450 Label Printers

Tue Jul 5 09:25:50 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.
> 
> 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

Here is the link to the alternate pdftops filter:
http://www.srz.de/Members/bla/cups/filter/pdftops
The documentation I have is in German only, but if you read the comment
lines in the script you'll get to know all relevant information.

As for the pdftops filter of your cups configuration, if it is the original design and 
not a substitute by your system provider, it is a slightly modified version of the
pdftops utility which is part of the xpdf suite (and runs without a running X server,
of course). As I read from the source (at svn.eaqsysw.com), it has the same
default of letter for the page size if not specified otherwise, and it looks for
a file named xpdfrc in the user's home directory (the user the filter is running as)
or /etc, in that order. So it should be sufficient to set up a file 
/etc/xpdfrc with just the directive I mentioned as the only content to retain
the page size of the originating PDF. But note that this only works if the PDF
does not have pages of different sizes.

Drop me a notice if you want to get the german documentation.

Helge