* [Printing-architecture] Building PAPI implementation @ 2006-05-17 13:28 Till Kamppeter 2006-05-17 14:32 ` [Printing-architecture] " Norm Jacobs 0 siblings, 1 reply; 11+ messages in thread From: Till Kamppeter @ 2006-05-17 13:28 UTC (permalink / raw) To: Norm Jacobs; +Cc: printing-architecture, desktop_printing@osdl.org Now I am trying to build the PAPI package from http://openprinting.sourceforge.net/ I am building the current Subversion state, rev 164. There I have encountered some problems: - At first I needed to patch the build infrastructure a little bit to make it compiling the Apache support. The patch on the acinclude.m4 file you can find here: http://www.linuxprinting.org/till/tmp/papi-1.0-acinclude-m4-apache-apr1.patch - Then I had a problem building the software, as source/mod_ipp/mod_ipp.c includes the file apr_compat.h in case of building with Apache support. According to http://www.apache.org/dist/apr/CHANGES-APR-1.2 this header file was removed on the transition from APR 0.9.5 to 1.0.0 and I have 1.2.7 on Mandriva's Cooker. So here the Apache module needs to be updated to the current Apache/APR API. Till ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Printing-architecture] Re: Building PAPI implementation 2006-05-17 13:28 [Printing-architecture] Building PAPI implementation Till Kamppeter @ 2006-05-17 14:32 ` Norm Jacobs 2006-05-17 21:03 ` Till Kamppeter 0 siblings, 1 reply; 11+ messages in thread From: Norm Jacobs @ 2006-05-17 14:32 UTC (permalink / raw) To: Till Kamppeter; +Cc: printing-architecture, desktop_printing@osdl.org The Apache support is only necessary if you want to supply IPP support for a print service that doesn't already have an IPP listener. We use it on Solaris, but if you are using CUPS, you don't need the listener. That being said, I will be fixing it in the next few days when I fix it's Apache 2.X support. In the meantime, you can configure --without-apache and it should avoid building the IPP listener module (mod_ipp.so). Thanks for the heads-up and the patch to the build infrastructure. -Norm Till Kamppeter wrote: > Now I am trying to build the PAPI package from > http://openprinting.sourceforge.net/ I am building the current > Subversion state, rev 164. > > There I have encountered some problems: > > - At first I needed to patch the build infrastructure a little bit to > make it compiling the Apache support. The patch on the acinclude.m4 file > you can find here: > > http://www.linuxprinting.org/till/tmp/papi-1.0-acinclude-m4-apache-apr1.patch > > - Then I had a problem building the software, as > source/mod_ipp/mod_ipp.c includes the file apr_compat.h in case of > building with Apache support. According to > > http://www.apache.org/dist/apr/CHANGES-APR-1.2 > > this header file was removed on the transition from APR 0.9.5 to 1.0.0 > and I have 1.2.7 on Mandriva's Cooker. So here the Apache module needs > to be updated to the current Apache/APR API. > > Till > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-17 14:32 ` [Printing-architecture] " Norm Jacobs @ 2006-05-17 21:03 ` Till Kamppeter 2006-05-18 9:48 ` [Desktop_printing] " Till Kamppeter 0 siblings, 1 reply; 11+ messages in thread From: Till Kamppeter @ 2006-05-17 21:03 UTC (permalink / raw) To: Norm Jacobs; +Cc: printing-architecture, desktop_printing@osdl.org Now I got it RPMized so that it can be installed on a machine with already installed CUPS. No I tried to make it actually working with the installed CUPS. I found out by running an "lpr" command through strace that it tries to load the non-existing "lpsched" service (/usr/lib/psm-lpsched.so) and I have seen in the source code that "lpsched" is used a s the default service (should not be as "lpsched" does not ship with the package. So I compile with export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=ipp" ./configure --without-apache --without-ruby make to make it using "ipp" as default service (can one configure/switch the service at run time? There are no files in /etc/... and no documentation about such files, man pages are only in section 1 and 8, nothing in section 5). But with this setting it does not build: ------------------------------------------------------------------------------------ [...] Making all in libpapi-dynamic make[2]: Entering directory `/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic' if /bin/sh ../../libtool --tag=CC --mode=compile i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 -DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF ".deps/psm.Tpo" -c -o psm.lo psm.c; \ then mv -f ".deps/psm.Tpo" ".deps/psm.Plo"; else rm -f ".deps/psm.Tpo"; exit 1; fi mkdir .libs i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 -DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF .deps/psm.Tpo -c psm.c -fPIC -DPIC -o .libs/psm.o if /bin/sh ../../libtool --tag=CC --mode=compile i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 -DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF ".deps/service.Tpo" -c -o service.lo service.c; \ then mv -f ".deps/service.Tpo" ".deps/service.Plo"; else rm -f ".deps/service.Tpo"; exit 1; fi i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 -DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF .deps/service.Tpo -c service.c -fPIC -DPIC -o .libs/service.o service.c: In function 'service_load': service.c:60: error: 'ipp' undeclared (first use in this function) service.c:60: error: (Each undeclared identifier is reported only once service.c:60: error: for each function it appears in.) ICECREAM[19319]: Compiled on 192.168.2.67 make[2]: *** [service.lo] Error 1 make[2]: Leaving directory `/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tkamppeter/rpm/BUILD/papi/source' make: *** [all-recursive] Error 1 ------------------------------------------------------------------------------------ Can you tell me how to get it correctly talking with CUPS? Thanks. Till Norm Jacobs wrote: > > The Apache support is only necessary if you want to supply IPP > support for a print service that doesn't already have an IPP listener. > We use it on Solaris, but if you are using CUPS, you don't need the > listener. That being said, I will be fixing it in the next few days when > I fix it's Apache 2.X support. In the meantime, you can configure > --without-apache and it should avoid building the IPP listener > module (mod_ipp.so). > Thanks for the heads-up and the patch to the build infrastructure. > > -Norm > > Till Kamppeter wrote: > >> Now I am trying to build the PAPI package from >> http://openprinting.sourceforge.net/ I am building the current >> Subversion state, rev 164. >> >> There I have encountered some problems: >> >> - At first I needed to patch the build infrastructure a little bit to >> make it compiling the Apache support. The patch on the acinclude.m4 file >> you can find here: >> >> http://www.linuxprinting.org/till/tmp/papi-1.0-acinclude-m4-apache-apr1.patch >> >> >> - Then I had a problem building the software, as >> source/mod_ipp/mod_ipp.c includes the file apr_compat.h in case of >> building with Apache support. According to >> >> http://www.apache.org/dist/apr/CHANGES-APR-1.2 >> >> this header file was removed on the transition from APR 0.9.5 to 1.0.0 >> and I have 1.2.7 on Mandriva's Cooker. So here the Apache module needs >> to be updated to the current Apache/APR API. >> >> Till >> > > > _______________________________________________ > Printing-architecture mailing list > Printing-architecture@lists.freestandards.org > http://lists.freestandards.org/cgi-bin/mailman/listinfo/printing-architecture > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-17 21:03 ` Till Kamppeter @ 2006-05-18 9:48 ` Till Kamppeter 2006-05-18 15:29 ` Till Kamppeter 0 siblings, 1 reply; 11+ messages in thread From: Till Kamppeter @ 2006-05-18 9:48 UTC (permalink / raw) To: Norm Jacobs; +Cc: printing-architecture, desktop_printing@osdl.org Now I got it working with CUPS by changing the default print service at compile time. The problem was the quoting. The current code ----------------------------------------------------------------------- #ifndef DEFAULT_PRINT_SERVICE #define DEFAULT_PRINT_SERVICE "lpsched" #endif ... char *scheme = DEFAULT_PRINT_SERVICE; ----------------------------------------------------------------------- requires from the user to supply also the quotes. So in the spec file I had to do ----------------------------------------------------------------------- export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=\\\"ipp\\\"" %configure --without-apache %make ----------------------------------------------------------------------- Note the quoted quotes in the first line. This I did not do in the first place and therefore it broke. But please still supply the documentation to configure PAPI at run time. Also a possibility to define the compile time default by the configure script, both by spooler auto discovery and also by command line option would be great. Note also that on the linker call(s) for the Ruby bindings the -L$RPM_BUILD_DIR/papi/source/libpapi-dynamic/.libs is missing. So I had to put ----------------------------------------------------------------------- export LDFLAGS="$LDFLAGS -L$RPM_BUILD_DIR/papi/source/libpapi-dynamic/.libs" ----------------------------------------------------------------------- before the "%configure" in the spec file. Till Till Kamppeter wrote: > Now I got it RPMized so that it can be installed on a machine with > already installed CUPS. No I tried to make it actually working with the > installed CUPS. I found out by running an "lpr" command through strace > that it tries to load the non-existing "lpsched" service > (/usr/lib/psm-lpsched.so) and I have seen in the source code that > "lpsched" is used a s the default service (should not be as "lpsched" > does not ship with the package. > > So I compile with > > export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=ipp" > ./configure --without-apache --without-ruby > make > > to make it using "ipp" as default service (can one configure/switch the > service at run time? There are no files in /etc/... and no documentation > about such files, man pages are only in section 1 and 8, nothing in > section 5). > > But with this setting it does not build: > > ------------------------------------------------------------------------------------ > [...] > Making all in libpapi-dynamic > make[2]: Entering directory > `/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic' > if /bin/sh ../../libtool --tag=CC --mode=compile > i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. > -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" > -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 > -DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF ".deps/psm.Tpo" -c -o > psm.lo psm.c; \ > then mv -f ".deps/psm.Tpo" ".deps/psm.Plo"; else rm -f ".deps/psm.Tpo"; > exit 1; fi > mkdir .libs > i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. > -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" > -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 > -DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF .deps/psm.Tpo -c > psm.c -fPIC -DPIC -o .libs/psm.o > if /bin/sh ../../libtool --tag=CC --mode=compile > i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. > -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" > -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 > -DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF > ".deps/service.Tpo" -c -o service.lo service.c; \ > then mv -f ".deps/service.Tpo" ".deps/service.Plo"; else rm -f > ".deps/service.Tpo"; exit 1; fi > i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. > -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" > -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 > -DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF .deps/service.Tpo > -c service.c -fPIC -DPIC -o .libs/service.o > service.c: In function 'service_load': > service.c:60: error: 'ipp' undeclared (first use in this function) > service.c:60: error: (Each undeclared identifier is reported only once > service.c:60: error: for each function it appears in.) > ICECREAM[19319]: Compiled on 192.168.2.67 > make[2]: *** [service.lo] Error 1 > make[2]: Leaving directory > `/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/tkamppeter/rpm/BUILD/papi/source' > make: *** [all-recursive] Error 1 > ------------------------------------------------------------------------------------ > > Can you tell me how to get it correctly talking with CUPS? Thanks. > > Till > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-18 9:48 ` [Desktop_printing] " Till Kamppeter @ 2006-05-18 15:29 ` Till Kamppeter 2006-05-18 19:02 ` Norm Jacobs 0 siblings, 1 reply; 11+ messages in thread From: Till Kamppeter @ 2006-05-18 15:29 UTC (permalink / raw) To: Norm Jacobs; +Cc: printing-architecture, desktop_printing@osdl.org I have probably found bugs in the PAPI library: I have CUPS 1.2.0 installed and the PAPI library. I have several local CUPS queues, one for an HP PhotoSmart 2600 using the HPIJS driver. With this driver I have the PPD options "PageSize", "PrintoutMode", "Quality", "InputSlot", and "Duplex". See http://www.linuxprinting.org/ppd-o-matic.cgi?driver=hpijs&printer=HP-PhotoSmart_2600&show=1 for the PPD file. I can print on this printer using the PAPI "lpr " command and the printer is correctly shown with the PAPI "lpstat -p" and "lpstat -v". Now I run printer-query -d HPPSmart2600 from the sample programs. According to its source code it is supposed to show all attributes of the printer when the command is called without the "-o" option (otherwise it wouls show only the specified attribute). What I get is -------------------------------------------------------------------------- [root@majax c]# printer-query -d HPPSmart2600 HPPSmart2600 at (default): printer-name=HPPSmart2600,HP Photosmart 2600 rm=majax.mandrakesoft.com rp=HPPSmart2600 [root@majax c]# -------------------------------------------------------------------------- There came out only three attributes, "printer-name", "rp", and "rm". What I expect is (according to section 9 of the specs) attributes for each PPD option, and also some more attributes, like whether I have a color printer, which operations are supported and whatever the specs tell about required printer attributes. And if I take the name of one of the required attributes, as for example "operations-supported", I get the very same output as without supplying an attribute name: -------------------------------------------------------------------------- [root@majax c]# printer-query -d HPPSmart2600 -ooperations-supported HPPSmart2600 at (default): printer-name=HPPSmart2600,HP Photosmart 2600 rm=majax.mandrakesoft.com rp=HPPSmart2600 [root@majax c]# -------------------------------------------------------------------------- It seems that the query function -------------------------------------------------------------------------- status = papiPrinterQuery(svc, destination, requested, NULL, &printer); -------------------------------------------------------------------------- is not taking care of what is in "requested". Without "-o" option "requested" should be NULL and therefore all attributes should be returned in "printer", if "-o" is used "requested" should contain the argument of "-o" and therefore only this attribute should be shown (of an error if the attribute does not exist). See section 6 of the specs. The query (and the use) of the capabilities )section 9) of a CUPS queue (independent whether it is local or remote) is essential (all Linux systems use CUPS by default), as the user expects to be able to control duplex, finisher, quality, paper size, ... and so an ISV should be able to get these options into the printing dialog. If this is not possible, the current PAPI is not fully usable and cannot be suggested as a standard, as an ISV has to interface to CUPS (or to KDE) on Linux machines and to the OS-manufacturer-specific printing system on Sun machines (and so make two dialogs, which we want to avoid with proposing PAPI as a standard). Till Till Kamppeter wrote: > Now I got it working with CUPS by changing the default print service at > compile time. The problem was the quoting. The current code > > ----------------------------------------------------------------------- > #ifndef DEFAULT_PRINT_SERVICE > #define DEFAULT_PRINT_SERVICE "lpsched" > #endif > > ... > > char *scheme = DEFAULT_PRINT_SERVICE; > ----------------------------------------------------------------------- > > requires from the user to supply also the quotes. So in the spec file I > had to do > > ----------------------------------------------------------------------- > export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=\\\"ipp\\\"" > %configure --without-apache > %make > ----------------------------------------------------------------------- > > Note the quoted quotes in the first line. This I did not do in the first > place and therefore it broke. > > But please still supply the documentation to configure PAPI at run time. > Also a possibility to define the compile time default by the configure > script, both by spooler auto discovery and also by command line option > would be great. > > Note also that on the linker call(s) for the Ruby bindings the > > -L$RPM_BUILD_DIR/papi/source/libpapi-dynamic/.libs > > is missing. So I had to put > > ----------------------------------------------------------------------- > export LDFLAGS="$LDFLAGS -L$RPM_BUILD_DIR/papi/source/libpapi-dynamic/.libs" > ----------------------------------------------------------------------- > > before the "%configure" in the spec file. > > Till > > > > Till Kamppeter wrote: > >>Now I got it RPMized so that it can be installed on a machine with >>already installed CUPS. No I tried to make it actually working with the >>installed CUPS. I found out by running an "lpr" command through strace >>that it tries to load the non-existing "lpsched" service >>(/usr/lib/psm-lpsched.so) and I have seen in the source code that >>"lpsched" is used a s the default service (should not be as "lpsched" >>does not ship with the package. >> >>So I compile with >> >>export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=ipp" >>./configure --without-apache --without-ruby >>make >> >>to make it using "ipp" as default service (can one configure/switch the >>service at run time? There are no files in /etc/... and no documentation >>about such files, man pages are only in section 1 and 8, nothing in >>section 5). >> >>But with this setting it does not build: >> >>------------------------------------------------------------------------------------ >>[...] >>Making all in libpapi-dynamic >>make[2]: Entering directory >>`/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic' >>if /bin/sh ../../libtool --tag=CC --mode=compile >>i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. >>-I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" >>-I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 >>-DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF ".deps/psm.Tpo" -c -o >>psm.lo psm.c; \ >>then mv -f ".deps/psm.Tpo" ".deps/psm.Plo"; else rm -f ".deps/psm.Tpo"; >>exit 1; fi >>mkdir .libs >> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. >>-I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" >>-I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 >>-DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF .deps/psm.Tpo -c >>psm.c -fPIC -DPIC -o .libs/psm.o >>if /bin/sh ../../libtool --tag=CC --mode=compile >>i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. >>-I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" >>-I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 >>-DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF >>".deps/service.Tpo" -c -o service.lo service.c; \ >>then mv -f ".deps/service.Tpo" ".deps/service.Plo"; else rm -f >>".deps/service.Tpo"; exit 1; fi >> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. >>-I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" >>-I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 >>-DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF .deps/service.Tpo >>-c service.c -fPIC -DPIC -o .libs/service.o >>service.c: In function 'service_load': >>service.c:60: error: 'ipp' undeclared (first use in this function) >>service.c:60: error: (Each undeclared identifier is reported only once >>service.c:60: error: for each function it appears in.) >>ICECREAM[19319]: Compiled on 192.168.2.67 >>make[2]: *** [service.lo] Error 1 >>make[2]: Leaving directory >>`/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/home/tkamppeter/rpm/BUILD/papi/source' >>make: *** [all-recursive] Error 1 >>------------------------------------------------------------------------------------ >> >>Can you tell me how to get it correctly talking with CUPS? Thanks. >> >> Till >> > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-18 15:29 ` Till Kamppeter @ 2006-05-18 19:02 ` Norm Jacobs 2006-05-18 21:24 ` Till Kamppeter 0 siblings, 1 reply; 11+ messages in thread From: Norm Jacobs @ 2006-05-18 19:02 UTC (permalink / raw) To: Till Kamppeter; +Cc: printing-architecture, desktop_printing@osdl.org The SourceForge openprinting project PAPI implementation actually contains multiple implementations of the PAPI, but the one that you link with and interact with directly uses a "printer-uri-supported" value in your name service/configuration data to contact the print service for a particular print queue. If there isn't a printer-uri-supported in the configuration data, it doesn't know how to contact the print service and will only return the name service/configuration data from a query. This data is retrieved on Solaris using the name service switch and can be stored in ${HOME}/.printers, /etc/printers.conf, NIS priners.conf.byname, NIS+ printers.org_dir, and/or LDAP. On other platforms, the NSS support is emulated and can be stored in /etc/printers.conf, /etc/printcap , and NIS printers.conf.byname. If you add a "printer-uri-supported=ipp\://majax.mandrakesoft.com/printers/HPPSmart2600" to the /etc/printers.conf or /etc/printcap entry for your printer, It's likely that you will see the results that you are looking for. The PAPI implementation should probably be modified to use the "rm" and "rp" information in abscense of a "printer-uri-supported" value. This would be similiar to what is being done for "bsdaddr" (see papi/source/libpapi-dynamic/nss.c:fill_printer_uri_supported) Additionally, the cupsd code that generates /etc/printcap and /etc/printers.conf entries (cups/scheduler/printers.c:cupsWritePrintcap()) could be enhanced to include the printer-uri-supported key/value data in it's output. Finally, if you only plan on targeting a particular print service, you can probably get away with removing libpapi.so and replacing it with a symlink to psm-{svc}.so. -Norm PS There are descriptions of the various bits in subversion under papi/docs/README.*. This is a short description of the PAPI implementations in the PAPI code base. I'll oversimplify this a little, but the PAPI implementation on SourceForge contains multiple implementations of the PAPI (all exporting the PAPI interface). source/libpapi-dynamic (builds and installs as libpapi.so) This implements something roughly analogous to the name service switch. It is effectively interposed between the applications and the "real" PAPI print service support. It resolves queue names using a nameservice (/etc/printers.conf, /etc/printcap, NIS printers.conf.byname). On Solaris this also includes $HOME/.printers, NIS+ printers.org_dir, and LDAP. It uses the "printer-uri-supported" information from these nameservices to load backend PAPI print service support and contact the real print service for the requested operation. The printer query operations (papiPrintersList and papiPrintersQuery) support in this library is "special" (and I don't necessarily mean that in a good way), It may not contact the actual print service if the name service contained the requested data. source/libpapi-lpd (builds and installs as psm-lpd.so and lpd-port) This implements support for contacting RFC-1179 based print services. Because of the limitted nature and wide variety of RFC-1179 support, the PAPI support is very limitted. The following printer/job operations do something useful: papiPrinterQuery, papiPrinterPurgeJobs, papiPrinterListJobs, papiJobSubmit, papiJobSubmitByReference, papiJobStreamOpen/Write/Close, papiJobQuery, papiJobCancel Because RFC-1179 returns very little information, the query functions return a very basic skeleton of information. They could be made to provide information from an associated PPD file, but there are other areas where the time might be better spent. lpd-port provides a means of isolating parts of rfc-1179 support that require elevated privilege from that application. libpapi-ipp (builds and installs as psm-ipp.so) This implements support for contacting IPP based print services. IPP provides a a framework and rich set of operations and attributes for printing. As a result, the PAPI support on top of IPP is complete. It makes use of standard IPP operations and attributes for the vast majority of the implementation with CUPS extensions being used where there was no standard means. Till Kamppeter wrote: > I have probably found bugs in the PAPI library: > > I have CUPS 1.2.0 installed and the PAPI library. I have several local > CUPS queues, one for an HP PhotoSmart 2600 using the HPIJS driver. With > this driver I have the PPD options "PageSize", "PrintoutMode", > "Quality", "InputSlot", and "Duplex". See > > http://www.linuxprinting.org/ppd-o-matic.cgi?driver=hpijs&printer=HP-PhotoSmart_2600&show=1 > > for the PPD file. I can print on this printer using the PAPI "lpr " > command and the printer is correctly shown with the PAPI "lpstat -p" and > "lpstat -v". > > Now I run > > printer-query -d HPPSmart2600 > > from the sample programs. According to its source code it is supposed to > show all attributes of the printer when the command is called without > the "-o" option (otherwise it wouls show only the specified attribute). > > What I get is > > -------------------------------------------------------------------------- > [root@majax c]# printer-query -d HPPSmart2600 > HPPSmart2600 at (default): > printer-name=HPPSmart2600,HP Photosmart 2600 > rm=majax.mandrakesoft.com > rp=HPPSmart2600 > [root@majax c]# > -------------------------------------------------------------------------- > > There came out only three attributes, "printer-name", "rp", and "rm". > What I expect is (according to section 9 of the specs) attributes for > each PPD option, and also some more attributes, like whether I have a > color printer, which operations are supported and whatever the specs > tell about required printer attributes. > > And if I take the name of one of the required attributes, as for example > "operations-supported", I get the very same output as without supplying > an attribute name: > > -------------------------------------------------------------------------- > [root@majax c]# printer-query -d HPPSmart2600 -ooperations-supported > HPPSmart2600 at (default): > printer-name=HPPSmart2600,HP Photosmart 2600 > rm=majax.mandrakesoft.com > rp=HPPSmart2600 > [root@majax c]# > -------------------------------------------------------------------------- > > It seems that the query function > > -------------------------------------------------------------------------- > status = papiPrinterQuery(svc, destination, requested, NULL, &printer); > -------------------------------------------------------------------------- > > is not taking care of what is in "requested". Without "-o" option > "requested" should be NULL and therefore all attributes should be > returned in "printer", if "-o" is used "requested" should contain the > argument of "-o" and therefore only this attribute should be shown (of > an error if the attribute does not exist). See section 6 of the specs. > > The query (and the use) of the capabilities )section 9) of a CUPS queue > (independent whether it is local or remote) is essential (all Linux > systems use CUPS by default), as the user expects to be able to control > duplex, finisher, quality, paper size, ... and so an ISV should be able > to get these options into the printing dialog. If this is not possible, > the current PAPI is not fully usable and cannot be suggested as a > standard, as an ISV has to interface to CUPS (or to KDE) on Linux > machines and to the OS-manufacturer-specific printing system on Sun > machines (and so make two dialogs, which we want to avoid with proposing > PAPI as a standard). > > Till > > Till Kamppeter wrote: > >> Now I got it working with CUPS by changing the default print service at >> compile time. The problem was the quoting. The current code >> >> ----------------------------------------------------------------------- >> #ifndef DEFAULT_PRINT_SERVICE >> #define DEFAULT_PRINT_SERVICE "lpsched" >> #endif >> >> ... >> >> char *scheme = DEFAULT_PRINT_SERVICE; >> ----------------------------------------------------------------------- >> >> requires from the user to supply also the quotes. So in the spec file I >> had to do >> >> ----------------------------------------------------------------------- >> export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=\\\"ipp\\\"" >> %configure --without-apache >> %make >> ----------------------------------------------------------------------- >> >> Note the quoted quotes in the first line. This I did not do in the first >> place and therefore it broke. >> >> But please still supply the documentation to configure PAPI at run time. >> Also a possibility to define the compile time default by the configure >> script, both by spooler auto discovery and also by command line option >> would be great. >> >> Note also that on the linker call(s) for the Ruby bindings the >> >> -L$RPM_BUILD_DIR/papi/source/libpapi-dynamic/.libs >> >> is missing. So I had to put >> >> ----------------------------------------------------------------------- >> export LDFLAGS="$LDFLAGS -L$RPM_BUILD_DIR/papi/source/libpapi-dynamic/.libs" >> ----------------------------------------------------------------------- >> >> before the "%configure" in the spec file. >> >> Till >> >> >> >> Till Kamppeter wrote: >> >> >>> Now I got it RPMized so that it can be installed on a machine with >>> already installed CUPS. No I tried to make it actually working with the >>> installed CUPS. I found out by running an "lpr" command through strace >>> that it tries to load the non-existing "lpsched" service >>> (/usr/lib/psm-lpsched.so) and I have seen in the source code that >>> "lpsched" is used a s the default service (should not be as "lpsched" >>> does not ship with the package. >>> >>> So I compile with >>> >>> export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=ipp" >>> ./configure --without-apache --without-ruby >>> make >>> >>> to make it using "ipp" as default service (can one configure/switch the >>> service at run time? There are no files in /etc/... and no documentation >>> about such files, man pages are only in section 1 and 8, nothing in >>> section 5). >>> >>> But with this setting it does not build: >>> >>> ------------------------------------------------------------------------------------ >>> [...] >>> Making all in libpapi-dynamic >>> make[2]: Entering directory >>> `/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic' >>> if /bin/sh ../../libtool --tag=CC --mode=compile >>> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. >>> -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" >>> -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 >>> -DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF ".deps/psm.Tpo" -c -o >>> psm.lo psm.c; \ >>> then mv -f ".deps/psm.Tpo" ".deps/psm.Plo"; else rm -f ".deps/psm.Tpo"; >>> exit 1; fi >>> mkdir .libs >>> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. >>> -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" >>> -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 >>> -DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF .deps/psm.Tpo -c >>> psm.c -fPIC -DPIC -o .libs/psm.o >>> if /bin/sh ../../libtool --tag=CC --mode=compile >>> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. >>> -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" >>> -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 >>> -DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF >>> ".deps/service.Tpo" -c -o service.lo service.c; \ >>> then mv -f ".deps/service.Tpo" ".deps/service.Plo"; else rm -f >>> ".deps/service.Tpo"; exit 1; fi >>> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. >>> -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\" >>> -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1 >>> -DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF .deps/service.Tpo >>> -c service.c -fPIC -DPIC -o .libs/service.o >>> service.c: In function 'service_load': >>> service.c:60: error: 'ipp' undeclared (first use in this function) >>> service.c:60: error: (Each undeclared identifier is reported only once >>> service.c:60: error: for each function it appears in.) >>> ICECREAM[19319]: Compiled on 192.168.2.67 >>> make[2]: *** [service.lo] Error 1 >>> make[2]: Leaving directory >>> `/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic' >>> make[1]: *** [all-recursive] Error 1 >>> make[1]: Leaving directory `/home/tkamppeter/rpm/BUILD/papi/source' >>> make: *** [all-recursive] Error 1 >>> ------------------------------------------------------------------------------------ >>> >>> Can you tell me how to get it correctly talking with CUPS? Thanks. >>> >>> Till >>> >>> >> > > _______________________________________________ > Desktop_printing mailing list > Desktop_printing@lists.osdl.org > https://lists.osdl.org/mailman/listinfo/desktop_printing > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-18 19:02 ` Norm Jacobs @ 2006-05-18 21:24 ` Till Kamppeter 2006-05-18 22:25 ` Till Kamppeter 0 siblings, 1 reply; 11+ messages in thread From: Till Kamppeter @ 2006-05-18 21:24 UTC (permalink / raw) To: Norm Jacobs; +Cc: printing-architecture, desktop_printing@osdl.org Thank you for this valuable info, so I will rearrange my RPM to choose the PAPI library with update-alternatives. Once manually configured (or automatically by scriptlets in RPMs, or by setup programs) to the actually installed spooler would serve well, no one is switching between spoolers between every print job. Usually on one box one spooler is used. And another thing: foomatic-configure auto-detects the locally installed spooler with a few lines, by checking presence of spooler-specific files. See more comments below. Till Norm Jacobs wrote: > The SourceForge openprinting project PAPI implementation actually > contains multiple implementations of the PAPI, but the one that > you link with and interact with directly uses a "printer-uri-supported" > value in your name service/configuration data to contact the print > service for a particular print queue. If there isn't a > printer-uri-supported > in the configuration data, it doesn't know how to contact the print service > and will only return the name service/configuration data from a query. > This > data is retrieved on Solaris using the name service switch and can be > stored in ${HOME}/.printers, /etc/printers.conf, NIS priners.conf.byname, > NIS+ printers.org_dir, and/or LDAP. On other platforms, the NSS support > is emulated and can be stored in /etc/printers.conf, /etc/printcap , and > NIS printers.conf.byname. > > If you add a > "printer-uri-supported=ipp\://majax.mandrakesoft.com/printers/HPPSmart2600" > to the /etc/printers.conf or /etc/printcap entry for your printer, It's > likely > that you will see the results that you are looking for. > This would require hacking the CUPS daemon to get this automatic. > The PAPI implementation should probably be modified to use the "rm" and > "rp" > information in abscense of a "printer-uri-supported" value. This would be > similiar to what is being done for "bsdaddr" > (see papi/source/libpapi-dynamic/nss.c:fill_printer_uri_supported) > > Additionally, the cupsd code that generates /etc/printcap and > /etc/printers.conf > entries (cups/scheduler/printers.c:cupsWritePrintcap()) could be > enhanced to > include the printer-uri-supported key/value data in it's output. > > Finally, if you only plan on targeting a particular print service, you can > probably get away with removing libpapi.so and replacing it with a symlink > to psm-{svc}.so. > For a fully automatic mode the best would be best to auto-detect the spooler at first and then use the spoolers native way to get the printer info. > -Norm > > PS > There are descriptions of the various bits in subversion under > papi/docs/README.*. > This is a short description of the PAPI implementations in the PAPI code > base. > The only docu I have read was the API spec (the PDF file) to understand what info PAPI can deliver to me. > I'll oversimplify this a little, but the PAPI implementation on SourceForge > contains multiple implementations of the PAPI (all exporting the PAPI > interface). > source/libpapi-dynamic (builds and installs as libpapi.so) > This implements something roughly analogous to the name service > switch. It is effectively interposed between the applications > and the "real" PAPI print service support. It resolves queue > names using a nameservice (/etc/printers.conf, /etc/printcap, > NIS printers.conf.byname). On Solaris this also includes > $HOME/.printers, NIS+ printers.org_dir, and LDAP. It uses the > "printer-uri-supported" information from these nameservices to > load backend PAPI print service support and contact the > real print service for the requested operation. The printer > query operations (papiPrintersList and papiPrintersQuery) support > in this library is "special" (and I don't necessarily mean that in > a good way), It may not contact the actual print service if the > name service contained the requested data. > > source/libpapi-lpd (builds and installs as psm-lpd.so and lpd-port) > This implements support for contacting RFC-1179 based print > services. > Because of the limitted nature and wide variety of RFC-1179 support, > the PAPI support is very limitted. The following printer/job > operations do something useful: > papiPrinterQuery, papiPrinterPurgeJobs, papiPrinterListJobs, > papiJobSubmit, papiJobSubmitByReference, > papiJobStreamOpen/Write/Close, > papiJobQuery, papiJobCancel > Because RFC-1179 returns very little information, the query > functions return a very basic skeleton of information. They > could be made to provide information from an associated PPD file, > but there are other areas where the time might be better spent. > lpd-port provides a means of isolating parts of rfc-1179 support > that require elevated privilege from that application. > > libpapi-ipp (builds and installs as psm-ipp.so) > This implements support for contacting IPP based print services. IPP > provides a a framework and rich set of operations and attributes for > printing. As a result, the PAPI support on top of IPP is complete. > It makes use of standard IPP operations and attributes for the vast > majority of the implementation with CUPS extensions being used where > there was no standard means. > So I will try to use psm-ipp.so deirectly now by setting some symlinks and if this works, I will use update-alternatives in the RPMs. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-18 21:24 ` Till Kamppeter @ 2006-05-18 22:25 ` Till Kamppeter 2006-05-19 3:35 ` Norm Jacobs 0 siblings, 1 reply; 11+ messages in thread From: Till Kamppeter @ 2006-05-18 22:25 UTC (permalink / raw) To: Norm Jacobs; +Cc: printing-architecture, desktop_printing@osdl.org I tried the trick with the links. I did ------------------------------------------------------------------------- [root@majax c]# mv /usr/lib/libpapi.so.0.0.0 /usr/lib/libpapi.so.0.0.0.orig [root@majax c]# ln -s /usr/lib/psm-ipp.so /usr/lib/libpapi.so.0.0.0 ------------------------------------------------------------------------- And then I got a lot of output with "printer-query", all CUPS-specific options and settings, but still one important thing missing: The options in the PPD file. So I cannot build a complete printing dialog with the info which I can poll with PAPI and this is very important for the standard to be adopted. Another thing is taht if I have queues which are broadcasted from remote machines to my local CUPS daemon, "printer-query" cannot poll info about them at all. It tells that these queues do not exist. Printing with the PAPI "lpr" command works, but "print-test" complains with the following error: ------------------------------------------------------------------------- [root@majax c]# print-test -d LJ4050 print-test: relocation error: print-test: symbol papiJobCreate, version SUNWprivate_1.0 not defined in file libpapi.so.0 with link time reference [root@majax c]# ------------------------------------------------------------------------- Till Till Kamppeter wrote: > Thank you for this valuable info, so I will rearrange my RPM to choose > the PAPI library with update-alternatives. Once manually configured (or > automatically by scriptlets in RPMs, or by setup programs) to the > actually installed spooler would serve well, no one is switching between > spoolers between every print job. Usually on one box one spooler is used. > > And another thing: foomatic-configure auto-detects the locally installed > spooler with a few lines, by checking presence of spooler-specific files. > > See more comments below. > > Till ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-18 22:25 ` Till Kamppeter @ 2006-05-19 3:35 ` Norm Jacobs 2006-05-19 9:38 ` Till Kamppeter 0 siblings, 1 reply; 11+ messages in thread From: Norm Jacobs @ 2006-05-19 3:35 UTC (permalink / raw) To: Till Kamppeter; +Cc: printing-architecture, desktop_printing@osdl.org Till Kamppeter wrote: > I tried the trick with the links. I did > > ------------------------------------------------------------------------- > [root@majax c]# mv /usr/lib/libpapi.so.0.0.0 /usr/lib/libpapi.so.0.0.0.orig > [root@majax c]# ln -s /usr/lib/psm-ipp.so /usr/lib/libpapi.so.0.0.0 > ------------------------------------------------------------------------- > > And then I got a lot of output with "printer-query", all CUPS-specific > options and settings, but still one important thing missing: The options > in the PPD file. So I cannot build a complete printing dialog with the > info which I can poll with PAPI and this is very important for the > standard to be adopted. > The PPD file data via a capabilities interface is something that Wendy is working on. I don't know that there is an ETA yet. > Another thing is taht if I have queues which are broadcasted from remote > machines to my local CUPS daemon, "printer-query" cannot poll info about > them at all. It tells that these queues do not exist. > The PAPI implementation in psm-ipp.so will contact the IPP server that is either the "default" compiled in service, specified via environment variable (IPP_SERVER, CUPS_SERVER) or via the destination name. Eg. papiPrinterQuery(svc, "ipp://server/printers/queue", ...); $ lpstat -p ipp://server/printers/queue -l 2 Part of the attraction of the libpapi-dynamic implementation is that it will enumerate print queues from a configuration db/name service and resolve names to uri's on a variety of print services across multiple hosts. To solve the update problem with CUPS browse protocol, I prototyped a CUPS browse listener that can be run to keep /etc/printers.conf up to date. The right way to do this on systems with CUPS running would be to have CUPS make the configuration updates via the "PrintcapFormat" directive. I can supply diffs for this as well. I run both Solaris LP and CUPS on my laptop side by side with a mod for this. > Printing with the PAPI "lpr" command works, but "print-test" complains > with the following error: > > ------------------------------------------------------------------------- > [root@majax c]# print-test -d LJ4050 > print-test: relocation error: print-test: symbol papiJobCreate, version > SUNWprivate_1.0 not defined in file libpapi.so.0 with link time reference > [root@majax c]# > ------------------------------------------------------------------------- > > I will look into this. -Norm ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-19 3:35 ` Norm Jacobs @ 2006-05-19 9:38 ` Till Kamppeter 2006-05-19 12:13 ` Norm Jacobs 0 siblings, 1 reply; 11+ messages in thread From: Till Kamppeter @ 2006-05-19 9:38 UTC (permalink / raw) To: Norm Jacobs Cc: mike, Wendy Phillips, printing-architecture, desktop_printing@osdl.org Norm Jacobs wrote: > Till Kamppeter wrote: > >> I tried the trick with the links. I did >> >> ------------------------------------------------------------------------- >> [root@majax c]# mv /usr/lib/libpapi.so.0.0.0 >> /usr/lib/libpapi.so.0.0.0.orig >> [root@majax c]# ln -s /usr/lib/psm-ipp.so /usr/lib/libpapi.so.0.0.0 >> ------------------------------------------------------------------------- >> >> And then I got a lot of output with "printer-query", all CUPS-specific >> options and settings, but still one important thing missing: The options >> in the PPD file. So I cannot build a complete printing dialog with the >> info which I can poll with PAPI and this is very important for the >> standard to be adopted. >> > > The PPD file data via a capabilities interface is something that Wendy > is working on. I don't know that there is an ETA yet. What is an ETA? > >> Another thing is taht if I have queues which are broadcasted from remote >> machines to my local CUPS daemon, "printer-query" cannot poll info about >> them at all. It tells that these queues do not exist. >> > > The PAPI implementation in psm-ipp.so will contact the IPP server > that is either the "default" compiled in service, specified via environment > variable (IPP_SERVER, CUPS_SERVER) or via the destination name. Eg. > > papiPrinterQuery(svc, "ipp://server/printers/queue", ...); > > $ lpstat -p ipp://server/printers/queue -l 2 > > Part of the attraction of the libpapi-dynamic implementation is that it > will > enumerate print queues from a configuration db/name service and resolve > names to uri's on a variety of print services across multiple hosts. To > solve > the update problem with CUPS browse protocol, I prototyped a CUPS browse > listener that can be run to keep /etc/printers.conf up to date. The right > way to do this on systems with CUPS running would be to have CUPS make > the configuration updates via the "PrintcapFormat" directive. I can supply > diffs for this as well. I run both Solaris LP and CUPS on my laptop > side by side > with a mod for this. > A standard CUPS frontend like kprinter shows all printers available via the local or selected CUPS server, including the ones which the server gets via broadcast. It also shows all capabilities of the broadcasted printers as they were local. And for that no external name service or file like /etc/printers.conf is needed. To make it as transparent as possible for end users an application linked against libpapi running on a box with CUPS as printing system should show the same printers and options as an application directly linked against libcups and this should be achieved without any change on the CUPS configuration, the CUPS daemon or library code and without any extra name service or browse listener daemon. It is a nice thing to have the libpapi-dynamic which can pull in various other PAPI libs and poll name services to serve on machines with different spoolers running in parallel, but I think there should also be a PAPI library which gets the full information out of CUPS. Perhaps this PAPI library (psm-cups.so or libpapi-cups.so) is perhaps more easily done by linking it against libcups to avoid redoing of code. Till ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation 2006-05-19 9:38 ` Till Kamppeter @ 2006-05-19 12:13 ` Norm Jacobs 0 siblings, 0 replies; 11+ messages in thread From: Norm Jacobs @ 2006-05-19 12:13 UTC (permalink / raw) To: Till Kamppeter Cc: mike, Wendy Phillips, printing-architecture, desktop_printing@osdl.org Till Kamppeter wrote: > Norm Jacobs wrote: > >> Till Kamppeter wrote: >> >> >>> I tried the trick with the links. I did >>> >>> ------------------------------------------------------------------------- >>> [root@majax c]# mv /usr/lib/libpapi.so.0.0.0 >>> /usr/lib/libpapi.so.0.0.0.orig >>> [root@majax c]# ln -s /usr/lib/psm-ipp.so /usr/lib/libpapi.so.0.0.0 >>> ------------------------------------------------------------------------- >>> >>> And then I got a lot of output with "printer-query", all CUPS-specific >>> options and settings, but still one important thing missing: The options >>> in the PPD file. So I cannot build a complete printing dialog with the >>> info which I can poll with PAPI and this is very important for the >>> standard to be adopted. >>> >>> >> The PPD file data via a capabilities interface is something that Wendy >> is working on. I don't know that there is an ETA yet. >> > > What is an ETA? > > estimated time of arrival >>> Another thing is taht if I have queues which are broadcasted from remote >>> machines to my local CUPS daemon, "printer-query" cannot poll info about >>> them at all. It tells that these queues do not exist. >>> >>> >> The PAPI implementation in psm-ipp.so will contact the IPP server >> that is either the "default" compiled in service, specified via environment >> variable (IPP_SERVER, CUPS_SERVER) or via the destination name. Eg. >> >> papiPrinterQuery(svc, "ipp://server/printers/queue", ...); >> >> $ lpstat -p ipp://server/printers/queue -l 2 >> >> Part of the attraction of the libpapi-dynamic implementation is that it >> will >> enumerate print queues from a configuration db/name service and resolve >> names to uri's on a variety of print services across multiple hosts. To >> solve >> the update problem with CUPS browse protocol, I prototyped a CUPS browse >> listener that can be run to keep /etc/printers.conf up to date. The right >> way to do this on systems with CUPS running would be to have CUPS make >> the configuration updates via the "PrintcapFormat" directive. I can supply >> diffs for this as well. I run both Solaris LP and CUPS on my laptop >> side by side >> with a mod for this. >> >> > > A standard CUPS frontend like kprinter shows all printers available via > the local or selected CUPS server, including the ones which the server > gets via broadcast. It also shows all capabilities of the broadcasted > printers as they were local. And for that no external name service or > file like /etc/printers.conf is needed. To make it as transparent as > possible for end users an application linked against libpapi running on > a box with CUPS as printing system should show the same printers and > options as an application directly linked against libcups and this > should be achieved without any change on the CUPS configuration, the > CUPS daemon or library code and without any extra name service or browse > listener daemon. > > It is a nice thing to have the libpapi-dynamic which can pull in various > other PAPI libs and poll name services to serve on machines with > different spoolers running in parallel, but I think there should also be > a PAPI library which gets the full information out of CUPS. Perhaps this > PAPI library (psm-cups.so or libpapi-cups.so) is perhaps more easily > done by linking it against libcups to avoid redoing of code. > > I agree, the IPP module should be able to ask the CUPS/IPP server for all of the printers it knows about and then use them. papiPrintersList() uses CUPS extensions to IPP (CUPS_GET_PRINTERS and CUPS_GET_CLASSES) to get a list of queues that the print service knows about. -Norm ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-05-19 12:13 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-05-17 13:28 [Printing-architecture] Building PAPI implementation Till Kamppeter 2006-05-17 14:32 ` [Printing-architecture] " Norm Jacobs 2006-05-17 21:03 ` Till Kamppeter 2006-05-18 9:48 ` [Desktop_printing] " Till Kamppeter 2006-05-18 15:29 ` Till Kamppeter 2006-05-18 19:02 ` Norm Jacobs 2006-05-18 21:24 ` Till Kamppeter 2006-05-18 22:25 ` Till Kamppeter 2006-05-19 3:35 ` Norm Jacobs 2006-05-19 9:38 ` Till Kamppeter 2006-05-19 12:13 ` Norm Jacobs
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.