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

[Nicolas Martin]

Pixma devices do not autodetect paper size width, so I guess the best
way to use the -x option as auto is to omit it. In this case, the max
value for page width will be used. 

Nicolas

Le mardi 08 décembre 2009 à 15:43 -0500, m. allan noah a écrit :
> 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"
> >
> 
> 
>