libkdeprint

[Kurt Pfeifle]

John Layt wrote:
> On Saturday 03 November 2007, Kurt Pfeifle wrote:
>> Are you saying you detect the cupsd.conf config file? And doing so by
>> searching the local file system?
>>
>> If so, that is not "good enough". The CUPS daemon to connect to may not
>> be running locally, but on a remote server.
>>
>> Also, does the code take into account that the local cupsd may not at
>> all listen at a TCP/UDP port, but only at a local unix domain socket?
> 
> The KDE3 KDEPrint code which I copied tries to connect to a local UNIX socket 
> with a path of /ipp,

Strange. (However, IIRC, that spot in the code was fiddled with by various
different people since the first bugs concerning domain socket printing
where reported...).

The default path used by CUPS itself (if you compile from pristine CUPS
sources) is in $CUPS_STATEDIR/cups.sock with CUPS_STATEDIR=/var/run/cups

Of course, it can be overriden in cupsd.conf (in which case the local
lp/lpr print commands can only know about it if the environment variable
CUPS_SERVER=/some/non/standard/path/to/domain/socket is set, or the line
in {/etc/cups,$HOME/.cups}/client.conf}

Server /some/non/standard/path/to/domain/socket

is found.

> and checks if cupsd.conf exists in various locations.  
> Both have to be true for it to believe it can talk to CUPS:
> 
> 	KMFactory::autoDetect()
> 	KMFactory::pluginList()
> 	KMFactory::pluginInfo()
> 	KdeprintChecker::check()
> 	using details in kdeprint/cups/cups.print
> 
> Is there a file that we can reliably say will be installed locally even if the 
> daemon is on a remote server?

I don't think so.

In KDE3, if I *know* where the remote server is, I can use the GUI to
point KDEPrint for that server (and it will work if libcups is present
locally [and KDEPrint is build against it], even if there is *no* CUPS-
owned lp/lpr print command installed.

> I'm assuming the CUPS versions of lp and lpr will transparently know how to 
> talk to the remote server?

Yes, by proxy of being linked to libcups. As does cupsdoprint in KDE3
by the same means.

They look (I think in the order I give below) for the server to use:

 (1)  $HOME/.cups/client.conf  # user owned file
 (2)  /etc/cups/client.conf    # system wide file
 (3)  CUPS_SERVER              # environment variable
 (4)  the compiled-in default  # determined at build (configure params)

and will use the first match.

>> Can't you look if that lpr binary is linked to libcups? On a shell I'd
>> do the "ldd $(which lpr)|grep libcups" test...
> 
> I'll look into that, would this work on all the *nix platforms?

Yes. (Unless the naming of libs is different on Mac).

>> KDEPrint3 didn't use the CUPS lpr/lp commands at all. It knew how to
>> talk IPP to CUPS, and it used "cupsdoprint" as a helper utility.
> 
> Well, there's a couple of good reasons not to talk directly to CUPS/IPP, 
> mainly because FilePrinter wll not be in kdelibs for 4.0 but will instead be 
> added to every application that wants to use it, i.e. okular, kghostview, 
> ligature. 

Well, the good reason to talk directly to CUPS using IPP is that this is
the mostly used printing system right now.

So can't we do that in case we find CUPS (and fall back to BSD otherwise)?

> If we had to build a cupsdoprint in every one of those apps, each 
> of them would pick up a compile-time dependency on CUPS, and we would have to 
> give cupsdoprint a different name for each to avoid install clashes. 

Hmm, I don't get this.

Why can't they use all the same generic "kdedoprint" (which tries CUPS
first, and falls back to BSD if CUPS is not here)?

Just like they'll use the lpr command they may or may not find right
now (which may or may not work even if found, depending on the other
circumstances discussed above)?

> When 
> you then consider that the few user options we can currently pull out from 
> QPrintDialog are all supported by the lpr command line, it just seemed the 
> simplist solution.
> 
> Now, if we still need this in 4.1, then obviously it will move to kdelibs and 
> we can then do it properly through cupsdoprint, but we'll cross that bridge 
> later.

Well, I didn't write my comments in this threat in order to insist this
should be in 4.0. I've no clue how much work it is.

I just want to make sure you know all the facts, and base your design de-
cisions on them, and head for a course that does not rule out fixes/improve-
ments in 4.1+

> With regard to lp, it's always installed with CUPS? 

lp/lpr are the 2 print client commands built when you compile CUPS from
sources.

If you install the CUPS server parts only, you may not have lp/lpr ne-
cessarily. Depends on how the distro splits its .deb, .rpm., .tgz,...
packages.

> What's its status if CUPS 
> isn't installed? 

Debian (who seems to be the distro most obsessed with package splitting)
split CUPS like this:

ii  cupsys         1.3.2-1   Common UNIX Printing System(tm) - server
ii  cupsys-bsd     1.3.2-1   Common UNIX Printing System(tm) - BSD commands
ii  cupsys-client  1.3.2-1   Common UNIX Printing System(tm) - client programs (SysV)
ii  cupsys-common  1.3.2-1   Common UNIX Printing System(tm) - common files

where

cupsys-client contains:

  /usr/bin/lp

  /usr/bin/lppasswd
  /usr/bin/lpoptions
  /usr/bin/cancel
  /usr/bin/lpstat
  /usr/bin/cupstestdsc
  /usr/bin/cupstestppd
  /usr/bin/cupsenable
  /usr/bin/cupsdisable
  /usr/sbin/cupsaddsmb
  /usr/sbin/cupsctl
  /usr/sbin/lpadmin
  /usr/sbin/accept
  /usr/sbin/lpinfo
  /usr/sbin/lpmove
  /usr/sbin/cupsaccept
  /usr/sbin/cupsenable
  /usr/sbin/cupsreject
  /usr/sbin/cupsdisable
  /usr/sbin/reject

and cupsys-bsd contains:

  /usr/bin/lpr

  /usr/bin/lpq
  /usr/bin/lprm
  /usr/sbin/lpc



> We could always just try a succession of calls to lp and 
> lpr with and without the options hoping one will work :-)

Please! Not "always".     s/always/for now/

However, I doubt this will work reliably... Are you sure that the non-
CUPS lpr/lp commands will give you a non-0 return code in case they
don't understand an option, or can't connect to the LPR server? (It's
too long that I used LPR/LPD frequently enough to memorize this kind
of behaviour exactly.)

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany