standard says: Backends must attach a unit of either pixels (SANE_UNIT_PIXEL) or millimeters (SANE_UNIT_MM) to these options. The unit of all four options must be identical.
I dont think 'auto' qualifies as either of those units. Try stating that 0 or -1 is auto. allan On Sun, Dec 6, 2009 at 8:45 AM, Nicolas Martin <nicolas0martin at gmail.com> wrote: > Le dimanche 06 d?cembre 2009 ? 10:50 +0100, Nicolas Martin a ?crit : >> - There's an error with scanimage/pixma backend when setting explicitly >> -x or -y options to "auto". This is the same for all pixma devices, so >> probably something the pixma backend rejects for now, and that needs to >> be checked. > > Just tried ?with another scanner (Canon N656U handled by the plustek > backend) and got the same message when setting scanimage -x option to > "auto" > > Looking more deeply at scanimage.c source code, I notice this: > > In main(): > > ... > ? ?case 'x': > ? ? ?window_val_user[0] = 1; > ? ? ?parse_vector (&window_option[0], optarg, &window_val[0], 1); > ? ? ?break; > > ? ?case 'y': > ? ? ?window_val_user[1] = 1; > ? ? ?parse_vector (&window_option[1], optarg, &window_val[1], 1); > ? ? ?break; > > ? ?case 'l': ? ? ? ? ? /* tl-x */ > ? ? ?process_backend_option (device, window[2], optarg); > ? ? ?break; > ... > > So here, (x, y) and (l, t) do not use obviously the same functions to be > processed. > > Then, looking in parse_vector(): > > ... > ? ? ?/* read value */ > ? ? ?str = parse_scalar (opt, str, &value); > ... > > and finally in parse_scalar(): > > v = strtol (str, &end, 10); > > if (str == end) > ?{ > ? ?fprintf (stderr, > ? ? ? "%s: option --%s: bad option value (rest of option: %s)\n", > ? ? ? prog_name, opt->name, str); > ? ?exit (1); > ?} > > > So if -x value is "auto", the strtol will fail, and trig the error > message: ?scanimage: option --x: bad option value (rest of option: auto) > > More evidence of that if I enter the scanimage command like this: > > $ scanimage --format pnm -x foo ?> output.pnm > scanimage: option --x: bad option value (rest of option: foo) > > In conclusion: the -x auto limitation seems to be due to scanimage. > > => And now the questions, before changing anything: > > - Is there any reason for that, should the -x auto and -y auto options > be valid ? > - Does this need to be fixed, or is it working as designed ? > - Should we process (x, y) values as (l, t) are processed ? > > All suggestions welcome. > > Nicolas > > > > -- > sane-devel mailing list: sane-devel at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > ? ? ? ? ? ? to sane-devel-request at lists.alioth.debian.org > -- "The truth is an offense, but not a sin"