Driver supports raw printing but hasn't set a print file callback.

[dipanshu247k-sys]

I am currently using proprietary Epson printer drivers on Arch Linux. Epson officially provides only RPM and DEB packages, so I converted the DEB package into an Arch-compatible package using DebtAP. The conversion completed successfully, and CUPS is able to detect my printer and send print jobs.
Given that CUPS 3 is expected to deprecate traditional PPD-based drivers in favor of driverless IPP printing, this situation is particularly concerning. My printer does not support IPP, and therefore relies entirely on the proprietary driver stack.

Printer : Epson L3210 Series
Drivers : EPSON L3210 (Seiko Epson Corporation) (en) ( converted using debtap )
Arch Linux 6.18.3-arch1-1
pappl-retrofit : Build from Source
pappl 1.4.10-1
libcupsfilters 2.1.1-2
libppd 2.1.1-1
cups 2:2.4.16-1

[zdohnal]

It is because the pappl-retrofit does not define printing function for raw printing, but specifies output format application/vnd.printer-specific - the printer app has to define the function, or set format to NULL, but since we want to have some raw printing in retrofitting printer apps, we have to define the function.

[tillkamppeter]

@dipanshu247k-sys for this situation pappl-retrofit comes with the Legacy Printer Application, legacy-printer-app. This Printer Application finds driver where they are usually installed for a distro's CUPS 2.x installation, even if CUPS 2.x is not installed, for example on a system using CUPS 3.x, or on a simple SBC server just running Linux with the Legacy Printer Application plus classic drivers to make old printers driverless.

This means that when you switch over to CUPS 3.x, you keep your proprietary printer driver installed where it is. You will now just install the Legacy Printer Application and set up your printer in its web interface (usually http://localhost:8000/). The Printer Application will offer your proprietary Epson driver and most probably even assign it automatically to your printer.

[shawnz]

It's not clear to me from the above -- what's the intended resolution here? I am facing this issue in ghostscript-printer-app since PAPPL version 1.4.10 (see michaelrsweet/pappl#391 (comment)). Are you saying there's some way I can be configuring it differently to avoid this error? Or that I should be using legacy-printer-app instead? As far as I can tell it's not possible to avoid this error when using ghostscript-printer-app

[dipanshu247k-sys]

@zdohnal so it will be fixed in some times will new commits ig
for now almost everything is working i hope it will get fixed before CUPS 3 become mainstream 😀

[dipanshu247k-sys]

@tillkamppeter i am using the same legacy-printer-app and also have my drivers properly installed CUPS 2:2.4.16-1 is able to discover them and use them properly .
But what is wrong actually is it pappl instead of pappl-retrofit ?

[dipanshu247k-sys]

@zdohnal I changed application/vnd.printer-specific to NULL
and i was able to now add my printer to legacy-printer-app
but when i tried printing a test page i got

`I [2026-01-06T16:28:08.588Z] [Client 49] Accepted connection from 'localhost'.
D [2026-01-06T16:28:08.588Z] Saving state/config changes.
I [2026-01-06T16:28:08.588Z] Saving system state to '/var/lib/legacy-printer-app/legacy-printer-app.state'.
E [2026-01-06T16:28:08.629Z] [Job 7] Unable to process job with format 'application/pdf'.
I [2026-01-06T16:28:08.629Z] [Client 48] Closing connection from 'localhost'.
I [2026-01-06T16:28:08.629Z] [Job 7] Aborted, job-impressions-completed=0.
D [2026-01-06T16:28:08.629Z] [Job 7] Device read metrics: 0 requests, 0 bytes, 0 msecs
D [2026-01-06T16:28:08.629Z] [Job 7] Device write metrics: 0 requests, 0 bytes, 0 msecs
I [2026-01-06T16:28:08.637Z] [Client 49] HTTP_STATE_GET http://localhost:8000/style.css HTTP/1.1 (en-US,en;q=0.9)
I [2026-01-06T16:28:08.637Z] [Client 49] Not Modified
I [2026-01-06T16:28:08.637Z] [Client 50] Accepted connection from 'localhost'.
D [2026-01-06T16:28:08.637Z] Saving state/config changes.
I [2026-01-06T16:28:08.637Z] Saving system state to '/var/lib/legacy-printer-app/legacy-printer-app.state'.
I [2026-01-06T16:28:08.639Z] [Client 49] Closing connection from 'localhost'.
I [2026-01-06T16:28:08.640Z] [Client 51] Accepted connection from 'localhost'.
I [2026-01-06T16:28:08.640Z] [Client 50] HTTP_STATE_GET http://localhost:8000/navicon.png HTTP/1.1 (en-US,en;q=0.9)
I [2026-01-06T16:28:08.640Z] [Client 50] Not Modified
I [2026-01-06T16:28:08.640Z] [Client 51] HTTP_STATE_GET http://localhost:8000/epson/icon-md.png HTTP/1.1 (en-US,en;q=0.9)
I [2026-01-06T16:28:08.641Z] [Client 51] Not Modified
I [2026-01-06T16:28:08.642Z] [Client 50] Closing connection from 'localhost'.
I [2026-01-06T16:28:08.644Z] [Client 51] Closing connection from 'localhost'.
I [2026-01-06T16:28:18.661Z] [Client 52] Accepted connection from 'localhost'.
I [2026-01-06T16:28:18.666Z] [Client 52] HTTP_STATE_GET http://localhost:8000/epson/ HTTP/1.1 (en-US,en;q=0.9)
I [2026-01-06T16:28:18.666Z] [Client 52] OK text/html 0
D [2026-01-06T16:28:18.666Z] [Client 52] Using HTTP Accept-Language value 'en-US,en;q=0.9' for localization.
D [2026-01-06T16:28:18.666Z] [Client 52] Using language 'en'.
D [2026-01-06T16:28:18.666Z] [Printer epson] Status callback called.
I [2026-01-06T16:28:18.667Z] Saving system state to '/var/lib/legacy-printer-app/legacy-printer-app.state'.
I [2026-01-06T16:28:18.667Z] [Client 53] Accepted connection from 'localhost'.
I [2026-01-06T16:28:18.667Z] [Client 52] Closing connection from 'localhost'.
I [2026-01-06T16:28:18.687Z] [Client 53] HTTP_STATE_GET http://localhost:8000/style.css HTTP/1.1 (en-US,en;q=0.9)
I [2026-01-06T16:28:18.687Z] [Client 53] Not Modified
I [2026-01-06T16:28:18.687Z] [Client 54] Accepted connection from 'localhost'.
I [2026-01-06T16:28:18.689Z] [Client 53] Closing connection from 'localhost'.
I [2026-01-06T16:28:18.690Z] [Client 55] Accepted connection from 'localhost'.
I [2026-01-06T16:28:18.691Z] [Client 54] HTTP_STATE_GET http://localhost:8000/navicon.png HTTP/1.1 (en-US,en;q=0.9)
I [2026-01-06T16:28:18.691Z] [Client 54] Not Modified
I [2026-01-06T16:28:18.691Z] [Client 55] HTTP_STATE_GET http://localhost:8000/epson/icon-md.png HTTP/1.1 (en-US,en;q=0.9)
I [2026-01-06T16:28:18.691Z] [Client 55] Not Modified
I [2026-01-06T16:28:18.692Z] [Client 54] Closing connection from 'localhost'.
I [2026-01-06T16:28:18.696Z] [Client 55] Closing connection from 'localhost'.
I [2026-01-06T16:28:18.716Z] [Client 56] Accepted connection from 'localhost'.
I [2026-01-06T16:28:18.716Z] [Client 56] HTTP_STATE_GET http://localhost:8000/favicon.png HTTP/1.1 (en-US,en;q=0.9)
I [2026-01-06T16:28:18.716Z] [Client 56] Not Modified
I [2026-01-06T16:28:18.716Z] [Client 56] Closing connection from 'localhost'.

`

so do i have to define vnd.printer-specific on my own ??

[tillkamppeter]

Does the proprietary driver for your Epson printer only provide CUPS filters and PPDs (or files which generate PPDs) or does it also provide CUPS backends?

Could you create a list of all files which get installed when installing the proprietary driver?

PAPPL is a generic library for creating printer applications. It just implements a driverless IPP interface so that the printing system of the OS sees a driverless IPP printer. It does not support PPD files, CUPS filters, CUPS backends, ..., and so it also does not require these and gives the developer liberty to write a printer driver without the restrictions coming from PPD files. Disadvantage is that you cannot simply drop legacy CUPS driver into PAPPL to convert them to the format which CUPS 3.x needs.

pappl-retrofit is an extension for PAPPL, a library which uses PAPPL for the IPP interface, the web interface, ... but it adds functionality to handle PPD files and to call CUPS filters and backends. So with very little C code you write a wrapper for any classic CUPS driver (also proprietary ones, you do not need to recompile the CUPS driver) that turns it into a Printer Application.

ghostscript-printer-app and legacy-printer-app are such wrappers, based on pappl-retrofit. We also call them retrofitting Printer Applications, while LPrint and hp-printer-app use only PAPPL and no PPD files. These we call native Printer Applications.

[shawnz]

at least in my case (can't speak for the OP) the driver that I was testing with uses the USB backend. You can see how I configured it here:

https://github.com/shawnz/homebrew-printing/blob/main/Formula/min12xxw.rb
https://github.com/shawnz/homebrew-printing/blob/main/Formula/ghostscript-printer-app.rb

This approach works fine with PAPPL 1.4.9, but breaks with the error that OP indicated since this new check was added in PAPPL 1.4.10: michaelrsweet/pappl@9a67015#diff-9493c910e845c5e901b170c81a77f48bd8035576b979a9346958d00ea24f500dR1559

i don't understand how it's possible for retrofit printer apps such as legacy-printer-app or ghostscript-printer-app to function with this check in place -- doesn't it make them essentially unusable?

[dipanshu247k-sys]

Ahh I see
I am getting issue in legacy-printer-app
But I think the only solution is building own printer application 🥀 and for a old printer
I think using some lts distros is better instead of learning C from basics
I have source code for my drivers and filters if that help

[tillkamppeter]

What we have to do here is not to set the raw printing callback as NULL.

We either need to create a callback which actually does raw printing, but this leads to garbage being printers if an input file is of unknown format, or we need to create a dummy callback, which when called returns with an error value and so makes the job getting rejected.

[zdohnal]

We either need to create a callback which actually does raw printing, but this leads to garbage being printers if an input file is of unknown format,

I would go with this - it is the same way as raw printing worked so far, and IMO it does not give much pros focusing on functionality which we keep only for retrofitting old behavior.

[Zepmann]

This also affects older Brother printers. Tested with Brother's proprietary driver and with a foomatic PPD file. Both have the same issue.

I understand that this is all work by volunteers (thank you!), so please do not let this question pressure you. Is there an indication of a timeline? How much work is it to add what @tillkamppeter and @zdohnal suggest? It seems to me that this is a necessary requirement to support a large number of legacy printers in the new ecosystem.