Hello,
before any work can start on SANE 2, the current proposal has to be
completed.
The major change is the image data format. SANE 2 will be able to
handle new formats easily (which matches the current needs, especially
regarding ir
channel). There will be 2 major image format, one pixel oriented and the other
will give images as a mime attachment. There is also standard part for button
handling.
Here is a summary of the differences between SANE 1 and SANE 2 proposal
standards:
structures changes:
- the SANE_Device struct has more fields, giving contact information
about the devices in case of bug, and the ability to send device capability
flags
- the SANE_Parameters changes to suit the image format improvement. It
also gives new informations such as a proposed filename and X/Y dpi.
options changes:
- capability hidden and allways settable added
- more commonly used options are now part of the standard
SANE operations changes:
- sane_open has a SANE_Device ** parameter
- scanner's button handling
newtwork operation:
The Network Protocol chapter seems to lag behind the SANE 1 chapter,
and the SANE_NET_OPEN call needs to be updated to reflect sane_open evolution.
The current proposal is in good shape, and the change regarding
image format seems to suit the current need for new formats. Converting current
backends
to SANE2 doesn't seem that difficult.
But before starting, there are some things I'd like to see in the new
standard:
- the current code flow is
sane_init
sane_open
sane_start
sane_read
sane_cancel
sane_close
sane_exit
rather than calling sane_cancel at the end of scan, I'd like to
have a sane_end function. Leaving the use of sane_cancel for canceling the scan
like it allready does. This new function would do about the same, but code flow
would be cleaner and easier to understand:
sane_init
sane_open
sane_start
sane_read
sane_end
sane_close
sane_exit
- the proposed button handling would surely be better if we create
sane_lock_buttons(), sane_update_buttons() and sane_unlock() buttons, instead
of doing this with control options.
- we should also add something about panels. Would some control options
be enough, or do we also need some lock/update/unlock behavior ?
- there are some issues about backends configuration. In order to be
detected, some backends need their configuration files tweaked. I think that
having well-known configuration options would improve the situation and would
also let us have a common way of accessing configuration parameters across
backends.
- do we want to improve warmup handling ? Currently there is no
feedback when warming-up is going on, which is sometime confusing, we can have
the feeling that nothing is happening. Do we want a sane_warm_up() or a
SANE_STATUS_WARMING_UP would be enough ?
There are other points that I feel they could be improved, but could be
done as we develop SANE2:
- we need a sane type for scanner buttons. Either we rename the
SANE_TYPE_BUTTON to SANE_TYPE_SOFT_BUTTON and use SANE_TYPE_BUTTON for
physical buttons, or we create a SANE_TYPE_HARD_BUTTON. So that a frontend can
easily detect hardware buttons. There should be a list of well-known buttons
description to use when possible.
- a SANE_TYPE_PANEL would be handy
- since there are well-know options there should be well-known groups,
and the SANE_CAP of these options should also be given.
- a SANE_STATUS_LOCKED could be added to handle the case where the
hardware lock of a scanner has been left.
Regards,
Stef
