Mailinglist Archive: opensuse-factory (393 mails)

< Previous Next >
Re: [opensuse-factory] Re: Meeting minutes dist meeting 2007-03-23
  • From: Johannes Meixner <jsmeix@xxxxxxx>
  • Date: Thu, 29 Mar 2007 12:31:44 +0200 (CEST)
  • Message-id: <Pine.LNX.4.64.0703291127590.24650@xxxxxxxxxxxxxx>


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 ;-)

> 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

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

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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >