Hello, I added Michal Zugec, the author of the YaST printer module to CC. On Mar 28 11:37 Chris Rivera wrote (shortened):
I noted it could be a starting point, nothing more. How do we generate our database? No one in the previous dist meetings indicating we had a good mapping of printers to print drivers and noted that previous efforts to collect this data had failed.
YaST already uses one. :-)
Is /var/lib/YaST2/ppd_db.ycp the one you're referring to?
Basically this is a leftover from old days when YaST also supported old-style printing systems like LPRng/lpdfilter. Currently it is merely the YaST version (a YaST YCP data structure) of a PPD info cache what CUPS has as /var/cache/cups/ppds.dat and from which CUPS can show the "lpinfo -l -m" output quite fast (i.e. without parsing all PPDs under /user/share/cups/model/ again).
How is this generated? Where do you get the mapping information from?
The details can be answered by Michal Zugec. Basically the mapping is based upon a tricky manufacturer and model string comparison (don't expect they match exactly) together with "recommended" info from the NickName in the PPDs and the PPD's sub-directory and a lot of hope that it works well ;-) see https://bugzilla.novell.com/show_bug.cgi?id=220712#c11
Fedora uses Foomatic
In the past (I don't know about the current state) Red Hat's printer setup tool was not in compliance to CUPS because it worked based upon Foomatic's XML-like database files. What the tool did was to generate a PPDs file on the fly from Foomatic's XML-like database files and then set up the queue with this new generated PPD file. If a printer setup tool uses whatever "private" data source, the consequence is that this tool will set up different stuff than all the other tools which work in compliance to CUPS like "lpadmin", CUPS web frontend, YaST, KDE printer setup tool, Gnome printer setup tool, HPLIP printer setup tool, ... The only way a printer setup tool can work in compliance to CUPS is to use the PPDs under /user/share/cups/model/ and nothing else. Stricty speaking even this is wrong since CUPS 1.2 because CUPS 1.2 supports printer drivers which generate PPDs on the fly (note the difference to printer setup tools which do this!) so that since CUPS 1.2 the only way a printer setup tool can work in compliance to CUPS 1.2 is to work based upon CUPS's "lpinfo -l -m" output (or matching CUPS library calls). Regarding "PPD generation on the fly" by printer drivers see http://www.cups.org/newsgroups.php?s1+gcups.general+v2+T0+Q%22PPD+generation... This means that as soon as there are printer drivers which generate PPDs on the fly, YaST does no longer work in compliance to CUPS.
There are tools other than Yast that need a printer to ppd/driver mapping.
Note the "device-id" field in "lpinfo -l -m" which matches a 1284DeviceID entry in the PPD file and which should (hopefully) match how the model shows up at the parallel port or USB.
The parsing and fuzzy mapping of ppd files on the system is painful.
Unfortunately many PPDs don't have a 1284DeviceID entry and therefore the painful fuzzy mapping via manufacturer and model name is all what can be done for many models. But it doesn't work too bad if the manufacturer shows reasonable manufacturer and model name via USB (which is e.g. often true for HP but often false for Epson).
Printerdrake also uses automatic queue setup. See https://wiki.ubuntu.com/PrinterDrake.
As far as I know Till Kamppeter is involved in PrinterDrake and Till knows very well how to work in compliance to CUPS so that PrinterDrake might be a much better example how it can be done than the Red Hat tool (which doesn't mean that looking at Red Hat's tool is forbidden ;-)
We might not even need a mapping for the uris.
If we find a way how to do it without such a mapping, it would be great because actually such a mapping cannot work because nobody can predict what whatever (third-party) backend will use for its URIs.
We can simply use the callout as a "a new printer was added" event. We can then use the list of printers detected by the backends and compare them to the list cups knows about to figure out which printers need to be setup.
You mean compare the "lpinfo -l -v" output to the "grep DeviceURI /etc/cups/printers.conf" output? With some tricks it might work (at least at the moment I don't see why it cannot work at all - like the URI mapping). Perhaps it is sufficient to filter the "lpinfo -l -v" output to ignore those URIs which are only generic placeholders but don't mean a real detected printer. At least all URIs which are only the scheme (i.e. the backend name and no colon and stuff after the colon) don't mean a real detected printer (see "man backend"). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org