[sane-devel] SANE2 proposal

Henning Meier-Geinitz henning@meier-geinitz.de
Mon, 15 Apr 2002 19:35:23 +0200


Hi,

On Sun, Apr 14, 2002 at 05:51:21PM -0500, Frank Zago wrote:
> - section 4.2.7 (status type).
> 
> The panasonic scanners scan a whole page before giving it back to the
> scanner. ie they must be able to cache the page. However if a high
> resolution is used, the internal memory isn't enough, the scan rejects
> the scan command with an insufficient memory error. SANE1/2 does not
> have a error status for that. Returning SANE_STATUS_NO_MEM is
> misleading because it is not the backend which is out of memory. What
> about adding a SANE_STATUS_SCANNER_OOM?

I would just use SANE_STATUS_IO_ERROR or _INVAL. You must provide
information what such messages mean and how to avoid them in the
documentation anyway. At least I wouldn't easily understand why my
scanner woul go "out of memory".

> Or adding several reserved error code for use by the backend (with a
> corresponding sane_strstatus() function)?

If the message callback is added to the standard, this may be a use of
it. Print "Too little memory for this resolution/size. [OK]".


> - I'd like to have all the SANE functions (sane_init, sane_open, ...)
> declared in a structure. Only that structure would be exported. eg:
>   static ... sane_open(...)
>   static ... sane_init(...)
> 
> backend_desc backendname_desc {
> 
>   /* backend entry points */
>   sane_open,
>   sane_init,
>   ...
>   /* Backend info */
>   "backendname",
>   0,               /* backend capabilities */
>   6544,            /* backend version */
>   ...
>   /* Reserved fields */
>   NULL,
>   ...
>   0,
>   ...
> } backendname_desc;
> 
> Some of the info here are from the SANE_Device structure. I don't think
> they belong there.
> 
> I know that would be a big change.

Keep in mind that we have to pass such structures over middle ends
like dll and net/saned. That's a reason for the backend version in
SANE_Device. Otherwise you get always the information from the dll
backend, not the real backend.

> - the .desc format description should be added too, and expanded. I'd
>   like to see an fcc id field.

The problem with more fields is the width of the generated table. We
thought about some more fields for e.g. ADF but if we use yet another
column, the HTML page gets even wider.

We could move some of the information into special listings per
backend, and only add the most important things to the main list.

I don't think however, we should put the definition into the standard.
Backends distributed seperately don't need a .desc, it's just for
generating our HTML page.

I'm currently working on a program that handles the desc files more
flexibly and can e.g. sort by manufacturer. However, I don't know
emacs lisp so it will be in C and can take some more time.

I guess the result will look like this:

Manufacturer | Product | Device type | comment | backend | version | status | man page |

Bye,
  Henning