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

[Johannes Meixner]

Hello all,

hello Till,
I don't know if you followed the "Infrared channel" thread.
Now I include you explicitely because I think we have come
to a point where I would like to have you informed.

I don't know who is the scanner-stuff maintainer at Red Hat.

The "Infrared channel" thread has changed to a discussion
about how to enhance the scanner description data which
is at the moment stored in *.desc source files.


On Feb 22 12:10 m. allan noah wrote (shortened):
> > > > i would like to see a few things done in the sane2 standard:
> > > > 3. more consistent config file interface for all backends
> > > 
> > > I would appreciate this very much.
> > > 
> > > At the moment all what the Suse scanner config tool does is:
> > > a) show a list of model names made from the *.desc files
> > > b) let the user select a model from this list
> > > c) activate the matching backend in dll.conf
> > > 
> > > At the moment it is simply ignored when particular models require
> > > special settings in <backend>.conf
> > > 
> > > I think we should discuss about an enhanced *.desc file format
> > > to specify autodetected model strings and model dependent
> > > parameter settings in <backend>.conf

Summary for Till:

I made a proposal to use PPD syntax for scanner description data
and there is the question whether scanner description data should
be in seperated files or whether each backend should be called
in a special mode and then the backend would spit out the
scanner description data.
------------------------------------------------------------------
[yesterday:]
For printer setup this problem is already solved by the so called
"PPD files" which describe printer model specific settings.
Perhaps it is possible to "misuse" the PPD file syntax for scanner
setup as well.
The advantage would be that the PPD file syntax is an established
standard wich is proved to work o.k.

[today:]
Regardless whether we use *.desc files, PPD files, XML files,
or the backend spits out the data:
We must agree on one data format for scanner description.
This data format should be extensible.
I like the general idea of the PPD syntax.
I assume manufacturers may like the PPD syntax too because
manufacturers know how to create PPD files for printers
and if they can use their existing tools also for scanners,
I assume they would be happy.
-----------------------------------------------------------------

> ok, so here is what i have been working on for the fujitsu backend conf file.
> i have situations where 2 of the same model of scanner may be connected to one
> machine, or where the order of insertion of two scanners may be different, so
> it is difficult to tell which one is where. there are also situations where
> the scanner is new but similar to an existing model, so being able to tell the
> backend to treat it as such is nice.
> 
> so what i have been trying to do is something more like either the syntax of
> samba's config (with [sections] followed by key=value pairs) or a simple grid
> with '*' for the missing items (like crontab)
> 
> ie:
> 
> # /etc/sane/fujitsu.conf
> # global section:
> default=main_scanner
> 
> [main_scanner]
> connection=usb
> vid=1234
> pid=5678
> SN=12345670001
> fw_file='/etc/fw/blah.bin'
> vid2=9090
> pid2=a556
> SN2=123412341234
> 
> [sec_scanner]
> connection=scsi
> name='Mega Scanner 3000'
> acts_like='Mega Scanner 2700'
> 
> this gives a permanent 'name' to a particular scanner, so that if you have
> more than one scanner on the computer, you dont have to guess which to use.
> when the user asks for 'fujitsu', you could use the 'default', and go lookup
> that vid/pid/SN on the usb bus, and upload the firmware, then look for the
> changed vid/pid/sn
> 
> if they say 'fujitsu:sec_scanner' then we scan the scsi bus for that name, but
> after we find it, pretend its a different model.
> 
> i suppose, if you even went so far, you could make just one of these files,
> instead of one for each backend, with the sections imported from external text
> files. this is a big reason i like the ppd or external desc files over the
> backend having a special mode: you could give someone a ppd that makes their
> new scanner work with an older backend easily (disable some options, etc)

Good point!

The more I think about it the more I like to copy the way
how it is done for printers - i.e.:
For each scanner use a PPD file (instead of one <backend>.conf).
Of course each backend can provide a generic PPD file which
can be used like <backend>.conf now.

I think external files and backend special mode do not exclude
each other:
The backend in special mode could spit out the PPD files
(according to internal data of the backend)
or the PPD files are provided seperated.

The point is what is used as scanner config file.
I think there should be one PPD file for each scanner as config file.

Why do I think PPD files are the right way:
It is simply the fact that for printers various problems are
already sloved by using PPDs and why re-invent the wheel?

Examples of solved problems by using PPDs:
- Several exactly same models.
- Several almost same models, e.g. one with ADF, one without
  (like one printer with duplex unit, one without).
- Options and choices with one choice being the default/(fallback).
- Constraints to exclude choices which cannot work together
  (e.g. for printers: print on transparencies and use duplex mode).
- Options and choices available for end-user selection (OpenUI/CloseUI)
  versus options and choices only to be changed by the admin.
- Option groups and sub-groups (for a nicer user interface).
- Translation strings (show options and choices in user's language).

Of course I know that the PPD spec. needs some enhancements:
- At the moment only fixed lists of choices are possible.
  Arbitrary user input (which mtches a regexp) should be possible.
- At the moment only one translation string for one language
  is possible (i.e. each language requires another PPD).
  Multiple translation strings for various languages
  should be possible in the same PPD.

The above enhancements are needed for printers and there
are several ideas how to solve them (e.g. as far as I know the
next major CUPS version defines a 100% PPD spec compliant way
for multiple translation strings in the same PPD).


For the future it might become even crucial to use PPDs
for printers and for scanners:
This way all-in-one devices (printer/scanner/copier/fax) could
be supported by one single user frontend.
- Option groups and sub-groups in the PPD would seperate the
  options in the user frontend.
- Options which are meaningless for one function are simply
  ignored (e.g. you can print without any problem using
  "lp -d <queue> -o nonsense=doesnotexist <file>").
Of course not everything is already solved:
- Fax support requires arbitrary user input to specify the
  fax number of the recipient.


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