Discussion:
Infrared channel
(too old to reply)
Michal Jaegermann
2005-02-20 23:09:02 UTC
Permalink
Yes, I have seen a rather short "Sane does not support the dust
removal with the Perfection 4870" here:

http://lists.alioth.debian.org/pipermail/sane-devel/2004-September/012111.html

But does somebody at least have some idea how to read an infrared
channel? It looks that quite a number of scanners is able to provide
that information nowadays but looking at backend sources only coolscan
and coolscan2 drivers can do that now and the situation did not change
for years. Are there any plans on the subject?

As a matter of fact yes, I am interested in that capability for Epson
Perfection 4870. Apparently VueScan, http://www.hamrick.com/, is able
to perform that feat on Linux as well.

Michal

ps. Please cc any eventual answers to me too.
Gerhard Jaeger
2005-02-22 07:28:18 UTC
Permalink
Hi,
Post by Michal Jaegermann
Yes, I have seen a rather short "Sane does not support the dust
http://lists.alioth.debian.org/pipermail/sane-devel/2004-September/012111.html
But does somebody at least have some idea how to read an infrared
channel? It looks that quite a number of scanners is able to provide
that information nowadays but looking at backend sources only coolscan
and coolscan2 drivers can do that now and the situation did not change
for years. Are there any plans on the subject?
As a matter of fact yes, I am interested in that capability for Epson
Perfection 4870. Apparently VueScan, http://www.hamrick.com/, is able
to perform that feat on Linux as well.
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.

The solution (whenever we can start) is SANE 2 where we have a more flexible
approach for transmitting image data to a frontend.
It might also be possible for a backend to read the infrared channel and to
perform i.e. the dust removal in the backend, but this functionality should
in general be part of a frontend.

VueScans' advantage or disadvantage here is, that you have a all-in-one
program (scanner-driver + image processor), this has never been the
approach of SANE...

Maybe it's really time now for SANE 2, but it seems we get more and more
problems in writing new driver code, as reverse engineering consumes too
much time...

Ciao,
Gerhard
Rene Rebe
2005-02-22 08:26:43 UTC
Permalink
Hi,
Post by Gerhard Jaeger
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
The solution (whenever we can start) is SANE 2 where we have a more flexible
approach for transmitting image data to a frontend.
It might also be possible for a backend to read the infrared channel and to
perform i.e. the dust removal in the backend, but this functionality should
in general be part of a frontend.
VueScans' advantage or disadvantage here is, that you have a all-in-one
program (scanner-driver + image processor), this has never been the
approach of SANE...
Maybe it's really time now for SANE 2, but it seems we get more and more
problems in writing new driver code, as reverse engineering consumes too
much time...
I think the immediate available development time is too low for SANE 2
right now. But maybe I'm mistaken ... (I would have the time and
motivation to convert the Avision backend but there are so many others
as well as other applications ...)

However just adding one or more SANE_FRAME_ types would be a trivial task:

SANE_FRAME_RGBI = 5
SANE_FRAME_IR = 6

;-)

But maybe we do not want to do this to have an argument to push SANE 2 ;-)

Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
Gerhard Jaeger
2005-02-22 09:10:19 UTC
Permalink
Post by Rene Rebe
Hi,
Post by Gerhard Jaeger
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
The solution (whenever we can start) is SANE 2 where we have a more flexible
approach for transmitting image data to a frontend.
It might also be possible for a backend to read the infrared channel and to
perform i.e. the dust removal in the backend, but this functionality should
in general be part of a frontend.
VueScans' advantage or disadvantage here is, that you have a all-in-one
program (scanner-driver + image processor), this has never been the
approach of SANE...
Maybe it's really time now for SANE 2, but it seems we get more and more
problems in writing new driver code, as reverse engineering consumes too
much time...
I think the immediate available development time is too low for SANE 2
right now. But maybe I'm mistaken ... (I would have the time and
motivation to convert the Avision backend but there are so many others
as well as other applications ...)
SANE_FRAME_RGBI = 5
SANE_FRAME_IR = 6
;-)
But maybe we do not want to do this to have an argument to push SANE 2 ;-)
he, he ;)

a few weeks ago, I started with button support for the plustek backend,
using your ideas Rene, that's another point for starting SANE 2 - but could
also be done - somehow - with the current.

But in the end we have too much backends and not that much time to spent.
IMHO we really have two options to proceed:

- expanding SANE 1 in a more or less compatible way (is there really anybody
out there who will have problems with this????)

- starting SANE 2 with, let's say 2 or three backends (in the end your Avision
stuff, my Plustek backends (plustek, plustek_pp and u12, maybe some other
VOLUNTEERS???????? - hell lot of work to do ;)

ciao,
Gerhard
Major A
2005-02-22 09:19:22 UTC
Permalink
Post by Gerhard Jaeger
- starting SANE 2 with, let's say 2 or three backends (in the end your Avision
stuff, my Plustek backends (plustek, plustek_pp and u12, maybe some other
VOLUNTEERS???????? - hell lot of work to do ;)
I've been suggesting that for months. As soon as a simple SANE2
front-end (scanimage) is available, I'm volunteering to adapt
coolscan2 fairly quickly. But first we'll have to decide how to
organize CVS so as to accommodate SANE2 (no fork please!), then it's
all downhill from there.

Andras
Rene Rebe
2005-02-22 09:29:24 UTC
Permalink
Hi,
Post by Major A
Post by Gerhard Jaeger
- starting SANE 2 with, let's say 2 or three backends (in the end your Avision
stuff, my Plustek backends (plustek, plustek_pp and u12, maybe some other
VOLUNTEERS???????? - hell lot of work to do ;)
I've been suggesting that for months. As soon as a simple SANE2
front-end (scanimage) is available, I'm volunteering to adapt
coolscan2 fairly quickly. But first we'll have to decide how to
organize CVS so as to accommodate SANE2 (no fork please!), then it's
all downhill from there.
For SANE 2 we also can recycle at least the sp15c backend maybe even the
tamarack one. In theory those are covered by the Avision backend. Maybe
I need two or three more conditionals to not send too new Avision
commands to them, but all are Avision OEM devices and the backends just
implemend a tiny subset of the Avision command set (and AFAICS neither
is really maintained).

Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
gerard klaver
2005-02-22 10:54:36 UTC
Permalink
Post by Rene Rebe
Hi,
Post by Gerhard Jaeger
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
The solution (whenever we can start) is SANE 2 where we have a more flexible
approach for transmitting image data to a frontend.
It might also be possible for a backend to read the infrared channel and to
perform i.e. the dust removal in the backend, but this functionality should
in general be part of a frontend.
VueScans' advantage or disadvantage here is, that you have a all-in-one
program (scanner-driver + image processor), this has never been the
approach of SANE...
Maybe it's really time now for SANE 2, but it seems we get more and more
problems in writing new driver code, as reverse engineering consumes too
much time...
I think the immediate available development time is too low for SANE 2
right now. But maybe I'm mistaken ... (I would have the time and
motivation to convert the Avision backend but there are so many others
as well as other applications ...)
SANE_FRAME_RGBI = 5
SANE_FRAME_IR = 6
;-)
But maybe we do not want to do this to have an argument to push SANE 2 ;-)
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
Adding some SANE_FRAME_ types which can be used for webcams would also
be nice (jpg for example).
Support for icc profiles in the SANE structure would also be nice
On the Gimp mailinglist they are also busy with discussion about icc
profiles or better a color management system.

If SANE 2 means better support possible for the features of scanners,
webcams there should be made a start someday.
Saying this i have no idea how much work it is to convert a SANE 1
backend to a SANE 2 backend and how much work it is to convert/rewrite
the frontends also i don't know much about SANE 2 standaard but i expect
a timetable of 1 or 2 years?

The v4l to v4l2 conversion (kernel modules) shows some comparison that
it takes some time.
--
--------
m.vr.gr.
Gerard Klaver
Gerhard Jaeger
2005-02-22 13:23:31 UTC
Permalink
Post by gerard klaver
Post by Rene Rebe
Hi,
Post by Gerhard Jaeger
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
The solution (whenever we can start) is SANE 2 where we have a more flexible
approach for transmitting image data to a frontend.
It might also be possible for a backend to read the infrared channel and to
perform i.e. the dust removal in the backend, but this functionality should
in general be part of a frontend.
VueScans' advantage or disadvantage here is, that you have a all-in-one
program (scanner-driver + image processor), this has never been the
approach of SANE...
Maybe it's really time now for SANE 2, but it seems we get more and more
problems in writing new driver code, as reverse engineering consumes too
much time...
I think the immediate available development time is too low for SANE 2
right now. But maybe I'm mistaken ... (I would have the time and
motivation to convert the Avision backend but there are so many others
as well as other applications ...)
SANE_FRAME_RGBI = 5
SANE_FRAME_IR = 6
;-)
But maybe we do not want to do this to have an argument to push SANE 2 ;-)
Yours,
Adding some SANE_FRAME_ types which can be used for webcams would also
be nice (jpg for example).
Support for icc profiles in the SANE structure would also be nice
On the Gimp mailinglist they are also busy with discussion about icc
profiles or better a color management system.
okay, okay, but that is exactly the problem we're running at!
For such changes, we first need the documentation finished and agreed, then
we can do this...
Post by gerard klaver
If SANE 2 means better support possible for the features of scanners,
webcams there should be made a start someday.
Saying this i have no idea how much work it is to convert a SANE 1
backend to a SANE 2 backend and how much work it is to convert/rewrite
the frontends also i don't know much about SANE 2 standaard but i expect
a timetable of 1 or 2 years?
I'm not really sure!
We can reuse a lot of the sanei_ libs, they're tested, maybe some of them
need to be updated. The configure framework can maybe reused...
Post by gerard klaver
The v4l to v4l2 conversion (kernel modules) shows some comparison that
it takes some time.
Yes, you are right there.
First of all we should agree to what needs to be done, how we are willing
to proceed.
- extending SANE 1
- starting SANE 2, by finishing the documents OR another approach: hacking
(which is not a good idea)

Ciao,
Gerhard
m. allan noah
2005-02-22 14:16:18 UTC
Permalink
Post by Gerhard Jaeger
Post by Gerhard Jaeger
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
The solution (whenever we can start) is SANE 2 where we have a more flexible
approach for transmitting image data to a frontend.
It might also be possible for a backend to read the infrared channel and to
perform i.e. the dust removal in the backend, but this functionality should
in general be part of a frontend.
okay, okay, but that is exactly the problem we're running at!
For such changes, we first need the documentation finished and agreed, then
we can do this...
Yes, you are right there.
First of all we should agree to what needs to be done, how we are willing
to proceed.
- extending SANE 1
- starting SANE 2, by finishing the documents OR another approach: hacking
(which is not a good idea)
agreed. i have made a (small) attempt to convert the fujitsu backend to
sane2, but it think the standard is not yet complete enough. i have always
found it difficult to complete documentation without a working test case,
though, so to make sane2 really viable, it would seem that we need a
single backend and simple front-end ported, and modify the standard as
that is built.

i would like to see a few things done in the sane2 standard:

1. buttons as named by the labels on the outside of the scanner
2. simpler locking (or the ability to disable complex locking)
3. more consistent config file interface for all backends
4. better integration with hotplug and multiple scanners of the same type
active at the same time.

other people have mentioned as well:

color correction
IR and jpeg frame types
generic per-scanner config adjustments storage (dot-file in homedir?)

anything i missed?

allan
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Johannes Meixner
2005-02-22 15:21:49 UTC
Permalink
Hello,
...
Post by m. allan noah
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
Post by m. allan noah
4. better integration with hotplug and multiple scanners of the
same type active at the same time.
This is a related problem.

In many cases the autodetected model string does not match to
the model name in the *.desc file.

Therefore it is normally not possible to determine the matching
backend from the autodetected model string.

I think we should discuss about an enhanced *.desc file format
to specify autodetected model strings and model dependent
parameter settings in <backend>.conf

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.
Post by m. allan noah
anything i missed?
Is there any special stuff needed to support big and fat
printer/scanner/copiers in the network?

In contrast to the small directly connected desktop scanners
such big and fat network-scanners can do the scanning (almost)
on their own.
I.e. the user can go to the printer/scanner/copier and do
the scan only by using the buttons and the display which
is integrated in the device.

All what such a network-scanner needs is a recipient
to which it can send the data of the scanned image.
Some of those device may even have a built-in disk
to store the images and the user could scan many images
and later the user would like to download the images from
the printer/scanner/copier to his workstation.

At the moment the recipient is normally a mail account
to which the printer/scanner/copier sends the image.

But it would be nicer if the image download could be done
via a SANE backend and/or if the printer/scanner/copier
could use this backend as recipient for the image data.

I would like when the manufacturers of such devices could make
SANE backends easily - i.e. the SANE frontend must support
to connect to a network-scanner (e.g. specify the IP address
and the port etc.).
I think it doesn't work to tell the manufacturers they should
implement a "saned" which runs in their network-scanners
because I think they won't change the firmware.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Gerhard Jaeger
2005-02-22 16:23:05 UTC
Permalink
On Tuesday 22 February 2005 16:21, Johannes Meixner wrote:
[SNIPSNAP]
Post by Johannes Meixner
Therefore it is normally not possible to determine the matching
backend from the autodetected model string.
I think we should discuss about an enhanced *.desc file format
to specify autodetected model strings and model dependent
parameter settings in <backend>.conf
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.
You are right, but I don't like the idea to "misuse" something, especially
it has a spec consiting of 186 pages ;)
But we should really create some unique database, somehow automagically,
where every backend puts it's information and options to in a well defined
way.
Post by Johannes Meixner
Post by m. allan noah
anything i missed?
Is there any special stuff needed to support big and fat
printer/scanner/copiers in the network?
In contrast to the small directly connected desktop scanners
such big and fat network-scanners can do the scanning (almost)
on their own.
I.e. the user can go to the printer/scanner/copier and do
the scan only by using the buttons and the display which
is integrated in the device.
All what such a network-scanner needs is a recipient
to which it can send the data of the scanned image.
Some of those device may even have a built-in disk
to store the images and the user could scan many images
and later the user would like to download the images from
the printer/scanner/copier to his workstation.
[SNIPSNAP]

Well I think this could be done with the current SANE implementation.
Somebody simply has to write a backend for that task...

Ciao,
Gerhard
Johannes Meixner
2005-02-22 16:43:30 UTC
Permalink
Hello,
Post by Gerhard Jaeger
Post by Johannes Meixner
Perhaps it is possible to "misuse" the PPD file syntax for scanner
setup as well.
You are right, but I don't like the idea to "misuse" something,
especially it has a spec consiting of 186 pages ;)
Don't get confused by the length of the PPD spec.
The spec of the plain PPD syntax is small.
Most in Adobe's PPD spec is description about very printer
specific stuff (which keywords should be used and so on ...).
Post by Gerhard Jaeger
But we should really create some unique database, somehow
automagically, where every backend puts it's information
and options to in a well defined way.
I didn't dare to ask for this.

Obviously it is best not to maintain any kind of text files
but to run the backend in a special mode and the backend spits out
what it knows in a well defined format.

This way a config tool would call all actually installed backends
and build the list of models upon the actual backend information
and not upon possibly wrong or outdated text files.


Kind Regards,
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Olaf Meeuwissen
2005-02-23 01:34:16 UTC
Permalink
Post by Johannes Meixner
Post by Gerhard Jaeger
Post by Johannes Meixner
Perhaps it is possible to "misuse" the PPD file syntax for scanner
setup as well.
You are right, but I don't like the idea to "misuse" something,
especially it has a spec consiting of 186 pages ;)
Don't get confused by the length of the PPD spec.
The spec of the plain PPD syntax is small.
Most in Adobe's PPD spec is description about very printer
specific stuff (which keywords should be used and so on ...).
Post by Gerhard Jaeger
But we should really create some unique database, somehow
automagically, where every backend puts it's information
and options to in a well defined way.
I didn't dare to ask for this.
What you are suggesting here sounds quite a bit to the way foomatic
handles printers.

- an XML database
- a few utilities to crank out PPD files
- one utility to glue the PPDs, the spooler and the printer drivers
together

I guess, we could do without the PPD files for scanners because there
is no established standard yet. Anyway, with all the info in an XML
database, converting to *.desc or *.conf or ... is just a matter of
writing the right XSL style sheet.

See http://www.linuxprinting.org/foomatic.html for details.
Post by Johannes Meixner
Obviously it is best not to maintain any kind of text files
but to run the backend in a special mode and the backend spits out
what it knows in a well defined format.
It be nice if the backend could spit out a baseline because quite a
few backends seem to at least partially support new models without any
modification. As a matter of fact, I have been playing with the
thought to externalise a lot of data that is now hard-coded in the
epkowa backend into data files. This would make it possible to add
support for at least some scanners without a recompile of the backend.
# If the original data is in XML format, it would also ease keeping my
# (internal) specs in sync with reality ;-)

Just my two yen,
--
Olaf Meeuwissen EPSON KOWA Corporation, PF1
FSF Associate Member #1962 sign up at http://member.fsf.org/
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
Penguin's lib! -- I hack, therefore I am -- LPIC-2
Johannes Meixner
2005-02-23 09:34:27 UTC
Permalink
Hello,
Post by Olaf Meeuwissen
What you are suggesting here sounds quite a bit to the way foomatic
handles printers.
- an XML database
- a few utilities to crank out PPD files
- one utility to glue the PPDs, the spooler and the printer drivers
together
Note that the Foomatic XML is not 100% compliant to XML spec
see "entity reference problem in XML data" on LinuxPrinting.org:
http://www.linuxprinting.org/pipermail/foomatic-devel/2004q1/001838.html
and the "DTDs: first try" thread on LinuxPrinting.org, for example:
http://www.linuxprinting.org/pipermail/foomatic-devel/2004q1/001830.html

I.e. if you like to use XML be very careful to produce correct XML.
Note that XML can be valid (i.e. xmllint doesn't complain) but
nevertheless it is not what you expect (see above), see for example:
http://www.linuxprinting.org/pipermail/foomatic-devel/2004q1/001851.html
(there is a wrong mail reference, it should be .../2004q1/001838.html)
I think the best way to make sure the XML is correct is not to use
selfmade XML parsers but only established tools like xmllint
and xsltproc.

Some notes regarding possible problems:

Do not depend on XML or any other intermediate format.
Do not force the authors of scanner software to provide XML.
Only specify the syntax of the final scanner description data.
This way third party software (e.g. HP's HPLIP or Epson Kowa's Iscan)
can be made as the authors of this software like to do it.

For printers only the PPD format is mandatory.
It doesn't matter how the PPDs are created.
Examples:
- PPDs for PostScript printers are created by internal tools
of the printer manufacturers
- PPDs for HP's HPIJS driver are created somehow by HP
(I don't care how HP makes them - I only use the PPDs)
- PPDs for the GimpPrint/Gutenprint driver are created
via Foomatic-stlye XML
Post by Olaf Meeuwissen
I guess, we could do without the PPD files for scanners
I would prefer this too.
Post by Olaf Meeuwissen
Post by Johannes Meixner
Obviously it is best not to maintain any kind of text files
but to run the backend in a special mode and the backend spits out
what it knows in a well defined format.
It be nice if the backend could spit out a baseline because quite a
few backends seem to at least partially support new models without any
modification. As a matter of fact, I have been playing with the
thought to externalise a lot of data that is now hard-coded in the
epkowa backend into data files. This would make it possible to add
support for at least some scanners without a recompile of the backend.
# If the original data is in XML format, it would also ease keeping my
# (internal) specs in sync with reality ;-)
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.

I would prefer when the backend would spit out the data
in the scanner-description-format because this way each author
of a backend can use the interal data representation he likes most.

If a backend author likes to have the data in scanner-description-format
in an external file, then all the backend has to do is output the file.

If a backend author likes hardcoded internal data the backend would
have to convert it into scanner-description-format and output this.

If the internal backend data cannot be made public available
(e.g. a proprietary binary-only backend - Olaf can you imagine
which backend I have in mind ;-) the backend could nevertheless
output at least minimal scanner-description-format data like
model name, autodetection model string/ID, and support status.


Kind Regards,
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
m. allan noah
2005-02-22 16:29:59 UTC
Permalink
Post by Johannes Meixner
...
Post by m. allan noah
3. more consistent config file interface for all backends
I would appreciate this very much.
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
unfortunately, this can be difficult to deal with, since what each model
needs can vary drastically. cheaper models that require firmware to be
loaded come to mind, and some models do crazy things like change usb ID or
name after the firmware is loaded.
Post by Johannes Meixner
Post by m. allan noah
4. better integration with hotplug and multiple scanners of the
same type active at the same time.
This is a related problem.
In many cases the autodetected model string does not match to
the model name in the *.desc file.
Therefore it is normally not possible to determine the matching
backend from the autodetected model string.
I think we should discuss about an enhanced *.desc file format
to specify autodetected model strings and model dependent
parameter settings in <backend>.conf
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.
ok, i have played with ppd only a little, but it does seem to work. the
problem comes with new scanners, or re-badged scanners. the current system
of loading every backend in turn, and letting them use a back-end specific
way to determine if they support the scanner gives us more flexibility
than a ppd file for each know model.

no, that said, i notice that quite a few backends just string compair to
determine this info, so the ppd file would be no different, except that
the 'string' is not always in the usb descriptor or scsi inq request...
Post by Johannes Meixner
Post by m. allan noah
anything i missed?
Is there any special stuff needed to support big and fat
printer/scanner/copiers in the network?
In contrast to the small directly connected desktop scanners
such big and fat network-scanners can do the scanning (almost)
on their own.
I.e. the user can go to the printer/scanner/copier and do
the scan only by using the buttons and the display which
is integrated in the device.
All what such a network-scanner needs is a recipient
to which it can send the data of the scanned image.
Some of those device may even have a built-in disk
to store the images and the user could scan many images
and later the user would like to download the images from
the printer/scanner/copier to his workstation.
At the moment the recipient is normally a mail account
to which the printer/scanner/copier sends the image.
But it would be nicer if the image download could be done
via a SANE backend and/or if the printer/scanner/copier
could use this backend as recipient for the image data.
I would like when the manufacturers of such devices could make
SANE backends easily - i.e. the SANE frontend must support
to connect to a network-scanner (e.g. specify the IP address
and the port etc.).
I think it doesn't work to tell the manufacturers they should
implement a "saned" which runs in their network-scanners
because I think they won't change the firmware.
Kind Regards
Johannes Meixner
you could write a sane backend that did this, but you would need one for
every different network transmission proto.

allan
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
m. allan noah
2005-02-22 17:10:53 UTC
Permalink
Post by Johannes Meixner
Post by m. allan noah
3. more consistent config file interface for all backends
I would appreciate this very much.
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
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)

allan
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Johannes Meixner
2005-02-23 11:13:11 UTC
Permalink
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.
Post by Johannes Meixner
Post by m. allan noah
3. more consistent config file interface for all backends
I would appreciate this very much.
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)
# /etc/sane/fujitsu.conf
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: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Till Kamppeter
2005-02-23 14:14:45 UTC
Permalink
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.

Having *.desc files, PPDs and the Foomatic database is mostly because
the drivers itself cannot output this information. In addition, printer
drivers can have many different architectures: GhostScript built-in,
filter on bitmap output of GhostScript, IJS driver, CUPS driver,
PPD-only (PostScript printer). Foomatic builds a unique interface around
that and so all printers get PostScript printers, with PPD file and
getting PostScript as input.

In SANE one has at least only one driver architecture, the SANE
backends. So it would not be very difficult to include appropriate
querying functions into the SANE2 API.

The syntax of this output should be

- Easily machine-readable, but also human-readable (like PPD, xml, ...)
- Extendable format
- Not based on too complicated standard (PPD specs have > 160 pages)
- Contain all needed info for each supported model (list of models
must be queriable, too):
o The scanner model name naturally (human- and machine-readable)
o Possible connection types
o Needed kernel modules
o Needed external software/configuration (like HPLIP for "hpaio"
backend)
o Has backend to run as root (for example for direct user-mode access
to the parallel port)
o Scanner auto-detection info: USB vendor/product, device name
returned by SCSI query, ...
o If scanner setup cannot be done fully automatically, info about
what manual steps/parameter settings are needed
o Info whether serial number is queryable (to allow more than one
of the same model on the same machine)
o Firmware or other files needed?
o ICC profiles supported?
o Options which can be set by the user, including default settings,
possible choices/ranges, String and password input options must be
possible, too (PPDs do not support this). All dependent on the
scanner model.
o How well is this model supported?

(Please add what I have forgotten).

In addition to provide all needed info to scanner setup and utilities
and scanning frontends, one could also have the SANE libs on the SANE
project web server and generate the "Supported Devices" pages on the
fly. A cron job could rebuild the SANE libs from CVS regularly.

By the way, in Mandrakelinux I let scannerdrake use a database generated
from the *.desc files and one additional file manually created by me.
This additional file contains for each backend which lines have to be in
the config file, dependent on the connection type (SCSI, USB, parallel).
The line prototypes contain placeholders where things like USB IDs,
firmware filenames, ... have to be inserted. Scannerdrake inserts these
lines when it found the appropriate scanner model (or when the user has
selected it from the device list) and inserts the appropriate data for
the placeholders. For the firmware a file dialog shows up and the
specified file gets copied into /user/share/sane/firmware, then the path
and name inserted into the backend's config file. On startup
scannerdrake calls "sane-find-scanner" and then "scanimage -L". It
compares the output and tries to configure all scanners found by
"sane-find-scanner" but missing in "scanimage -L". After each
configuration of a scanner Scannerdrake runs "scanimage -L" to build the
list of available scanners in the main window. For parallel scanners
saned is set up to run as root and share to localhost and the "net"
backend to poll from localhost, so that normal users can use "root-only"
scanners. scannerdrake has also the possibility to set up network
scanner sharing via saned/"net" backend.

In Mandrakelinux 10.2 I have added some functionality: Needed kernel
modules are loaded and added to the modules to be loaded at boot time,
user is warned if a scanner requires editing the backend's config file,
and in the list of scanner models unsupported scanners will get a big
"(UNSUPPORTED)" (some users complained at us that they bought a scanner
listed bt scannerdrake and when connecting it and clicking on the entry,
scannerdrake told that the scanner is not supported).

Till
Post by 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.
Post by Johannes Meixner
Post by m. allan noah
3. more consistent config file interface for all backends
I would appreciate this very much.
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
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,
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)
# /etc/sane/fujitsu.conf
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
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
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.
It is simply the fact that for printers various problems are
already sloved by using PPDs and why re-invent the wheel?
- 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).
- 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
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>").
- Fax support requires arbitrary user input to specify the
fax number of the recipient.
Kind Regards
Johannes Meixner
m. allan noah
2005-02-23 15:05:52 UTC
Permalink
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. the online db
would need to be able to say things like "requires sane version xxx" so
that users wont try to use a new ppd on an ancient version of a backend.

or did you have in mind that the backend would output the ppd when it
finds the scanner the first time?
Having *.desc files, PPDs and the Foomatic database is mostly because the
drivers itself cannot output this information. In addition, printer drivers
can have many different architectures: GhostScript built-in, filter on bitmap
output of GhostScript, IJS driver, CUPS driver, PPD-only (PostScript
printer). Foomatic builds a unique interface around that and so all printers
get PostScript printers, with PPD file and getting PostScript as input.
In SANE one has at least only one driver architecture, the SANE backends. So
it would not be very difficult to include appropriate querying functions into
the SANE2 API.
The syntax of this output should be
- Easily machine-readable, but also human-readable (like PPD, xml, ...)
- Extendable format
- Not based on too complicated standard (PPD specs have > 160 pages)
- Contain all needed info for each supported model (list of models
o The scanner model name naturally (human- and machine-readable)
o Possible connection types
o Needed kernel modules
o Needed external software/configuration (like HPLIP for "hpaio"
backend)
o Has backend to run as root (for example for direct user-mode access
to the parallel port)
o Scanner auto-detection info: USB vendor/product, device name
returned by SCSI query, ...
o If scanner setup cannot be done fully automatically, info about
what manual steps/parameter settings are needed
o Info whether serial number is queryable (to allow more than one
of the same model on the same machine)
o Firmware or other files needed?
o ICC profiles supported?
o Options which can be set by the user, including default settings,
possible choices/ranges, String and password input options must be
possible, too (PPDs do not support this). All dependent on the
scanner model.
o How well is this model supported?
(Please add what I have forgotten).
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?
In addition to provide all needed info to scanner setup and utilities and
scanning frontends, one could also have the SANE libs on the SANE project web
server and generate the "Supported Devices" pages on the fly. A cron job
could rebuild the SANE libs from CVS regularly.
By the way, in Mandrakelinux I let scannerdrake use a database generated from
the *.desc files and one additional file manually created by me. This
additional file contains for each backend which lines have to be in the
config file, dependent on the connection type (SCSI, USB, parallel). The
line prototypes contain placeholders where things like USB IDs, firmware
filenames, ... have to be inserted. Scannerdrake inserts these lines when it
found the appropriate scanner model (or when the user has selected it from
the device list) and inserts the appropriate data for the placeholders. For
the firmware a file dialog shows up and the specified file gets copied into
/user/share/sane/firmware, then the path and name inserted into the backend's
config file. On startup scannerdrake calls "sane-find-scanner" and then
"scanimage -L". It compares the output and tries to configure all scanners
found by "sane-find-scanner" but missing in "scanimage -L". After each
configuration of a scanner Scannerdrake runs "scanimage -L" to build the list
of available scanners in the main window. For parallel scanners saned is set
up to run as root and share to localhost and the "net" backend to poll from
localhost, so that normal users can use "root-only" scanners. scannerdrake
has also the possibility to set up network scanner sharing via saned/"net"
backend.
In Mandrakelinux 10.2 I have added some functionality: Needed kernel modules
are loaded and added to the modules to be loaded at boot time, user is warned
if a scanner requires editing the backend's config file, and in the list of
scanner models unsupported scanners will get a big "(UNSUPPORTED)" (some
users complained at us that they bought a scanner listed bt scannerdrake and
when connecting it and clicking on the entry, scannerdrake told that the
scanner is not supported).
your desc file format would need 2.4 and 2.6 linux kernel modules, as well
as possibly the same for the bsd's.

allan
Till
Post by 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.
Post by Johannes Meixner
Post by m. allan noah
3. more consistent config file interface for all backends
I would appreciate this very much.
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
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,
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)
# /etc/sane/fujitsu.conf
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
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
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.
It is simply the fact that for printers various problems are
already sloved by using PPDs and why re-invent the wheel?
- 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).
- 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
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>").
- Fax support requires arbitrary user input to specify the
fax number of the recipient.
Kind Regards
Johannes Meixner
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Johannes Meixner
2005-02-23 17:04:17 UTC
Permalink
Hello,
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: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Johannes Meixner
2005-02-23 15:47:12 UTC
Permalink
Hello,
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.
Yes, this would be best.
In SANE one has at least only one driver architecture, the SANE backends.
... and funny required daemons like PTAL/HPLIP and what else may
occur in the future (in particular for proprietary backends).
The syntax of this output should be
- Easily machine-readable, but also human-readable (like PPD, xml, ...)
- Extendable format
- Not based on too complicated standard (PPD specs have > 160 pages)
Don't get confused by the length of the PPD spec.
The spec of the plain PPD syntax is small.
Most in Adobe's PPD spec is description about very printer
specific stuff (which keywords should be used and so on ...).
I am only talking about using the plain PPD syntax.

I think if a new syntax was created, the semantic would be
the same as in the PPD syntax because I think we need all
what is possible with the PPD syntax:
- options (main keywords), choices (option keywords), defaults
- option groups and sub-groups
- user-interface options <-> admin-only options
- constraints
- translation strings
and additionally
- choices for arbitrary user input which matches a regexp
I.e. we could start with the PPD syntax and enhance it.

Because PPD syntax allows adding arbitrary keywords, I think
this is a sufficient extendable format.
But we must agree upon standard main keywords and option keywords
(just like in Adobe's PPD spec).
- Contain all needed info for each supported model (list of models
[...]
(Please add what I have forgotten).
o The backend name must also be in a scanner PPD.
Or should this be just one choice of a "driver" option?

For printing there are almost no PPDs which include different
drivers because of too many constraints. (Only drivers with same
driver optins like "ljet4, lj4dith" are in one PPD.)
By the way, in Mandrakelinux I let scannerdrake use a database generated from
the *.desc files and one additional file manually created by me. This
additional file contains for each backend which lines have to be in the config
file,
And you must verify each entry in this additional file for each new
SANE version whether it is still valid :-(
Otherwise it may happen you enter obsolete stuff.

Examples:

In the old Yast scanner setup we set the SCSI device in
<backend>.conf but I detected that at least the hp backend
perfectly autodetects SCSI scanners.
Having a SCSI device like /dev/sg0 in <backend>.conf may cause
problems because the generic SCSI device nodes are assigned in
arbitrary order to the SCSI devices (all USB storage devices
are SCSI devices and get a generic SCSI device node).
If a backend does not do autodetection when the SCSI device
is set in <backend>.conf, the scanner may work or not depending
how many USB storage devices have been connected during
scanner setup and are now connected when using the scanner.

In epkowa.conf there is (or was) by default the line
usb /dev/usb/scanner0
which causes that it doesn't work out of the box with libusb.
Since I changed it in the Suse iscan package to
usb
it works out of the box with libusb because epkowa
autodetects its USB scanners.

As a result I do no longer like to change the defaults in
<backend>.conf because I assume when a backend detects a model
it knows best which settings it must use for this model.
As I do not have all scanner models to verify such settings
(in fact I only have a few models) I think it is safer to rely
on the automatisms in the backend than setting possible wrong
values in <backend>.conf.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Oliver Rauch
2005-02-23 19:33:36 UTC
Permalink
Hello.

I do not understand the discussion about the sane config file format.

In a usual/normal case the config file of a backend should not be
touched by a user or configuration program:
- We do not need to enter any device files because the sanei_* routines
search the devices and passes them to the backend.
- The position of a firmware file should be defined by a rule like a
path prefix and the backend an device name, e.g.
/pathto_foo/sane/firmware/umax/astra1220u.firmware
- The backend knows what devices it does support. It is dangerous when
you tell the backend to handle an unknown device as an already known
device. You can break the scanner with a bad setup.
When someone contacts me because he things my backend could support his
scanner then I do some tests with his help and tell him what he can
change in the config file.

It is dangerous when a setup program or an unexperienced user is
changing the config file. For supported scanners it generally is not
necessary to change anything in the config file.

I suggest to discuss how we can make the sane-backends work without any
config file changes. The first versions of SANE did work out of the box
for supported devices. There is no need for tweaking config files.

We have to define how a backend can find a firmware file and how a setup
program does now where to put a firmware version. There is no need to
change any config files for this reason.

Oliver
m. allan noah
2005-02-23 19:59:55 UTC
Permalink
most respectfully oliver, i disagree. perhaps your points about scanner
damage, etc are true in your backend because of models of scanners that
you support, but for my backend, it is far more likely that there is an
odd variation on the scanner that the backend does not know about, but
works just like an existing model.

also, the current sane method of loading every backend under the sun
trying to find the owner works, but is not very efficient, especially in
systems where there is only one scanner, and it does not change. my linux
box does not do this with all the known ethernet drivers everytime i ifup
eth0!

hence, the vendors have scanner tools that attempt to modify the dll.conf
to only load the right backends.one could make a strong case for finding
ways to do more in hotplug, instead of via such manual tools, and
it would seem that a very clear mapping between scanner models and
backends is the best way to do this. two different vendor representatives
have told us that the current conf/desc setup is not cutting it.

we are just discussing alternatives.

allan
Post by Oliver Rauch
Hello.
I do not understand the discussion about the sane config file format.
In a usual/normal case the config file of a backend should not be
- We do not need to enter any device files because the sanei_* routines
search the devices and passes them to the backend.
- The position of a firmware file should be defined by a rule like a
path prefix and the backend an device name, e.g.
/pathto_foo/sane/firmware/umax/astra1220u.firmware
- The backend knows what devices it does support. It is dangerous when
you tell the backend to handle an unknown device as an already known
device. You can break the scanner with a bad setup.
When someone contacts me because he things my backend could support his
scanner then I do some tests with his help and tell him what he can
change in the config file.
It is dangerous when a setup program or an unexperienced user is
changing the config file. For supported scanners it generally is not
necessary to change anything in the config file.
I suggest to discuss how we can make the sane-backends work without any
config file changes. The first versions of SANE did work out of the box
for supported devices. There is no need for tweaking config files.
We have to define how a backend can find a firmware file and how a setup
program does now where to put a firmware version. There is no need to
change any config files for this reason.
Oliver
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Oliver Rauch
2005-02-23 20:37:40 UTC
Permalink
Post by m. allan noah
most respectfully oliver, i disagree. perhaps your points about scanner
damage, etc are true in your backend because of models of scanners that
you support, but for my backend, it is far more likely that there is an
odd variation on the scanner that the backend does not know about, but
works just like an existing model.
That also is true for some umax scanners. But I still think that the
backend author(s) should care about that.
Post by m. allan noah
hence, the vendors have scanner tools that attempt to modify the dll.conf
to only load the right backends.one could make a strong case for finding
ways to do more in hotplug, instead of via such manual tools, and
it would seem that a very clear mapping between scanner models and
backends is the best way to do this. two different vendor representatives
have told us that the current conf/desc setup is not cutting it.
What the linux distribution vendors try is to create a workaround for
the bad situation in the moment. This does not mean that it is the best
approach.

I think SANE should work out of the box without tweaking config files.

It is ok to add something like /dev/usb/xyz behaves like "Model 872" to
the config file, but we do not need XML or other things for this.

It is a good idea to make the config files a bit more uniform,
but the discussion goes into the wrong direction in the moment.

Oliver
m. allan noah
2005-02-23 20:41:36 UTC
Permalink
Post by Oliver Rauch
Post by m. allan noah
most respectfully oliver, i disagree. perhaps your points about scanner
damage, etc are true in your backend because of models of scanners that
you support, but for my backend, it is far more likely that there is an
odd variation on the scanner that the backend does not know about, but
works just like an existing model.
That also is true for some umax scanners. But I still think that the
backend author(s) should care about that.
Post by m. allan noah
hence, the vendors have scanner tools that attempt to modify the dll.conf
to only load the right backends.one could make a strong case for finding
ways to do more in hotplug, instead of via such manual tools, and
it would seem that a very clear mapping between scanner models and
backends is the best way to do this. two different vendor representatives
have told us that the current conf/desc setup is not cutting it.
What the linux distribution vendors try is to create a workaround for
the bad situation in the moment. This does not mean that it is the best
approach.
I think SANE should work out of the box without tweaking config files.
It is ok to add something like /dev/usb/xyz behaves like "Model 872" to
the config file, but we do not need XML or other things for this.
It is a good idea to make the config files a bit more uniform,
but the discussion goes into the wrong direction in the moment.
but you give no reasons why! you just repeatedly say we are doing wrong.
that is not constructive.

yes, what the vendors do is odd and divergent from the normal sane
installation (suse's insistence on resmgr comes to mind) but if you admit
that there is a 'bad situation', the how about some ideas to fix it,
instead of hoping it will go away?

allan
Post by Oliver Rauch
Oliver
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Oliver Rauch
2005-02-23 21:37:36 UTC
Permalink
Post by m. allan noah
but you give no reasons why! you just repeatedly say we are doing wrong.
that is not constructive.
yes, what the vendors do is odd and divergent from the normal sane
installation (suse's insistence on resmgr comes to mind) but if you admit
that there is a 'bad situation', the how about some ideas to fix it,
instead of hoping it will go away?
What I say is: it is better when it is not necessary to tweak any config
files than to have a good tool to tweak the config files.


When you want to have a reason for this then you also can ask for a
reason for: "It is better to be not ill than to have a good doctor".

Oliver
Gerhard Jaeger
2005-02-24 07:49:57 UTC
Permalink
Post by Oliver Rauch
Post by m. allan noah
but you give no reasons why! you just repeatedly say we are doing wrong.
that is not constructive.
yes, what the vendors do is odd and divergent from the normal sane
installation (suse's insistence on resmgr comes to mind) but if you admit
that there is a 'bad situation', the how about some ideas to fix it,
instead of hoping it will go away?
What I say is: it is better when it is not necessary to tweak any config
files than to have a good tool to tweak the config files.
When you want to have a reason for this then you also can ask for a
reason for: "It is better to be not ill than to have a good doctor".
okay, okay ;)

the intention was, that sane should work out of the box, BUT in fact it
doesn't anymore. We really have too much different config-entries, which
need to be tweaked.

In times, where everybody (of course there are some exceptions ;) wants
a graphical configuration frontend, we should really improve the situation
here - and we should improve it in a way, that a new version is compatible
to the older one.

I fully understand the positions of the various distri guys. If you want
to increase acceptance of Linux, then you should have a comfortable
configuration tool (yes - with a GUI), that allows an easy setup.
We currently have .conf files, .desc files and the dll.conf to enable/
disable a backend. The .conf file is territory of each backend maintainer
and thus there are no limits, which is confusing, as some backends work
without touching the .conf file others did not.

I also agree, that introducing such stuff as PPD or XML might not be the
correct way, as I think its oversized, but improving the internal API to
support external configuration tools - or better, we provide also a
config tool as demo on our own.

From a users point of view, he will buy or download a distri, plug-in
the devices - all devices - he owns, and wants a running and working
system. And he wants a tool, with which he can tweak settings.

In the end, we need an easy to use AND handle way to unify the scanner
descriptions and to give the distri guys the possibility to create
tools for configuration:

- install SANE
- ask what is supported
- select what is wanted
- show the available options
- select and test if scanner works
- done

And I think to get this, we have to do something - BUT this will
be SANE2.

Ciao,
Gerhard
Julien BLACHE
2005-02-24 11:17:22 UTC
Permalink
Post by Gerhard Jaeger
In the end, we need an easy to use AND handle way to unify the scanner
descriptions and to give the distri guys the possibility to create
Ok, so, as a "distri guy", I disagree with this.

I agree with Oliver, in that there's no need for config files tweaking
by the user, and I back that one with facts: SANE in Debian works
pretty much out of the package for most of the scanners newcomers care
about, that is, USB scanners. The same is true for most SCSI scanners,
while parport scanners are, well, parport scanners :P

Let's face it, for some backends, it's not possible to get rid of the
config file, but for most this could and should be done.

Config tools are a pain, let's avoid that as much as we can. The
future of scanners and other peripherals is clearly USB and FireWire,
and whatever will be next will have the same goals: plug&play, no
configuration, device/capability advertisement and so on.

Users do not want config tools. They want to use their scanner, and
that's it. Most users do not need a thousand options to tweak, they
just want something that works.

And don't even think about documentation, they won't read it.

Now, if only our beloved vendors could stop their firmware
crazyness... *THAT* is much more painful for our users than editing
dll.conf.

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Johannes Meixner
2005-02-24 14:44:17 UTC
Permalink
Hello,
there's no need for config files tweaking by the user
If this is true, why are there so many config files?
for some backends, it's not possible to get rid of the
config file
How should such a scanner be set up when you neither want
a config tool nor do you want to change the config file?

I think it is up to the author of a backend whether or
not he likes to have everything hardcoded in the backend
or have settings in a config file.
Users do not want config tools. They want to use their scanner,
and that's it.
I have heared this kind of "the hardware must simply work"
wishes many many times since years and since years there is
a lot of step by step progress but since years there is no
general solution to set up hardware without user interaction.

Please let us be constructive and proceed step by step
instead of wishes which may be implemented in some years.
Now, if only our beloved vendors could stop their firmware
crazyness...
Perhaps you are more successful than I to teach the hardware
manufacturers how they should make their devices for those
customers who simply buy the cheapest one.

In fact there would be nothing bad with firmware upload
if the manufacturers provided backends which have the
firmware included (or as external files) and the backend
cares for the firmware upload
or if the manufacturers permit free distribution and
re-distribution of the firmware files so that the firmware
files could be included in the sane-backends or in a special
package of the distributors (if firmware files without source
code cannot be included in sane-backends).


Kind Regards,
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Julien BLACHE
2005-02-24 15:17:29 UTC
Permalink
Post by Johannes Meixner
there's no need for config files tweaking by the user
If this is true, why are there so many config files?
Take a close look at the config files. A majority of them could
disappear tomorrow, that is, the ones that only contain a "usb 0xVVVV
0xPPPP" line, or the ones that contain options that could perfectly be
handled through the frontend. This applies to most of the USB
backends.
Post by Johannes Meixner
I think it is up to the author of a backend whether or
not he likes to have everything hardcoded in the backend
or have settings in a config file.
It's up to the SANE standard to define the use cases for a config
file, then it's up to the backend authors to follow the standard. As
the backend authors are also the ones elaborating the standard, a
convenient solution should arise ;)
Post by Johannes Meixner
Users do not want config tools. They want to use their scanner,
and that's it.
I have heared this kind of "the hardware must simply work"
wishes many many times since years and since years there is
a lot of step by step progress but since years there is no
general solution to set up hardware without user interaction.
It could have worked with USB, but vendors fucked up the
implementations once again, so ... next time maybe.
Post by Johannes Meixner
Please let us be constructive and proceed step by step
instead of wishes which may be implemented in some years.
I think it is constructive to say that some of the existing config
files are of no use today, and could be removed without any problem.
Post by Johannes Meixner
Now, if only our beloved vendors could stop their firmware
crazyness...
Perhaps you are more successful than I to teach the hardware
manufacturers how they should make their devices for those
customers who simply buy the cheapest one.
Unfortunately, no.
Post by Johannes Meixner
In fact there would be nothing bad with firmware upload
if the manufacturers provided backends which have the
firmware included (or as external files) and the backend
cares for the firmware upload
or if the manufacturers permit free distribution and
re-distribution of the firmware files so that the firmware
files could be included in the sane-backends or in a special
package of the distributors (if firmware files without source
code cannot be included in sane-backends).
Alternatively, they could avoid hiding the said firmware into a
windows installer or inside a dll ...

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Johannes Meixner
2005-02-24 15:34:47 UTC
Permalink
Hello,
Post by Julien BLACHE
I think it is constructive to say that some of the existing config
files are of no use today, and could be removed without any problem.
Of course!
I fully agree to get rid of stuff which is in fact not needed.

Nevertheless:
For the remaining backends which still need config files
it would be good to have a common config file syntax which
supports to change them in a safe way by software tools.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Julien BLACHE
2005-02-24 16:25:00 UTC
Permalink
Post by Johannes Meixner
Post by Julien BLACHE
I think it is constructive to say that some of the existing config
files are of no use today, and could be removed without any problem.
Of course!
I fully agree to get rid of stuff which is in fact not needed.
For the remaining backends which still need config files
it would be good to have a common config file syntax which
supports to change them in a safe way by software tools.
Sure, but let's keep something that's human-readable :) (XML or PPD
aren't human-readable ;)

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
m. allan noah
2005-02-24 16:34:22 UTC
Permalink
Post by Julien BLACHE
Post by Johannes Meixner
Post by Julien BLACHE
I think it is constructive to say that some of the existing config
files are of no use today, and could be removed without any problem.
Of course!
I fully agree to get rid of stuff which is in fact not needed.
For the remaining backends which still need config files
it would be good to have a common config file syntax which
supports to change them in a safe way by software tools.
Sure, but let's keep something that's human-readable :) (XML or PPD
aren't human-readable ;)
let me ask this: how many of the config files that must be kept are kept
because they have scanner-specific information in them, as opposed to
backend-specific information?

ie: how many times does a conf file say:

'for any scanners that use this backend, enable feature x"

v/s

'for this particular model of scanner, enable feature x'

v/s

'for this particular serial number, enable feature x'

the reason i ask is that it would seem, based on the name, that only the
first example really belongs in 'backend.conf', where the others belong in
a per-model or per-SN file?

allan
Post by Julien BLACHE
JB.
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Julien BLACHE
2005-02-24 17:49:27 UTC
Permalink
Post by m. allan noah
let me ask this: how many of the config files that must be kept are
kept because they have scanner-specific information in them, as
opposed to backend-specific information?
'for any scanners that use this backend, enable feature x"
v/s
'for this particular model of scanner, enable feature x'
v/s
'for this particular serial number, enable feature x'
the reason i ask is that it would seem, based on the name, that only
the first example really belongs in 'backend.conf', where the others
belong in a per-model or per-SN file?
Don't you think that at least item 1 and 2 can be detected by the
backend ? (the serial number might not be accessible by the backend,
sure). There's still the possibility that a vendor will slightly
modify the hardware and not anything else, making it impossible to
guess which version of the hardware we're talking to.

If we cannot get rid of the config files (there's some experience like
the same product ID applying to slightly different hardware), we can
at least have a look at them as they are now, see if there are options
that can be removed, and try to come up with a unified format.

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
m. allan noah
2005-02-24 18:38:14 UTC
Permalink
Post by Julien BLACHE
Post by m. allan noah
let me ask this: how many of the config files that must be kept are
kept because they have scanner-specific information in them, as
opposed to backend-specific information?
'for any scanners that use this backend, enable feature x"
v/s
'for this particular model of scanner, enable feature x'
v/s
'for this particular serial number, enable feature x'
the reason i ask is that it would seem, based on the name, that only
the first example really belongs in 'backend.conf', where the others
belong in a per-model or per-SN file?
Don't you think that at least item 1 and 2 can be detected by the
backend ?
yes for #1, no for #2 and #3. since some times the same 'model' is
actually 2 different pieces of hardware. but, i am not familiar with
every single backend, so i dont know how much this happens.

(the serial number might not be accessible by the backend,
Post by Julien BLACHE
sure).
if the serial number cant be gotten by the backend, then who can? the
backend should know how if it is possible at all.

There's still the possibility that a vendor will slightly
Post by Julien BLACHE
modify the hardware and not anything else, making it impossible to
guess which version of the hardware we're talking to.
right, which is why #2 above cant automatically be in the backend.
Post by Julien BLACHE
If we cannot get rid of the config files (there's some experience like
the same product ID applying to slightly different hardware), we can
at least have a look at them as they are now, see if there are options
that can be removed, and try to come up with a unified format.
agreed, though i believe that most users think in terms of the label on
the scanner not backends, so any config that is required might end up
being more scanner specific.

allan
Post by Julien BLACHE
JB.
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Julien BLACHE
2005-02-24 18:51:00 UTC
Permalink
Post by m. allan noah
Post by Julien BLACHE
Don't you think that at least item 1 and 2 can be detected by the
backend ?
yes for #1, no for #2 and #3. since some times the same 'model' is
actually 2 different pieces of hardware. but, i am not familiar with
every single backend, so i dont know how much this happens.
In this case, the product ID will differ between the 2 hardwares (if
they're totally different, at least), or we can hope so. (talking of
USB here, as for everything else there's really no means to guess)
Post by m. allan noah
(the serial number might not be accessible by the backend,
Post by Julien BLACHE
sure).
if the serial number cant be gotten by the backend, then who can? the
backend should know how if it is possible at all.
The user, with a pair of eyes :)
Post by m. allan noah
Post by Julien BLACHE
If we cannot get rid of the config files (there's some experience like
the same product ID applying to slightly different hardware), we can
at least have a look at them as they are now, see if there are options
that can be removed, and try to come up with a unified format.
agreed, though i believe that most users think in terms of the label
on the scanner not backends, so any config that is required might end
up being more scanner specific.
Yes. It's always confusing when an Epson scanner ends up being used
with the snapscan backend ;)

How about we ask the vendors to embbed the config file in the scanner ? :P

(and here, we can only realize that the whole scanning world is such a
mess, that we might never find a good solution to handle everything...)

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
m. allan noah
2005-02-24 22:55:04 UTC
Permalink
Post by Julien BLACHE
Post by m. allan noah
Post by Julien BLACHE
Don't you think that at least item 1 and 2 can be detected by the
backend ?
yes for #1, no for #2 and #3. since some times the same 'model' is
actually 2 different pieces of hardware. but, i am not familiar with
every single backend, so i dont know how much this happens.
In this case, the product ID will differ between the 2 hardwares (if
they're totally different, at least), or we can hope so. (talking of
USB here, as for everything else there's really no means to guess)
no, you hope for too much. there are cases where manuf. makes changes to
equipment capabilities (running changes) but does not update the PID.
perhaps this case cannot be helped, and perhaps Oliver is right, that the
backend will have to make options to disable these features.
Post by Julien BLACHE
Post by m. allan noah
(the serial number might not be accessible by the backend,
Post by Julien BLACHE
sure).
if the serial number cant be gotten by the backend, then who can? the
backend should know how if it is possible at all.
The user, with a pair of eyes :)
then the serial number is useless to the discussion. the only reason to
get it, is situations where there are multiple of the same scanner being
used on a machine, and each needs a slightly different calibration. if
per-scanner configs (gamma tables, etc) were stored by serial number this
would work, even when the scanner switches ports or from scsi to usb.

in order for this to work, the backend needs to be able to uniquely ID the
unit.
Post by Julien BLACHE
Post by m. allan noah
Post by Julien BLACHE
If we cannot get rid of the config files (there's some experience like
the same product ID applying to slightly different hardware), we can
at least have a look at them as they are now, see if there are options
that can be removed, and try to come up with a unified format.
agreed, though i believe that most users think in terms of the label
on the scanner not backends, so any config that is required might end
up being more scanner specific.
Yes. It's always confusing when an Epson scanner ends up being used
with the snapscan backend ;)
How about we ask the vendors to embbed the config file in the scanner ? :P
(and here, we can only realize that the whole scanning world is such a
mess, that we might never find a good solution to handle everything...)
agreed.

allan
Post by Julien BLACHE
JB.
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Julien BLACHE
2005-02-25 11:00:59 UTC
Permalink
Post by m. allan noah
Post by Julien BLACHE
In this case, the product ID will differ between the 2 hardwares (if
they're totally different, at least), or we can hope so. (talking of
USB here, as for everything else there's really no means to guess)
no, you hope for too much. there are cases where manuf. makes changes
I hope that, in this case, the changes aren't too significant, that's
all. I learned the hard way that there's nothing you can hope from
hardware vendors (although some obviously behave better than others).
Post by m. allan noah
to equipment capabilities (running changes) but does not update the
Hmm. There's a revision information along with the VID/PID which
basically covers this need. Is that usable in this situation ? (ie do
vendors care to update this one ?)
Post by m. allan noah
PID. perhaps this case cannot be helped, and perhaps Oliver is right,
that the backend will have to make options to disable these features.
Yep.
Post by m. allan noah
then the serial number is useless to the discussion. the only reason
to get it, is situations where there are multiple of the same scanner
being used on a machine, and each needs a slightly different
calibration. if per-scanner configs (gamma tables, etc) were stored by
serial number this would work, even when the scanner switches ports or
from scsi to usb.
in order for this to work, the backend needs to be able to uniquely ID
the unit.
This is needed too in cases where several identical scanners are
connected to the same host.

If only the USB spec made it mandatory to have a unique device
identifier :( [haven't read the spec for a long time now, but I don't
think something alike exists in the spec]

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Oliver Rauch
2005-02-24 19:06:40 UTC
Permalink
Post by Julien BLACHE
Post by m. allan noah
let me ask this: how many of the config files that must be kept are
kept because they have scanner-specific information in them, as
opposed to backend-specific information?
'for any scanners that use this backend, enable feature x"
v/s
'for this particular model of scanner, enable feature x'
v/s
'for this particular serial number, enable feature x'
the reason i ask is that it would seem, based on the name, that only
the first example really belongs in 'backend.conf', where the others
belong in a per-model or per-SN file?
Don't you think that at least item 1 and 2 can be detected by the
backend ? (the serial number might not be accessible by the backend,
sure). There's still the possibility that a vendor will slightly
modify the hardware and not anything else, making it impossible to
guess which version of the hardware we're talking to.
If we cannot get rid of the config files (there's some experience like
the same product ID applying to slightly different hardware), we can
at least have a look at them as they are now, see if there are options
that can be removed, and try to come up with a unified format.
When there are really some settings that need to be selected by the
user, why are these settings not implemented as a sane option, may be an
advanded sane option.

May be we need an additional flag to the existing ADVANCED flag, may be
a CONFIGURE flag. This way the backend would define what the user can
select and we already would have a configuration tool: the frontend.
The backend could save the last selected setting in its own
configuration file as a default option (although this also could be done
by the frontend).


Oliver
Johannes Meixner
2005-02-25 09:31:08 UTC
Permalink
Hello,
Post by Oliver Rauch
May be we need an additional flag to the existing ADVANCED flag, may be
a CONFIGURE flag. This way the backend would define what the user can
select and we already would have a configuration tool: the frontend.
The backend could save the last selected setting in its own
configuration file as a default option (although this also could be done
by the frontend).
This would be great!

Please have in mind that it must be possible to seperate configuring
from daily usage.
It would lead to chaos if many different (unexperienced) users
who may access the scanner for example via saned and net backend
can configure it as they like.

In particular it should be possible to request admin authentication
for configuring.
As an example have a look how printer configuration is done in CUPS:
Via 'lppasswd' root can permit any user to act as a CUPS admin
and in cupsd.conf admin authentication can be disabled at all.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
m. allan noah
2005-02-25 14:16:05 UTC
Permalink
the problem with this is that doing the config as non-root would mean the
backend would need elevated permissions in order to write its config out
into /etc/...

if the user is willing to run the front-end the first time as root, and
then the backend saves the config changes, that might be ok. otherwise the
user will have to re-config under each user account.

remember also that sane works on platforms that dont use unix account
setups...

allan
Post by Johannes Meixner
Hello,
Post by Oliver Rauch
May be we need an additional flag to the existing ADVANCED flag, may be
a CONFIGURE flag. This way the backend would define what the user can
select and we already would have a configuration tool: the frontend.
The backend could save the last selected setting in its own
configuration file as a default option (although this also could be done
by the frontend).
This would be great!
Please have in mind that it must be possible to seperate configuring
from daily usage.
It would lead to chaos if many different (unexperienced) users
who may access the scanner for example via saned and net backend
can configure it as they like.
In particular it should be possible to request admin authentication
for configuring.
Via 'lppasswd' root can permit any user to act as a CUPS admin
and in cupsd.conf admin authentication can be disabled at all.
Kind Regards
Johannes Meixner
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Johannes Meixner
2005-02-25 14:32:45 UTC
Permalink
Hello,
Post by m. allan noah
the problem with this is that doing the config as non-root would mean the
backend would need elevated permissions in order to write its config out into
/etc/...
if the user is willing to run the front-end the first time as root, and then
the backend saves the config changes, that might be ok. otherwise the user
will have to re-config under each user account.
Perhaps there was a misunderstanding.
I do not want that any user can do config stuff via the normal
SANE frontend - I want to avoid that this happens.
It is perfectly o.k. when config stuff requires root privileges
by default.

Perhaps it is simplest to let root define who is allowed to do
config stuff by setting the appropriate permissions for the
backend config file.

What happens when the backend runs as root (e.g. to access parallel
port scanners as normal user via a local running saned)?
Then a normal user would get write permission for the config file.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
m. allan noah
2005-02-25 14:52:34 UTC
Permalink
Post by Johannes Meixner
Hello,
Post by m. allan noah
the problem with this is that doing the config as non-root would mean the
backend would need elevated permissions in order to write its config out into
/etc/...
if the user is willing to run the front-end the first time as root, and then
the backend saves the config changes, that might be ok. otherwise the user
will have to re-config under each user account.
Perhaps there was a misunderstanding.
I do not want that any user can do config stuff via the normal
SANE frontend - I want to avoid that this happens.
It is perfectly o.k. when config stuff requires root privileges
by default.
Perhaps it is simplest to let root define who is allowed to do
config stuff by setting the appropriate permissions for the
backend config file.
i think we want to hide the config file concept from the user if possible,
rather than require someone to change the perms.

i personally am very much in favor of per-scanner config files anyway,
rather than per-backend, because if you do manage to solve the root
permissions issue, then you have an all-or-nothing situation. any user
that can change the backend config can change it for all scanners that use
that backend.
Post by Johannes Meixner
What happens when the backend runs as root (e.g. to access parallel
port scanners as normal user via a local running saned)?
Then a normal user would get write permission for the config file.
i would prefer that sane developed a way to send strong electrical shocks
via the parallel port and put such pitiful hardware out of its misery :)

but, since we cant do that, does it make sense (somehow) for the 'closest'
backend to be the one that saves the config? then the net backend, which
is presumably running as the local user, will not be able to write the
config, or if it does, just writes the config in his homedir?

i guess this is a bad idea cause it means that multiple network users of
the same scanner will have to config separately.

what about the way pine works? there are two config files, pine.conf
(which sets system defaults like from domain and mail servers) and
pine.conf.fixed, that are unmodifiable by user configs. both of these
files are just like a normal user's .pinerc

what if sane provided these config options for every user, and stored them
in .sane/ in their homedir. then the root user (or another tool suid)
copied one of these completed configs into /etc, and made it the system
default? i am not sure what happens in that case to any users that have
set their own configs, i guess the /etc configs are just the defaults?

allan
Post by Johannes Meixner
Kind Regards
Johannes Meixner
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Johannes Meixner
2005-02-25 16:39:07 UTC
Permalink
Hello,
Post by m. allan noah
i think we want to hide the config file concept from the user
if possible, rather than require someone to change the perms.
It is not required to change any permission.
The default that only root can write to <backend>.conf is
perfectly o.k. but when root likes, he can change the
permissions for <backend>.conf so that a group of normal users
or all normal users get write permission.

Oliver's proposal hides the file concept perfectly from the user
because the user uses only the frontend.
Post by m. allan noah
i personally am very much in favor of per-scanner config files
anyway, rather than per-backend,
According to Oliver's proposal it is the backend (and as far as I
understand it is only the backend) which writes into <backend>.conf.
So each backend can handle its config file(s) as the backend author
likes:
One backend may have the configs for several scanners in one
<backend>.conf and another backend may have <backend>.conf as
default and <backend>.<model1>.conf, <backend>.<model2>.conf, ...
Post by m. allan noah
what if sane provided these config options for every user, and
stored them in .sane/ in their homedir.
Please keep the different kind of "configs" seperated:

What I have in mind when I use the word "config" are settings which
should not be changed by a normal user during daily usage
but only by the admin during configuration of the scanner.
I.e. critical settings which must be set correctly because
otherwise the scanner would not work (e.g. firmware file location)
or may be damaged (e.g. maximum values of the scan area).

What you are talking about is to store user preferences.
A normal user likes to store often used sets of various parameters
under convenient names like "text", "color", "photo", ...
so that he can easily switch between them.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
m. allan noah
2005-02-25 17:12:49 UTC
Permalink
Post by Johannes Meixner
Hello,
Post by m. allan noah
i think we want to hide the config file concept from the user
if possible, rather than require someone to change the perms.
It is not required to change any permission.
The default that only root can write to <backend>.conf is
perfectly o.k. but when root likes, he can change the
permissions for <backend>.conf so that a group of normal users
or all normal users get write permission.
Oliver's proposal hides the file concept perfectly from the user
because the user uses only the frontend.
ok, then how does this address the network-based scanner, where the
backend is loaded by saned, which may be running as root or maybe not?
a user would have to go to the server machine, and login as root and do
the config. i suppose that is ok, but being able to run the config steps
from another box would be nice.
Post by Johannes Meixner
Post by m. allan noah
i personally am very much in favor of per-scanner config files
anyway, rather than per-backend,
According to Oliver's proposal it is the backend (and as far as I
understand it is only the backend) which writes into <backend>.conf.
So each backend can handle its config file(s) as the backend author
One backend may have the configs for several scanners in one
<backend>.conf and another backend may have <backend>.conf as
default and <backend>.<model1>.conf, <backend>.<model2>.conf, ...
yes, i guess if the front-end is our only means of interaction, and the
vendors are ok with no longer touching the config files, that might work.

the only problem i see with this is that some backends can do scsi and
usb, and need that set in the config file, before the backend will find
the scanner and present it to the front-end for configuration. so you have
a chicken and egg problem with the most basic config params.
Post by Johannes Meixner
Post by m. allan noah
what if sane provided these config options for every user, and
stored them in .sane/ in their homedir.
What I have in mind when I use the word "config" are settings which
should not be changed by a normal user during daily usage
but only by the admin during configuration of the scanner.
I.e. critical settings which must be set correctly because
otherwise the scanner would not work (e.g. firmware file location)
or may be damaged (e.g. maximum values of the scan area).
What you are talking about is to store user preferences.
A normal user likes to store often used sets of various parameters
under convenient names like "text", "color", "photo", ...
so that he can easily switch between them.
now you mean to tell me what i am talking about? :) no, i personally dont
have much problem with users being able to plug scanner into machine and
make it work without root permissions. and besides, i think some things
(default binary scanning threshold) may need to be set to a good default,
but the user should be able to override. the root user's config seems a
way to do this.

should you not be in bed at this hour? :)

allan
Post by Johannes Meixner
Kind Regards
Johannes Meixner
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Oliver Rauch
2005-02-25 18:34:38 UTC
Permalink
Post by m. allan noah
the only problem i see with this is that some backends can do scsi and
usb, and need that set in the config file, before the backend will find
the scanner and present it to the front-end for configuration. so you have
a chicken and egg problem with the most basic config params.
I think it should not be a problem for the backend to scan all supported
busses for the devices. It is not necessary that the backend needs to
know from the config file on which bus the devices is connected.

Oliver
Johannes Meixner
2005-02-28 09:23:31 UTC
Permalink
Hello,
... i personally dont have much problem with users being able
to plug scanner into machine and make it
work without root permissions ...
Admins don't like it when normal users can plug in whatever
hardware and make it work.
Admins want to be able to define what the normal users are
allowed to do and what not.

But it is perfect when - as Oliver said - there is a SANE admin
authentication in the frontend (like the CUPS admin authentication
for http://localhost:631/admin) and root can define who is a SANE admin
(by default it is only root but root can add any user to be a SANE admin).

I had this discussion regarding printers ("any user should be
able to plug in a printer and make it work"), a quote from a mail:
------------------------------------------------------------------------
See for example
http://www.cups.org/str.php?L790
what is possible (of course for all printing systems on all operating
systems) when any user can act as printing system administrator:

For all printing systems on all operating systems the printing system
administrator can copy any printout to any place he likes (e.g. send
it via mail to any external address or copy it to any external place).

To avoid misunderstandings:

If a person is the administrator of her/his workstation then
this person knows the root password and then this person is root
for her/his workstation and then this person can of course set up
the printing system on her/his workstation as she/he likes.

But if a workstation is administrated by someone else then
this "someone else person" is root for this workstation and
then the normal user of this workstation must not be permitted
by default to set up or change the printing system on this
workstation as she/he likes.
Of course the "someone else person" can permit the normal user
of this workstation to be a printing system administrator of
this workstation but this must not be permitted by default.
------------------------------------------------------------------------

You may say "for SANE there are no such problems".
But I think there are similar problems:
To "plug in a SCSI scanner and make it work" requires that a
SCSI kernel module is loaded - e.g. for the nice unstable SCSI
controller which comes with the scanner and which may lead to
unpredictable sudden system stops.
To set up some external backends special daemons must be
started (ptal for hpoj, hplip for hpaio) or non-free software
must be installed (for epkowa the Iscan software).
"Any user should be able to plug in a scanner and make it work"
requires sometimes additional stuff which leads to security or
license problems.
should you not be in bed at this hour? :)
I don't know which way Suse/Novell mails go nowadays
(perhaps from German via US to the final recipient
and perhaps the sent-time may be somehow wrong).
When I sent this mail it was late afternoon in German.


Kind Regards,
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
m. allan noah
2005-02-28 14:31:13 UTC
Permalink
Post by Johannes Meixner
... i personally dont have much problem with users being able
to plug scanner into machine and make it
work without root permissions ...
Admins don't like it when normal users can plug in whatever
hardware and make it work.
Admins want to be able to define what the normal users are
allowed to do and what not.
you should say 'the average admin', because i for one (an abnormal admin)
dont care.
Post by Johannes Meixner
But it is perfect when - as Oliver said - there is a SANE admin
authentication in the frontend (like the CUPS admin authentication
for http://localhost:631/admin) and root can define who is a SANE admin
(by default it is only root but root can add any user to be a SANE admin).
i dont see much way to make this happen, sane does not really have the
infrastructure of CUPS, since no daemon is required to be running in sane.

perhaps a system like pam could be exploited?

allan
gazel joel
2005-02-27 12:07:09 UTC
Permalink
Post by Johannes Meixner
Hello,
Post by m. allan noah
i think we want to hide the config file concept from the user
if possible, rather than require someone to change the perms.
It is not required to change any permission.
The default that only root can write to <backend>.conf is
perfectly o.k. but when root likes, he can change the
permissions for <backend>.conf so that a group of normal users
or all normal users get write permission.
Oliver's proposal hides the file concept perfectly from the user
because the user uses only the frontend.
Post by m. allan noah
i personally am very much in favor of per-scanner config files
anyway, rather than per-backend,
According to Oliver's proposal it is the backend (and as far as I
understand it is only the backend) which writes into <backend>.conf.
So each backend can handle its config file(s) as the backend author
One backend may have the configs for several scanners in one
<backend>.conf and another backend may have <backend>.conf as
default and <backend>.<model1>.conf, <backend>.<model2>.conf, ...
Post by m. allan noah
what if sane provided these config options for every user, and
stored them in .sane/ in their homedir.
What I have in mind when I use the word "config" are settings which
should not be changed by a normal user during daily usage
but only by the admin during configuration of the scanner.
I.e. critical settings which must be set correctly because
otherwise the scanner would not work (e.g. firmware file location)
or may be damaged (e.g. maximum values of the scan area).
What you are talking about is to store user preferences.
A normal user likes to store often used sets of various parameters
under convenient names like "text", "color", "photo", ...
so that he can easily switch between them.
Kind Regards
Johannes Meixner
--
90409 Nuernberg, Germany WWW: http://www.suse.de/
Johannes Meixner
2005-02-25 09:58:58 UTC
Permalink
Hello,
Post by Julien BLACHE
Post by Johannes Meixner
For the remaining backends which still need config files
it would be good to have a common config file syntax which
supports to change them in a safe way by software tools.
Sure, but let's keep something that's human-readable :) (XML or PPD
aren't human-readable ;)
Julien,
I don't understand what you want.

As far as I understand you:
On the one hand
you said that users don't want to bother with config tools
and then I assume you even more want that users should't need
to bother with reading man pages and editing config files manually.
On the other hand
it seems you do not want computer read/writeable config file formats.

Don't you see that the real reason for all the discussion is
how to make the setup more user friendly even for those scanners
which need special settings (i.e. which don't work with the default
built-in settings of the backend)?

One approach is to have a special user setup frontend (a setup tool)
and such a tool requires computer read/writeable config file formats.

Even what Oliver Rauch proposed with the "CONFIGURE flag"
includes a computer read/writeable config data format.
I like Oliver's proposal very much because it doesn't require
a special user setup frontend.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Julien BLACHE
2005-02-25 11:28:18 UTC
Permalink
Post by Johannes Meixner
On the one hand
you said that users don't want to bother with config tools
and then I assume you even more want that users should't need
to bother with reading man pages and editing config files manually.
On the other hand
it seems you do not want computer read/writeable config file formats.
A config file should be human-readable, otherwise it's not a config
file. Because a non human-readable format would be easier to deal with
at the code level isn't a good enough argument.

For our needs, both XML and PPD are more than over-engineered
solutions, and would probably require more support code, which means
more bugs, etc. It also means someone must maintain that code.

Remember that SANE stands for Scanner Access Now Easy, and think about
what happened to SMTP and SNMP for instance, which aren't simple
anymore.
Post by Johannes Meixner
Don't you see that the real reason for all the discussion is
how to make the setup more user friendly even for those scanners
which need special settings (i.e. which don't work with the default
built-in settings of the backend)?
And we can perfectly do that without resorting to a special config
tool, without introducing XML or PPD config files.
Post by Johannes Meixner
One approach is to have a special user setup frontend (a setup tool)
and such a tool requires computer read/writeable config file formats.
Another approach would be to introduce the notion of scanner profile
in the backends, which would become an option settable in the
frontend.
Post by Johannes Meixner
Even what Oliver Rauch proposed with the "CONFIGURE flag"
includes a computer read/writeable config data format.
I like Oliver's proposal very much because it doesn't require
a special user setup frontend.
Yep.


I am getting seriously tired of the current tendency to introduce
configuration wizards, panels, control centers and the like, when
nothing of the sort is really needed. This is not Windows, everybody
please wake up.

And I tend to get angry at that shit when the use of the said wizard
is made mandatory by the use of a non human-readable configuration
file.

Hope you'll get my point a bit better now.

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Johannes Meixner
2005-02-24 14:00:40 UTC
Permalink
Hello,
Post by Gerhard Jaeger
the intention was, that sane should work out of the box, BUT in fact it
doesn't anymore. We really have too much different config-entries, which
need to be tweaked.
I am sure it will become worse.
The more popular Linux becomes the more external backends will come up.
In particular scanner (and printer) manufacturers normally insist
on their own way:
- HP has free open source backensd (hpoj, hpaio) but introduced nice
daemons (ptal, hplip) which must run, otherwise the scanner is not
accessible and they introduced a nice new frontend 'toobox' for
the device management functions.
- Epson Kowa introduced nice proprietary binary-only i386-only parts
for their 'epkowa' backend and they introduced a nice new frontend
'iscan' to support special features for their devices.
- Another manufacturer of big and fat network-scanners is working
on a special non-SANE frontend to download scanned images from
the network-scanner and they think about to make a SANE backend
but I assume their big and fat network-scanners have some special
features which require special software.
- ...

Of course you (i.e. the SANE authors) can say "we don't want to care
about the manufacturers and their weird stuff" - don't misunderstand
me - I do not complain - you can really say this.

But we (i.e. the distributors) - at least I - care about both:
SANE and the manufacturers.
Therefore we will implement any weird dirty workaround hack
to get as many devices as possible set up and running,
if there is no better way to do it.

As you can read from the previous mails there are differences
how differnt distributors set up scanners.

Till from Mandrake explained what Mandrake does.
The "Mandrake way" is to change <backend>.conf and I am sure,
Till can show you a good reason for each change.

I from Suse explained what we do:
The "Suse way" is not to change <backend>.conf and rely on the
defaults in <backend>.conf and the built-in automatisms of the
backends (I explained in a previous mail why I think this is
the rigth way).

The obvious result is that some scanners in some cases will work
out-of-the-box for Mandrake but not for Suse and vice versa.
Post by Gerhard Jaeger
The .conf file is territory of each backend maintainer
and thus there are no limits, which is confusing, as some backends work
without touching the .conf file others did not.
It is perfectly o.k. that the .conf file is territory of each backend
maintainer and that there are no limits.
This is not the reason of the problem.
The reason is that there is no defined syntax for .conf files so
that a setup tool can determine
- which options exist
- which values (choices) are possible for each option
- which value is the current setting (default)
- which settings exclude each other
- which options can be modified by the normal user
(in this case "normal user" means the user who sets up the scanner)
- which options can only be modified by the admin
(in this case "admin" means the backend maintainer or a really
experienced user)
Post by Gerhard Jaeger
I also agree, that introducing such stuff as PPD or XML might not be the
correct way, as I think its oversized
PPD syntax is not oversized.
PPD syntax fits perfectly - there may be even the need to enhance
the PPD syntax (e.g. allow arbitrary input for option values, but
if arbitrary option values is only needed for the "admin" then
there is no need to enhance the PPD syntax because the "admin"
can enter arbitrary option values manually into the PPD file).

I would like to show you examples for a .conf file in PPD syntax.
It is all about having a standardized _syntax_.
No existing option and no existing value must be changed.
All what must be changed is the syntax how it is specified
in the .conf file so that a software tool (which cannot read
Post by Gerhard Jaeger
- install SANE
- ask what is supported
- show the available options
- select what is wanted
- test if option values conflict, if yes go two steps back
- test if scanner works
Post by Gerhard Jaeger
- done
Assume there are two models connected, both need the 'acmefun'
backend, but both need different settings.

It is only meant as an example to show how PPD syntax can be used.
Don't care too much about the particular options and values.

ACME_FunScanner_Mono.ppd
---------------------------------------------------------------
*Manufacturer: "ACME"
*Product: "(acmefun)"
*ModelName: "ACME FunScanner Mono"
*ShortNickName: "ACME FunScanner Mono"
*NickName: "ACME FunScanner Mono (up to A4/Letter)"
*1284DeviceID: "MFG:acme;MODEL:funscanner gray"
*ColorDevice: False
*DefaultColorSpace: Gray
*LimitsImageableArea: "0 0 216 297"
*DefaultGrayGamma: "1.234"

*OpenUI *ImageableArea: PickOne
*DefaultImageableArea: A4
*ImageableArea A4/A4: "-l 0 -t 0 -x 210 -y 297"
*ImageableArea Letter/US Letter: "-l 0 -t 0 -x 216 -y 279"
*CloseUI: *ImageableArea
---------------------------------------------------------------

The limits for the imageable area must not be changed by the
normal user because it is hardware dependent.

The default for gamma should not be changed by the normal user
because the default is hardware dependent and if the user wants
another gamma setting, he should change it in his frontend.

The default imageable area can be changed by the normal user
to a reasonable default depending on the country where
the user lives.


ACME_FunScanner_Color_XL.ppd
---------------------------------------------------------------
*Manufacturer: "ACME"
*Product: "(acmefun)"
*ModelName: "ACME FunScanner Color"
*ShortNickName: "ACME FunScanner Color"
*NickName: "ACME FunScanner Color (up to A3/11x17)"
*1284DeviceID: "MFG:acme;MODEL:acme fun scanner CXL"
*ColorDevice: True
*DefaultColorSpace: RGB
*LimitsImageableArea: "0 0 307 442"
*DefaultRedGamma: "0.98"
*DefaultGreenGamma: "1.0"
*DefaultBlueGamma: "0.893"

*UIConstraints: *ADF True *ASF True
*UIConstraints: *ASF True *ADF True

*UIConstraints: *ASF False *ImageableArea Slide
*UIConstraints: *ImageableArea Slide *ASF False
*UIConstraints: *ASF True *ImageableArea A3
*UIConstraints: *ImageableArea A3 *ASF True
*UIConstraints: *ASF True *ImageableArea 11x17
*UIConstraints: *ImageableArea 11x17 *ASF True
*UIConstraints: *ASF True *ImageableArea A4
*UIConstraints: *ImageableArea A4 *ASF True
*UIConstraints: *ASF True *ImageableArea Letter
*UIConstraints: *ImageableArea Letter *ASF True

*UIConstraints: *ImageableArea A3 *Resolution 1200dpi
*UIConstraints: *Resolution 1200dpi *ImageableArea A3
*UIConstraints: *ImageableArea 11x17 *Resolution 1200dpi
*UIConstraints: *Resolution 1200dpi *ImageableArea 11x17

*OpenGroup: BasicSettings/Basic Settings

*OpenUI *ImageableArea/Imageable Area: PickOne
*DefaultImageableArea: A4
*ImageableArea A3/A3: "-l 10 -t 10 -x 297 -y 420"
*ImageableArea 11x17/11x17: "-l 10 -t 10 -x 279 -y 432"
*ImageableArea A4/A4: "-l 10 -t 10 -x 210 -y 297"
*ImageableArea Letter/US Letter: "-l 10 -t 10 -x 216 -y 279"
*ImageableArea Slide/For Slides Feeder: "-l 100 -t 100 -x 24 -y 18"
*CloseUI: *ImageableArea

*OpenUI *Resolution/Resolution: PickOne
*DefaultResolution: 150dpi
*Resolution 75dpi/750 dpi: "--resolution 75"
*Resolution 150dpi/150 dpi: "--resolution 150"
*Resolution 300dpi/300 dpi: "--resolution 300"
*Resolution 600dpi/600 dpi: "--resolution 600"
*Resolution 1200dpi/1200 dpi: "--resolution 1200"
*CloseUI: *Resolution

*CloseGroup: BasicSettings

*OpenGroup: InstallableOptions/Installed Options

*OpenUI *ADF/Automated Document Feeder: Boolean
*DefaultADF: False
*ADF False/Not Installed: ""
*ADF True/Installed: ""
*CloseUI *ADF

*OpenUI *ASF/Automated Slides Feeder: Boolean
*DefaultASF: False
*ASF False/Not Installed: ""
*ASF True/Installed: ""
*CloseUI *ASF

*CloseGroup: InstallableOptions

---------------------------------------------------------------

This more complicated example should show more possibilities
of PPD syntax:

Option groups can be used for a better user interface.
A simple user interface can ignore them.

This model has optional units which exclude each other.

When the special "Automated Slides Feeder" is mounted,
only one matching special imageable area makes sense.

The admin may have added constraints that 1200 dpi is not
possible for the big imageable areas to avoid images which
need too much memory.

Again: This is only an example.

Of course if the backend can autodetect everything, there is
no need for a config file.
But does it actually work that the backends can autodetect
everything for all scanners?


Kind Regards,
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Oliver Rauch
2005-02-23 19:33:43 UTC
Permalink
Hello.

I do not understand the discussion about the sane config file format.

In a usual/normal case the config file of a backend should not be
touched by a user or configuration program:
- We do not need to enter any device files because the sanei_* routines
search the devices and passes them to the backend.
- The position of a firmware file should be defined by a rule like a
path prefix and the backend an device name, e.g.
/pathto_foo/sane/firmware/umax/astra1220u.firmware
- The backend knows what devices it does support. It is dangerous when
you tell the backend to handle an unknown device as an already known
device. You can break the scanner with a bad setup.
When someone contacts me because he things my backend could support his
scanner then I do some tests with his help and tell him what he can
change in the config file.

It is dangerous when a setup program or an unexperienced user is
changing the config file. For supported scanners it generally is not
necessary to change anything in the config file.

I suggest to discuss how we can make the sane-backends work without any
config file changes. The first versions of SANE did work out of the box
for supported devices. There is no need for tweaking config files.

We have to define how a backend can find a firmware file and how a setup
program does now where to put a firmware version. There is no need to
change any config files for this reason.

Oliver
Oliver Rauch
2005-02-23 19:38:54 UTC
Permalink
Hello.

I do not understand the discussion about the sane config file format.

In a usual/normal case the config file of a backend should not be
touched by a user or configuration program:
- We do not need to enter any device files because the sanei_* routines
search the devices and passes them to the backend.
- The position of a firmware file should be defined by a rule like a
path prefix and the backend an device name, e.g.
/pathto_foo/sane/firmware/umax/astra1220u.firmware
- The backend knows what devices it does support. It is dangerous when
you tell the backend to handle an unknown device as an already known
device. You can break the scanner with a bad setup.
When someone contacts me because he things my backend could support his
scanner then I do some tests with his help and tell him what he can
change in the config file.

It is dangerous when a setup program or an unexperienced user is
changing the config file. For supported scanners it generally is not
necessary to change anything in the config file.

I suggest to discuss how we can make the sane-backends work without any
config file changes. The first versions of SANE did work out of the box
for supported devices. There is no need for tweaking config files.

We have to define how a backend can find a firmware file and how a setup
program does now where to put a firmware version. There is no need to
change any config files for this reason.

Oliver
Oliver Rauch
2005-02-23 19:36:44 UTC
Permalink
Hello.

I do not understand the discussion about the sane config file format.

In a usual/normal case the config file of a backend should not be
touched by a user or configuration program:
- We do not need to enter any device files because the sanei_* routines
search the devices and passes them to the backend.
- The position of a firmware file should be defined by a rule like a
path prefix and the backend an device name, e.g.
/pathto_foo/sane/firmware/umax/astra1220u.firmware
- The backend knows what devices it does support. It is dangerous when
you tell the backend to handle an unknown device as an already known
device. You can break the scanner with a bad setup.
When someone contacts me because he things my backend could support his
scanner then I do some tests with his help and tell him what he can
change in the config file.

It is dangerous when a setup program or an unexperienced user is
changing the config file. For supported scanners it generally is not
necessary to change anything in the config file.

I suggest to discuss how we can make the sane-backends work without any
config file changes. The first versions of SANE did work out of the box
for supported devices. There is no need for tweaking config files.

We have to define how a backend can find a firmware file and how a setup
program does now where to put a firmware version. There is no need to
change any config files for this reason.

Oliver
Sergey Vlasov
2005-02-23 20:35:24 UTC
Permalink
Post by Oliver Rauch
It is dangerous when a setup program or an unexperienced user is
changing the config file. For supported scanners it generally is not
necessary to change anything in the config file.
I suggest to discuss how we can make the sane-backends work without any
config file changes. The first versions of SANE did work out of the box
for supported devices. There is no need for tweaking config files.
Unfortunately there are stupid devices out there. Look at the "usb
0x05d8 0x4002" entry in gt68xx.conf for example - there are lots of
different scanners with the same USB ID, and most of them need
explicit overrides ("vendor" and "model" are just cosmetic, but
"override" and "firmware" lines really change things). In this case
the config tool would need to get the real scanner model from the user
and modify the config file appropriately.
Oliver Rauch
2005-02-24 18:40:33 UTC
Permalink
Hello.

I think there will be a possibility that the backend finds out what
scanner model talks to in almost all cases. Of course it is hard work to
find out what registers behave different to identify the models. But I
am pretty sure that in most cases it is possible for the backend to
identify the devices. And this will be much better than a XML config
file.

When it is not possible for the backend to find out the exact device it
could try the known devices to find out what model it is and store the
result in an own file (or put it into an advanced sane option that is
stored by the frontend in the devices preferences file), so it knows
next time what device it should test at first.

And for the cases it really is necessary to tweak any config files I
think it is more important to define and create a SANE-package internal
configuration program than to define how the config files look like.

Oliver
Post by Sergey Vlasov
Post by Oliver Rauch
It is dangerous when a setup program or an unexperienced user is
changing the config file. For supported scanners it generally is not
necessary to change anything in the config file.
I suggest to discuss how we can make the sane-backends work without any
config file changes. The first versions of SANE did work out of the box
for supported devices. There is no need for tweaking config files.
Unfortunately there are stupid devices out there. Look at the "usb
0x05d8 0x4002" entry in gt68xx.conf for example - there are lots of
different scanners with the same USB ID, and most of them need
explicit overrides ("vendor" and "model" are just cosmetic, but
"override" and "firmware" lines really change things). In this case
the config tool would need to get the real scanner model from the user
and modify the config file appropriately.
m. allan noah
2005-02-24 19:00:57 UTC
Permalink
Post by Oliver Rauch
Hello.
I think there will be a possibility that the backend finds out what
scanner model talks to in almost all cases. Of course it is hard work to
find out what registers behave different to identify the models. But I
am pretty sure that in most cases it is possible for the backend to
identify the devices. And this will be much better than a XML config
file.
When it is not possible for the backend to find out the exact device it
could try the known devices to find out what model it is and store the
result in an own file (or put it into an advanced sane option that is
stored by the frontend in the devices preferences file), so it knows
next time what device it should test at first.
but what about when it CANNOT find out this way? how can the backend
describe to a config tool that it needs some information? can the .desc
file for the backend tell the config tool which scanners it supports, as
well as which ones require user input?
Post by Oliver Rauch
And for the cases it really is necessary to tweak any config files I
think it is more important to define and create a SANE-package internal
configuration program than to define how the config files look like.
is that not the same thing?

allan
Post by Oliver Rauch
Oliver
Post by Sergey Vlasov
Post by Oliver Rauch
It is dangerous when a setup program or an unexperienced user is
changing the config file. For supported scanners it generally is not
necessary to change anything in the config file.
I suggest to discuss how we can make the sane-backends work without any
config file changes. The first versions of SANE did work out of the box
for supported devices. There is no need for tweaking config files.
Unfortunately there are stupid devices out there. Look at the "usb
0x05d8 0x4002" entry in gt68xx.conf for example - there are lots of
different scanners with the same USB ID, and most of them need
explicit overrides ("vendor" and "model" are just cosmetic, but
"override" and "firmware" lines really change things). In this case
the config tool would need to get the real scanner model from the user
and modify the config file appropriately.
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
Johannes Meixner
2005-02-22 17:21:41 UTC
Permalink
Hello,
Post by m. allan noah
Post by Johannes Meixner
At the moment it is simply ignored when particular models require
special settings in <backend>.conf
unfortunately, this can be difficult to deal with, since what
each model needs can vary drastically. cheaper models that require
firmware to be loaded come to mind, and some models do crazy things
like change usb ID or name after the firmware is loaded.
I forgot to mention that we do some guessing which models actually
require firmware upload and if yes we show a message to the user.
As we cannot distribute firmware it would not help to know
the syntax how to specify firmware upload in <backend>.conf
simply because we cannot provide the firmware.
I.e. in case of required firmware upload the user must set up
his device manually.

Firmware upload is a good example of missing information
in the *.desc files:

a)
As far as I know all scanners which use the backend gt68xx
and the related backend artec_eplus48u require a firmware upload,
I read "man sane-gt68xx" and "man sane-artec_eplus48u" and
http://www.meier-geinitz.de/sane/gt68xx-backend/
but I cannot be sure because there might be scanners
which use those backends but have built-in firmware.

b)
As far as I know all USB scanners (but not the SCSI scanners)
which use the backend snapscan require firmware upload according
to "man sane-snapscan" and http://snapscan.sourceforge.net/
but again I cannot be sure because there might be SCSI scanners
without built-in firmware or USB scanners with built-in firmware.

c)
There might be other scanners which require firmware upload
but when it is not mentioned in "man sane-<backend>" I would
miss such models.

If the location of the firmware on the manufacturer CD is fixed
and known then the location should be in the *.desc file
so that a config tool could get the firmware from there.

If the manufacturer provides firmware explicitely under a free
license for download then the URL should be in the *.desc file
so that a config tool could download the firmware.
Post by m. allan noah
ok, i have played with ppd only a little, but it does seem to work. the
problem comes with new scanners, or re-badged scanners. the current system of
loading every backend in turn, and letting them use a back-end specific way to
determine if they support the scanner gives us more flexibility than a ppd
file for each know model.
Of course.
At the moment the problem for a scanner config tool is that the
backends do their stuff somehow "secretly".
Therefore all a scanner config tool can do is to activate the
backend in dll.conf and hope for the best.
Post by m. allan noah
Post by Johannes Meixner
I would like when the manufacturers of such devices could make
SANE backends easily - i.e. the SANE frontend must support
to connect to a network-scanner (e.g. specify the IP address
and the port etc.).
you could write a sane backend that did this, but you would need
one for every different network transmission proto.
As the manufacturers of such devices should do it, it is perfectly
o.k. when each kind of network-scanner needs a matching backend.
It is the same as for the different kind of desktop scanners.

To set up many network-scanners in a business environment there
would be a scanner-server with a saned running and the user
workstations would only run the net meta-backend.

It is very similar to printing.
Even security (of saned) is not such a big problem.
When the users must have physical hardware access,
you must be in a trusted environment (internal network).


Kind Regards,
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: ***@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
Michal Jaegermann
2005-02-22 18:39:28 UTC
Permalink
Post by Gerhard Jaeger
Post by Michal Jaegermann
But does somebody at least have some idea how to read an infrared
channel?
the problem is our SANE 1 standard, which defines the image format.
We have currently only the possibility to pass RGB data to a frontend.
Still coolscan2 driver somehow manages in that framework for years.
Yes, I understand that this is hacky (ab)use of Alpha channel but
the point is that one can retrieve an available information. xsane
has even some options to help with this.
Post by Gerhard Jaeger
The solution (whenever we can start) is SANE 2 where we have a more flexible
approach for transmitting image data to a frontend.
I am all for a better standard which would be a right fit for the
current technology and would allow to use it without strange
contortions. The problem is that I have seen in archives messages
from a year 2002 talking about SANE 2, and they were not likely the
earliest ones, so with the current pace this sounds like a really
long term project. In the meantime I have some scanners to use now.
This is somewhat discouraging.

I am glad that at least apparently I provoked some discussion. :-)
Post by Gerhard Jaeger
It might also be possible for a backend to read the infrared channel and to
perform i.e. the dust removal in the backend, but this functionality should
in general be part of a frontend.
I do not suggest now that dust removal should be folded into a
backend (or any other particular place). Still from what I
understand the prerequisite is that one has to get somehow out
of scanner relevant data. I am not above writing some code but
I am afraid that I have not a clue how to talk to a scanner to
convince it to send me that stuff. If such documentation exists
then I failed to find it in my Google searches.
Post by Gerhard Jaeger
VueScans' advantage or disadvantage here is, that you have a all-in-one
program (scanner-driver + image processor), this has never been the
approach of SANE...
I do not mind a stand-alone dust remover program. It looks that
with a bit of scripting one should be able to automate such tasks in
any case. Although some hooks in right places which would allow to
drop some external filters into a data stream would be really handy.
In a general picture these things look like details.

Thanks,
Michal
Loading...