[sane-standard] More device properties

[Étienne Bersac]

Hi,

> No, page width and length are parameters for the firmware of some
> ADF scanners telling the device the size of the documents.

Interesting. So this make sense to add "paper-width" and "paper-height"
option as Alan suggests.

> 	A----------------- max scan/paper size--------------+
> 	|                                                   |
> 	|                                                   |
> 	|     B-----------  paper size ---------------+     |
> 	|     |                                       |     |
> 	|     |                                       |     |
> 	|     |      +-- scan window --+              |     |
> 	|     |      |                 |              |     |
> 	|     |      |                 |              |     |
> 	|     |      |                 |              |     |
> 	|     |      |                 |              |     |
> 	|     |      +-----------------+              |     |
> 	|     |                                       |     |
> 	|     |                                       |     |
> 	|     +---------------------------------------+     |
> 	|                                                   |
> 	|                                                   |
> 	+---------------------------------------------------+

> Scanners that allow to set the paper size may set the scan window
> coordinates relative to point A (top left corner of the max scan
> size) or relative to point B (top left corner of the selected paper
> size).

Thanks. This clarify things a bit :).

> > frontend must know how the feeder is aligned.
> 
> Perhaps... well, this is probably useful, if you want to have a
> selection list with standard paper sizes (A4/A5...). But the
> frontend does _not_ need to care about the alignment, if the scanner
> allows to set the page width/length, and if it sets the scan window
> relative to the selected page size.

Absolutely. See GnomeScan 0.4. It ask user for paper size and
orientation, it then compute the right area, but currently, it assume
the document is centered in feeder, feeder centerd relative to head,
top-first-introduced, and without paper-size options. (This the case on
my HP OfficeJet 7100 series and HP OfficeJet 7300 series, but not the
OfficeJet G85).

For device that do not handle paper-size (HP ones seems to), we must
teach the frontend feeders infos in order to compute the right scan
window relative the max scan area.

> > ACK. However, some might allow ADF preview, we must support that. The
> > backend must teach the frontend if it can preview with ADF.
> 
> Ummm, I would rather suggest to support a more general way to set
> the scan window that is useful for every ADF scanner: Let the user
> make a test scan with one page; display this page in a preview
> window; allow to set page size (if possible/reasonable) and the scan
> window; let the user insert the test page back into the ADF; let him
> make again a test scan and so on.

That's just crazy. Users are just fed up to walk trough the room just to
relaunch a preview. (In my case, my HP is networked and my mother has to
walk from the living room to my bedroom in order to feed the scanner,
that's quite long, and running the there and back trip more than twice
just makes user crazy).

In ADF, we must as far as possible avoid preview. The ideal workflow is
put the paper (carefully aligned), push the button, teach the file
name/…, click "scan" and that's all. 


> > I think that this source usage is a confusion of two separate options.
> > That's a quirks common in various backend.
> 
> Maybe. Actually, I don't care that much about these details, as long
> as we have the same options in all affected backends. If one or the
> other way to specify the ADF mode does not fit the GUI concept of a
> frontend, it is easy to use other GUI elements than suggested by the
> backend's options and to "map" the values selected in the GUI to the
> options.

I know. A lot of GnomeScanBackend is about mapping variable string from
variable backend into enum. :). I don't mean that GUI concept must
influence SANE design, however, SANE must allow GUI to choose there own
concept.

See : fujitsu backend merge source and duplex option, but hpaio backend
not. So the frontend has to take care of backend specific option
handling. That's no the purpose of a backend. All backends must expose a
as far as possible uniform API. Only adding specific options for
specific features. See SANE 2 draft : source values are 
"Flatbed", "Transparancy Adapter" and "Automatic Document Feeder".
Nothing else.

> I was trying to figure out, how this "feed from the right side of
> scan area" device works, to which you obviously have access.
> 
> The "average" ADF scanner works this way, perhaps you can explain,
> where your scanner works differently: […]

I own an HP OfficeJet G85 all-in-one printer which introduce paper
left-side-first in the flatbed, scan the paper, then eject it and while
feeder is no empty. The paper is moved left-to-right. I agree this is
not the fastest way, and new HP all-in-one printers do not work like
that. However, such device exsists and we must support it.

> > According to this example, i don't really know if adf-duplex is usefull.
> 
> Why should it not be useful?

You're right. In fact, some backend has a duplex option (hpaio does). We
should add it to the well known option.

> Another viewpoint: If the scanner moves the paper "by default from
> left to right", i.e., for example an A4 size ADF scanner that moves
> the paper parallel to the short edge, shouldn't the backend simply
> set the X range to 0...297mm and the Y range to 0..210mm? 

This mean that the backend rotate the picture in order to follow the
scan area rotation. That's a wrong idea. Backend must not rotate, they
just get data from device and drop them to frontend through sane_read
().

> Well, as I understand it, both cases you describe boil down to these
> parameters and questions:
> 
> - alignment of the paper in the feeder: centered/corner 1/corner 2
>   (other possible alignments should be considered broken...)
> - "clever" support of the page width/length parameters by the
>   frontend, which must be aware of a possible shift of the origin of
>   the scan window coordinates to the top-left corner of the selected
>   page size
> - which information is missing for scanners that can move an A4 page
>   parallel to its short edge?

Yes. Adding a offset info for scanne that do not support paper-size.

So we should add to the standard :

 - paper-width (fixed mm)
 - paper-height (fixed mm)
or
 - adf-alignement (string) {centered, start, end}
 - adf-offset (fixed mm)
 - adf-side (string) {top,bottom,left,right}

Right ?

Thank for your very interesting comments :)

Étienne.
-- 
Verso l'Alto !
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.alioth.debian.org/pipermail/sane-standard/attachments/20070118/248b7853/attachment.pgp