[sane-devel] Are "scanimage" options sequence dependent?

[m. allan noah]

Some scanners do not have the same list of resolutions in flatbed and
ADF modes, so I would expect that selecting the resolution first could
cause that resolution to be ignored when you later switch source.
However, if the scanner in question supports 300 dpi in both flatbed
and ADF, i would call this a bug in the Pixma backend.

allan

On Tue, May 15, 2018 at 6:52 AM, Dr Rainer Woitok
<rainer.woitok at gmail.com> wrote:
> Jeff,
>
> On Tuesday, 2018-05-15 08:22:20 +0200, you wrote:
>
>> ...
>> If you are only using scanimage then you can only find the dependencies
>> out by trial and error, using the --help output for each different
>> combination of options. i.e. the output from:
>>
>> scanimage --depth=1 --mode=color --help
>>
>> in my example above is likely to be different from
>>
>> scanimage --mode=color --depth=1 --help
>
> You are right,  and thanks for this information.   This is what I dubbed
> the bug in "man/man1/scanimage1"  in my last mail: there should be a big
> hint that options already specified  might influence  what other options
> are still specifyable and how to find that out.
>
> But I still regard  this specific behaviour  a bug in either "scanimage"
> or the "pixma" backend.  There is absolutely nothing in that help output
> indicating that  "--resolution" must not be  specified before "--source"
> (and with respect to these two particular options there isn't any reason
> for such a restriction either):
>
> $ scanimage --device pixma:MX880_192.168.2.199 --format tiff --mode Color \
>             --resolution 300 --help > /tmp/help1
> $ scanimage --device pixma:MX880_192.168.2.199 --format tiff --mode Color \
>             --source Flatbed --help > /tmp/help2
> $ diff -du /tmp/help1 /tmp/help2
> --- /tmp/help1  2018-05-15 11:17:25.756748641 +0200
> +++ /tmp/help2  2018-05-15 11:17:51.657527337 +0200
> @@ -34,7 +34,7 @@
>
>  Options specific to device `pixma:MX880_192.168.2.199':
>    Scan mode:
> -    --resolution auto||75|150|300|600|1200|2400dpi [300]
> +    --resolution auto||75|150|300|600|1200|2400dpi [75]
>          Sets the resolution of the scanned image.
>      --mode auto|Color|Gray|Lineart [Color]
>          Selects the scan mode (e.g., lineart, monochrome, or color).
>
>> This is where a GUI like gscan2pdf is useful, as the options are
>> automatically reloaded when the backend requests it.
>
> You know that I know "gscan2pdf".   But its user interface  currently is
> not customizable enough for my purpose:
>
>   - I want to preprocess  my scans using  "empty-page" [1]  and "textde-
>     scew" [2],
>
>   - if at all  I want "unpaper" to only  improve the OCR process but not
>     to spoil my scan  (like the temporary black and white image "gscan2-
>     pdf" is using only for OCR-ing  without turning the scan itself into
>     black and white),
>
>   - and I do not want having to remember each time I switch between "ADF
>     single sided" and  "ADF double sided"  to also manually check or un-
>     check the box "Rotate Reverse Side by 180 degrees".
>
> I only use a limited set of options like colour vs grey, 300 dpi vs 600
> dpi, flatbed vs ADF simplex vs ADF duplex,  and this can more easily be
> controlled from the command line.
>
> Sincerely,
>   Rainer
>
> [1] https://exactcode.com/opensource/exactimage/
> [2] http://www.fmwconcepts.com/imagemagick/index.php
>
> --
> sane-devel mailing list: sane-devel at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>              to sane-devel-request at lists.alioth.debian.org



-- 
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"