[sane-devel] Canon PIXMA MX330 working, with -x auto and -y auto bug; data here

[m. allan noah]

In fact, the auto paper length detection of the epjitsu backend uses
0, though the fujitsu backend uses a separate --ald option. your
choice.

allan

On Sun, Dec 6, 2009 at 12:57 PM, m. allan noah <kitno455 at gmail.com> wrote:
> 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"
>



-- 
"The truth is an offense, but not a sin"