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? 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? > 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. > >> 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 ..? >> 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? -Ghee > -Norm > >
