Hi Andrea,
On 11/25/20 12:59 AM, Andrea Croci wrote:
1) I do agree that the backend should merely expose the native
capabilities of the hardware. However if you are having one backend for
a lot of similar, but not identical, machines, then it may be that some
of these machines do offer lineart scanning natively and others don't. I
think the backend that covers all these machines should offer the
superset of the hardware capabilities, instead of the subset, which
would reduce the whole machine family to the smallest set of features
offered.
I think, the problem comes from the fact, that SANE applications
(frontends) directly speaks with SANE hardware drivers (backends)
without any middleware layer between them.
Obviously, this is better not to implement emulation of missed (in
hardware) features in the drivers, to avoid code duplication and having
an assortment of independent, often incompatible implementations of the
similar features.
From another hand, implementing these features in applications is also
not a very good idea. xsane, which implements some image enhancement
features, like brightness/contrast/gamma correction, is a nice app, but
there are other popular scanning apps around, and duplication this code
around all of them is not wise, as it is not wise to duplicate this code
around hardware drivers.
User, of course, would prefer that these functions will be available on
all hardware and with any drivers.
I think, the best place to implement missed features is the sane-dll. It
is (almost always) present between apps and drivers and can do this work.
It also opens a way to seamlessly move from SANE 1.0 to SANE 2.0,
because sane-dll may provide the required translation layer.
--
Wishes, Alexander Pevzner (p...@apevzner.com)
