[sane-devel] Film holder control (and adf)

[Henning Meier-Geinitz]

Hi,

On Fri, Jan 25, 2002 at 11:52:23AM +0000, Jose Paulo Moitinho de Almeida wrote:
> They can, probably I am wrong when I speak about the api, but my concern is 
> that life may be easier if reasonable, common options are chosen before 
> implementation. Perhaps what I want is to propose new "well known options" or 
> a set of "reasonably well known options".
> 
> In 1.0.6 when trying to figure out what is implemented I found:
> 
> coolscan.c:  dev->sane.type = "slide scanner";
> canon.c:    dev->sane.type = "film scanner";
> 
> This is not critical, but if a frontend relies on these properties you know 
> what it costs to guess all the alternatives that where used.

That's right. Currently there is no well known type for film/slide scanners
so I think we can add this in the standard.

Are both names valid or should one of them be chosen? I mean: are
these only different names or is this different hardware? Can the
backend authors agree on one name?

> * Background:
> 
> Imagine a film scanner wich can accepts a film strip (eg 6 in a row), a 
> single slide, a slide holder (eg 4 in a row) or an aps cassete.
> 
> I never used a flatbed with an adf adapter, but I think that it is possible 
> to install/remove it without turning off the scanner, so the situation will 
> be similar.

That's not possible with Mustek ADFs but maybe with others. But it's
no problem to scan a single piece of paper by just lifting the ADF and
selecting "Flatbed" instead of "ADF" for option source.

> The frontend wants to allow the user to select which frame he/she wants to 
> scan, providing the relevant options that apply, but after initialization it 
> is possible to change the media, eg from a aps cassete to a film strip, so 
> that the initial information queried by the backend may become outdated.

So add a button-type option "Query scan-information from scanner" or
similar?

> * Finding the properties/current options
> 
> A new (common) option is created.
> 
> scanimage -query 
> 
> which will print
> 
>  My scanner:Number of images: 4
>  My scanner:Can move back: yes
>  My scanner:Current frame: 2
>  My scanner:....
> 
> The same effect can probably be obtained by repeating a call to 
> sane_control_option. But what confuses me is that while I can see current 
> frame as an option, number of images is  a property of the scanner that may 
> change without notification.

I don't understand this. Why should scanimage print this information?
Does it even need to know it? I think it's the job of the backend to
query all the information it needs from the scanner and adjust the
options accordingly. E.g. the backend could provide an option "move
forward" or a selecter for the frame.

The only thing that's really missing in the current sane standard is a
way to inform the frontend automatically that it should reload its
options. This is planned for SANE2. This means that a backend must
fork and constantly polls the hardware for changes.

> * Scanning
> 
> To do a scan the other options are used:
> 
> scanimage -next-frame
> scanimage -previous-frame
> scanimage -frame 3

That should be possible with current options. I don't know if it makes
sense for ADFs, however. At least for the Mustek scanners it's not
possible to select the number of the piece of paper to scan. The only
option is to scan the next one or to not use the ADF at all.

I'm not against adding new well known options. However, I'm not sure
if we can/should add options to saneopts.h now, because this means
that backends not included in the sane-backends distribution have to
use #ifdefs for these options.

However, for SANE2 new well known options can be added anyway. So you
can start defining these. See include/sane/saneopts.h for examples.

Bye,
  Henning