sane config files [was [sane-devel] Infrared channel]]
Johannes Meixner
jsmeix@suse.de
Thu, 24 Feb 2005 15:00:40 +0100 (CET)
Hello,
On Feb 24 08:49 Gerhard Jaeger wrote (shortened):
> 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.
> 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)
> 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
and understand a man page) can work with it, see below:
I change it a bit:
> - 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
> - 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: jsmeix@suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/