Ghee Teo wrote:
> Hi Norm,
>> lpadmin(1m) and the printmgr(1m) are fairly conservative in their
>> selection of protocol to use when talking to the print server. They
>> assume the lowest common denominator and default to rfc-1179 without
>> extenstions. The result is that you get a very limited set of
>> information (see your example above). If the print server is IPP
>> enabled,
> If the print server is an pre-Solaris 10, ipp is not enabled by
> default,
> Then, it is no way to query using ipp, right?
That's about right, though later s9 updates include some IPP support.
Right now, I am fixing a few LP bugs and back porting all of the Nevada
printing bits to S10. When I am done, S10 will be bug for bug
compatible with Nevada.
> can one assume that attribute of printer-uri-supported has the following
> transport protocol:
>
> lpsched:// - local host only
> lpd:// ipp://
>
> what else does the PAPI server support, smb etc?
It doesn't currently support SMB, but the intention was to be able to
support additional print services and protocols. SMB is one that's on
the wish list.
>> psm-lpsched.so does some very rudimentary PPD parsing right now for
>> papiPrinterQuery(). It only supply a small subset of PPD data. Wendy
>> is working on a more comprehensive set of interfaces and parser for
>> access to PPD data.
>>
> Understood.
>> Making lpadmin(1m)/printmgr(1m) auto-detect if IPP support is available
>> from the print server should be very easy to do at if the print server
>> is accessible at configuration time.
>>
> You lost me here. I am sure I understand what you are trying to
> achieve here.
The idea is to make lpadmin/printmgr generate a printer-uri-supported
entry that uses the best and most functionality means of communicating
with remote print queues. If it's a local lpsched queue, libpapi
actually rewrites the URI to the lpsched:// form when it's retrieved
from the printers.conf DB.
>>
>>> 2. On the local print queue, we typically have
>>> number-up-supported=1
>>> number-up-default=1
>>>
>>> Is this really supported on the server? Playing around with it,
>>> doesn't seems to
>>> be so. But can this be made supported on the PAPI server side?
>>>
>> If I remember correctly, foomatic can use psnup to support n-up. As a
>> result, we can probably actually support more than 1 up. The PAPI
>> lpsched support should determine which number-up-supported values are
>> valid and report that rather than the hard coded 1. We need to file a
>> bug on this.
>>
> what PAPI type does you expect number-up-supported going to be,
> char* or ..?
number-up, number-up-supported, and number-up-default are described in
RFC-2911.
They contain integer values.
>>> 3. In a previous discussion, I was advised that I have to parse the
>>> PPD for
>>> additional information. But it seems if the print queue is on the
>>> local machine,
>>> PAPI already parsed the PPD file and present these information through
>>> the API.
>>> Why do I need to parse the PPD file then?
>>>
>>> If parsing the PPD file is required for the remote queue, there are
>>> potentially 2 problems
>>> - How does one know what is printer model the print queue is?
>>> - What should one do while the print server may have the PPD file but
>>> the local machine
>>> has not that PPD file?
>>>
>> Wendy is working on the interface for this. One of the goals it to make
>> the network as transparent as possible, so effectively, you will be able
>> to ask for the PPD data from the "queue". Under the covers, it will
>> locate the PPD file associated with the queue, transfer it if
>> necessary, and parse it for you. There will probably also be interfaces
>> for you to do this on your own.
>>
> I can base on the protocol above:
>
> lpsched:// then uses the values provided by the PAPI api.
> ipp:// then simply uses the values provided bythe PAPI api
>
> if it is lpd://, I can't tell whether this server supports IPP or not.
> So I simply have to provide the minimum option on the GUI.
> Are these correct assumptions?
That's about right, though when Wendy's interface becomes available, you
will probably want to just call it to get the capabilities. If it can't
open and/or parse the PPD (or other capabilities data), then use some
minimal set of options.
-Norm
