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"
