This is a related but distinct issue from #<số_issue_trước_nếu_có>, found while
debugging why Windows 11 could not properly add the shared CUPS printer for
Ricoh SP112 (foo2ddst) over the network, while an alternative PPD
(https://github.com/vaginessa/ricoh-sp112-ppd) worked fine for the same task.
Observation
Comparing printer-device-id via ipptool between the two setups on the
same printer/CUPS server:
Working PPD (vaginessa's RICOH_Aficio_SP_112.ppd, explicit *1284DeviceID):
printer-device-id = MFG:MFPrinter ;MDL:Laser Pro LL;CMD:AUTOMATIC,PJL,GDI_RL;
DES:MFPrinter Laser Pro LL;CLS:PRINTER;VER:v1.03e ;
NS:L507124L8090042;
Foomatic-generated PPD for foo2ddst (Debian package
printer-driver-foo2zjs 20200505dfsg0-3+b1, file
foomatic:.../foo2zjs/Ricoh-SP_112.ppd):
*1284DeviceID: "DRV:Dfoo2ddst,R1,M0,TF;"
The foomatic-generated value is NOT a standards-compliant IEEE 1284 Device
ID (missing MFG:, MDL:, and critically CLS:PRINTER;). It appears to be a
CUPS/foomatic-rip internal fallback format, not a real device
identification string.
Impact
On Windows 11, when adding this printer over the network via the native
IPP/Bonjour discovery flow, Windows' "Microsoft IPP Class Driver" creates
the device but categorizes it as "Unspecified"/"Categories: Unknown"
instead of "Printers"/"Categories: Printer", and the connection hangs at
"Connecting..." indefinitely — the printer never becomes usable from
Windows. No "Print queue" device function is created either.
Fix that resolved it locally
Manually editing the installed PPD to replace the *1284DeviceID line with
a standards-compliant one:
*1284DeviceID: "MFG:Ricoh;MDL:SP 112;CMD:PJL,DDST;CLS:PRINTER;DES:Ricoh Aficio SP 112;"
...then restarting cupsd, removing the stale "Unspecified" device on the
Windows side, and re-adding the printer, resulted in Windows correctly
showing Manufacturer: Ricoh, Model number: SP 112, Categories: Printer,
with a working Print queue device function.
Suggested fix upstream
The foomatic PPD template/generation for foo2ddst-based printers (and
possibly other foo2* drivers) should emit a standards-compliant
*1284DeviceID with at least MFG:, MDL:, and CLS:PRINTER: fields, rather
than falling back to the internal "DRV:D,..." format, since that
fallback format breaks Windows' printer categorization during IPP/Bonjour
network discovery.
Happy to test further or provide more captured IPP attribute dumps if
useful.
This is a related but distinct issue from #<số_issue_trước_nếu_có>, found while
debugging why Windows 11 could not properly add the shared CUPS printer for
Ricoh SP112 (foo2ddst) over the network, while an alternative PPD
(https://github.com/vaginessa/ricoh-sp112-ppd) worked fine for the same task.
Observation
Comparing
printer-device-idvia ipptool between the two setups on thesame printer/CUPS server:
Working PPD (vaginessa's RICOH_Aficio_SP_112.ppd, explicit *1284DeviceID):
printer-device-id = MFG:MFPrinter ;MDL:Laser Pro LL;CMD:AUTOMATIC,PJL,GDI_RL;
DES:MFPrinter Laser Pro LL;CLS:PRINTER;VER:v1.03e ;
NS:L507124L8090042;
Foomatic-generated PPD for foo2ddst (Debian package
printer-driver-foo2zjs 20200505dfsg0-3+b1, file
foomatic:.../foo2zjs/Ricoh-SP_112.ppd):
*1284DeviceID: "DRV:Dfoo2ddst,R1,M0,TF;"
The foomatic-generated value is NOT a standards-compliant IEEE 1284 Device
ID (missing MFG:, MDL:, and critically CLS:PRINTER;). It appears to be a
CUPS/foomatic-rip internal fallback format, not a real device
identification string.
Impact
On Windows 11, when adding this printer over the network via the native
IPP/Bonjour discovery flow, Windows' "Microsoft IPP Class Driver" creates
the device but categorizes it as "Unspecified"/"Categories: Unknown"
instead of "Printers"/"Categories: Printer", and the connection hangs at
"Connecting..." indefinitely — the printer never becomes usable from
Windows. No "Print queue" device function is created either.
Fix that resolved it locally
Manually editing the installed PPD to replace the *1284DeviceID line with
a standards-compliant one:
...then restarting cupsd, removing the stale "Unspecified" device on the
Windows side, and re-adding the printer, resulted in Windows correctly
showing Manufacturer: Ricoh, Model number: SP 112, Categories: Printer,
with a working Print queue device function.
Suggested fix upstream
The foomatic PPD template/generation for foo2ddst-based printers (and
possibly other foo2* drivers) should emit a standards-compliant
*1284DeviceID with at least MFG:, MDL:, and CLS:PRINTER: fields, rather
than falling back to the internal "DRV:D,..." format, since that
fallback format breaks Windows' printer categorization during IPP/Bonjour
network discovery.
Happy to test further or provide more captured IPP attribute dumps if
useful.