Foomatic-generated PPD for foo2ddst printers lacks proper *1284DeviceID, causing Windows IPP Class Driver to misclassify printer as "Unspecified" device

Open
#28 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c

Research direction

Start by tracing how the foomatic template generates the foo2ddst PPD, using the generated foo2zjs/Ricoh-SP_112.ppd and its *1284DeviceID line as the reference. Compare the output with the standards-compliant example, then use ipptool to verify the resulting printer-device-id includes MFG:, MDL:, and CLS:PRINTER: fields.

Written by the indexing model from the issue text.

Description

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.

Dominant language
C
Stars
8
Forks
5
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenPrinting/foo2zjs

All issues in OpenPrinting/foo2zjs

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.