SANE2 was: Re: [sane-devel] Infrared channel

[Johannes Meixner]

Hello,

On Feb 23 10:05 m. allan noah wrote (shortened):
> On Wed, 23 Feb 2005, Till Kamppeter wrote:
> 
> > I think, the best is if the backend can spit out this data. Then there can
> > never happen that the database and the actually installed backends differ
> > from each other.
> 
> unfortunately, scanners often work in a fashion similar to printers, the model
> may not have existed at the time the backend was compiled, but it will still
> work with the backend. if our users have the option of going to an online db
> and getting a ppd made for their new scanner, and drop it in on their existing
> backend, then i think the idea is ok.

I think "backend spit out PPD" and "external PPD files" do not
exclude each other - see my other mail from today.

Of course a backend can only spit out PPDs for its internally
known models (whatever "internally known" means).

The crucial point is:
If a PPD is used as backend config file then it is possible
to use one of the PPDs spit out by the backend or(!) use any
other PPD which matches to the backend.

To set up a model:
1.:
The backend must be activated in dll.conf in any case.
2.:
Optionally a PPD which matches to the model can be copied
for example into /etc/sane.d/<backend>/<arbitrary-name>.ppd

Then the user could specify exactly this model via
scanimage -d <arbitrary-name>
or as usual via
scanimage -d <what "scanimage -f '%d'" has shown>

If no such PPD exists in /etc/sane.d/<backend>/
the backend could fall back to its generic behaviour
or the backend may require a /etc/sane.d/<backend>/generic.ppd
(which would be a replacement for <backend>.conf) and such
a generic.ppd could be installed by default for each backend.


> so this would give us a base directory full of ppd files, one for each
> backend/scanner combination. would this directory be a part of your vendor's
> sane .rpm/.deb?

Of course!
The same as we do it now to set up printers.
At the moment we have more than 3000 PPDs for printers.
No real problem with normal hardware - perhaps a bit slow
on 500Mhz/64MB machines - but it works o.k. even there.

All what Till and I wanted to point out is that it would be
nicer when the PPDs could be spit out by the backends only
to avoid inconsistencies between backend and PPD.

If "backend spit out PPD" is too much work (in this case
PPD input and PPD output must be implemented in the backend)
then it is perfectly o.k. to have external PPDs.

It is also perfectly o.k. when some backends have external PPDs
and other backends can spit out their PPDs.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix@suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/