Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CUPS queues emulate IPP Everywhere printers: Not all details of the PPD file made available as IPP attributes #4952

Closed
tillkamppeter opened this issue Jan 31, 2017 · 2 comments
Assignees
Labels
wontfix This will not be worked on

Comments

@tillkamppeter
Copy link

The PPD API of CUPS is deprecated, in favor of the fact that CUPS queues emulate IPP Everywhere printers and all printer capabilities and options could be polled via IPP. This was recently discussed on the CUPS mailing list, thread "PPD API: Status, future and alternatives to handle printer-specific options". So I have done some tests and found some problems, not only the one described here but also Issue #4951 and Issue #4950.

I have a CUPS queue for my HP Deskjet Ink Advantage 2645 All-in-one set up with HPLIP with the attached PPD file.

When I treat this CUPS queue as an IPP Everywhere printer and poll its capabilities via IPP with this command (output file attached)

ipptool -tv ipp://till-x1carbon.local:631/printers/printer get-printer-attributes.test > ../cups-queue-hp-clj-cm3530.txt

I get some discrepancies between the options in the PPD file (which the current print dialogs would use) and the options in the IPP record (which a future print dialog would use).

For example the PPD allows setting several print quality levels with different resolutions and the IPP record only tells about a resolution of 300 dpi.

@tillkamppeter
Copy link
Author

IPP get-printer-attributes record of the print queue:
cups-queue-hp-dj-ia-2645-aio.txt

Original PPD file of the queue:
printer1.ppd.txt

@michaelrsweet
Copy link
Collaborator

Understand there is a difference between printer drivers, document formats, and what a printer will support.

Drivers generate printer raster data at various resolutions, however printers consume PWG raster documents at (typically) lower resolutions that are then dithered internally at a higher resolution. So for example a printer that does 1200x600dpi might only accept 300dpi PWG Raster data and internally will dither the 300dpi at 1200x600dpi.

The resolution the printer uses can be controlled by the printer-resolution attribute and/or by the print-quality attribute - the latter is the approach we have chosen to support for CUPS since a) we have no way to convey the printer and document resolution separately and b) exposing 3 print qualities is more user-friendly than exposing 3 print qualities AND N print resolutions.

So while we definitely want to ensure that we expose all of the print qualities supported by the printer, we have no interest in separately exposing all of the printer resolutions that are supported.

@michaelrsweet michaelrsweet added the wontfix This will not be worked on label Feb 1, 2017
@michaelrsweet michaelrsweet self-assigned this Feb 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants