#7 query mechanism should include PPD information

[Norm Jacobs]

The printer query mechanism available in the PAPI asks
the print
service for data and blindly sends it back the the
requestor. For the
most part, this is fine, but In the case of the Solaris
LP IPP server
and the CUPS server, PPD files can be associated with
print queues
and the data can be retreived via IPP. The IPP
implementation of
papiPrinterQuery() should make an attempt at retreiving and
digestings any associated PPD data to make it easier
for applications
to find out more about the printers, their queues and
their capabilities.
A comment in some mail that I received from dparsons at
debian dot org
prompted this.

[Drew Parsons]

Logged In: YES
user_id=1232190

For record, my interest in PAPI is to improve the
flexibility of Xprint (see
https://bugs.freedesktop.org/show_bug.cgi?id=411 and
https://bugs.freedesktop.org/show_bug.cgi?id=636\).

At the moment Xprint hard-codes printer resolutions into a
config file, and does not know from the printing system
(without setting an environment variable) which of the
printers is the default.

There's a suggestion we use libcups (the CUPS/IPP API), but
I think it makes sense to use PAPI instead if it's working
and available.