[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.