[cups] Re: CUPS classes wrecking printing

Gary Dale <gary-atQw05gpxNcQV5J4pn1zwwC/[email protected]> Sun, 2 Nov 2025 12:31:25 -0500
Newsgroups gmane.comp.printing.cups.general
Message-ID <[email protected]>
On 2023-12-09 17:58, Gary Dale wrote:
> I've running Debian/Bookworm (stable) on an AMD64 system - a laptop. 
> It's a fresh install of Debian from about 6 months back that has been 
> kept up to date.
>
> Each December I am involved in an event that requires me to use 3 
> photo-printers to print a lot of 4x6 photos. It takes 2 or 3 printers 
> to get the throughput so people aren't waiting for their photos.
>
> I've been doing this for a decade using various photo printers. I've 
> always just set up a CUPS "photo" class and added the printers to it. 
> Then I'd use lpr -P photo <name of jpeg photo to print> to send the 
> output to whichever printer was free. I even did it last year using 
> the same laptop and printers and things worked.
>
> This year, because it was a new OS install, I had to connect the 
> printers and install them again. This required the gutenprint drivers 
> for two of the printers while the newest seems to work "driverless".
>
> All the printers were tested individually and printed the CUPS test 
> page perfectly.
>
> However when I sent something to the "photo" class, whichever printer 
> received the job just printed a page of bands of colour. I could send 
> a picture to an individual printer OK but not send it to the "photo" 
> class.
>
> I got through the event by skipping the lpr -P photo... command and 
> manually selecting a printer from Gwenview when I was viewing the 
> picture earlier in the workflow (to verify it was worth printing). 
> This was not ideal and I only got through it because this year's event 
> was less than half its usual size.
>
> This was not an lpr problem because I also couldn't print to the class 
> from Gwenview. CUPS classes seem to be broken.


I'm running Debian 13 (Trixie) on an AMD64 laptop. As I reported 2 years 
ago, CUPS classes aren't working. This has gotten worse since then (I 
didn't do any photo printing to a class last year).

I am attempting the same thing as described above. I have only one 
printer currently in the class - an Epson XP-6100 attached via a USB 
cable. The printing appears to work but nothing ever comes out. This was 
installed as a driverless printer so CUPS should have no trouble with it.

I noted when trying to modify the class that the printer class name is 
not displayed. Instead I get things like a white question mark in a 
black diamond, a greater-than symbol or other characters. I am also 
unable to modify the class - possibly a result of the name being mangled.

In an attempt to fix the problems, I purged my CUPS install on the 
laptop, including "rm -r /etc/cups", rebooted and reinstalled. Rather 
than reinstalling lpr, I figured I'd just go with lp, which supposedly 
has the same functionality (I just had to change the -P option to -d).

Unfortunately, this fixed nothing. The print class still can't be 
modified and I can't send a .jpeg file to the printer nor to the print 
class using lp. The jobs seem to print OK (according to the Jobs list) 
but there is no output.

I can print a test page from the CUPS web interface (localhost:631) for 
the printer. It correctly prints to both letter and 4x6 photo paper. One 
oddity I note is that CUPS insists that its test page is actually 3 
pages in reporting it in the Jobs list.

I can also print a photo from Gwenview to the printer but not to the 
class. When I print to the class, the job shows up as pending and just 
sits in the queue until I cancel it.

So, classes seem to be totally broken at this point. Lp doesn't seem to 
working on my laptop for printing jpeg files but is working on my 
(headless) server for printing PDFs.

I don't take pleasure in criticizing developers but WTF are they doing? 
In 2019 everything was working great. After things restarted after the 
pandemic, CUPS has been getting worse.

Why are classes broken? Even if you are going to driverless printing, 
each printer still has its own non-driver. This should not have impacted 
classes at all. The output file should still be sent the same way to the 
next available printer.

Similarly, why is lp broken? If I can print from a gui application, why 
doesn't printing from the command line also work?

CUPS classes used to be one of the best things about Linux that Windows 
couldn't match. Now with lp also broken, I can't even write a 
print-to-class function to manually emulate classes by waiting for an 
available printer from a list.