Hi Norm, thanks for this clarification. Hoping that we will have in the next months a solution. :-)
Best regards Pascal Norm Jacobs wrote: > Comments are inline > > Pascal Kreyer wrote: >> On which level will CUPS be integrated ? Between the customer >> application and the printer directly or through PAPI ? >> Why should we add cups support on GTK, mozilla products or >> staroffice if we send the printers through PAPI ? >> > We actually don't have to add CUPS support to any of these > components. It's a matter of building and shipping the existing > code. We haven't done so before because we haven't shipped CUPS. >> An another question. What is the actual status of capability support >> from the printing project ? > Wendy is better equipped to answer this. She has been looking at > adding capabilities support to PAPI. >> On my point of view, this is certainly most important that CUPS >> integration. Should we not create before a solution that work with >> 90% of all applications before to integrate any other print service ? > Several years ago, we worked with others to define an interface for > that, PAPI came out of that. Unfortunately, PAPI currently falls > short in the area of capabilities and has gone largely unadopted. On > the other hand, CUPS (and libcups) address this area and seem to be > being largely adopted in the open source world. > >> Actually only Acrobat Reader use CUPS to obtain the capability >> information. >> If i look the different customer request on my side, the most >> important is to unify the print dialog box and in same time add the >> capability support like duplex, multi-tray and black/white switch >> support. >> > Along those lines, the GTK print dialog support for CUPS includes PPD > file options. The deprecated libgnomeprint support does as well. The > Mozilla support that uses libcups doesn't supply capabilities, but > rumor has it that Mozilla is looking to use the GTK print dialog in > the not too distant future. I think that StarOffice (OpenOffice) can > also use the CUPS interface to get PPD file data for it's dialog. I > believe that the same is also true for toolkits like Qt and other > applications like Inkscape. > > Just to throw a wrench in the whole thing, there is work in progress > in the OpenPrinting world to create a unified print dialog. (see > http://www.mmiworks.net/eng/publications/labels/openPrinting.html) > Peter Sikking is working on the UI design and I think that some people > are planning on getting together to implement something based on his > design work in a couple of months in Europe. > > There are trade-offs between using CUPS or using LP as your print > service. At a very cursory level, CUPS enjoys better desktop > application integration than LP and it enjoys a wider set of printer > support. On the other hand, LP has some client side name service > support and server side features currently not available under CUPS. > > -Norm >
