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