Hi Povilas,
On 10/23/20 1:13 PM, Povilas Kanapickas wrote:
May be in printer world it could work, because there are only one device
class, used by USB printers, and only 3 service types, used by DNS-SD to
advertise a printer, and these is no such thing as SCSI printer, but
scanner hardware is MUCH more chaotic.
Can't we just add an additional set of APIs for this use case in e.g.
SANE 1.1? The applications may dlsym these APIs if they want to be
backwards-compatible with SANE 1.0.
I think, requiring application to dlsym these APIs will significantly
increase entry barrier for applications writers. Also, if there are
multiple backends loaded (via sane-dll), how to know how to dlsym the
proper symbol.
It would be better to shift dlsyming into the sane-dll, to keep all
complexity in a single place.
We already have "x-resolution" and "y-resolution" options. X/Y
resolutions can be handled the same way the non-pecific "resulution"
option is handled right now. That is, application sets the preferred X
and Y resolutions and then must check what actual supported resolution
was selected by the backend by querying these options again.
In SANE these x/y-resolution options are independent, while real
scanners offer a discrete set of possible x/y combinations. For example,
my scanner offers 200x100, 200x200, 200x400, 300x300, 400x400 and 600x600.
In theory, setting one of these options may update constraints for
another option and return SANE_INFO_RELOAD_OPTIONS to tell application
to reload constraints. But xsane, for example, doesn't understand it
properly. Also, for application that wants to simple show a drop-down
list of possible resolutions it will be a lot of work to obtain content
of this list.
The current standard actually handles a lot of similar problems already.
For example, the capabilities scan modes of a scanner can differ
significantly: transparency scans may offer completely different
resolutions than regular scans, transparency infrared scans may offer
only gray color and the scan boundaries offered by all of the modes may
be different.
Yes, I only want to tell, that switching to the "raw" mode is the "big
change", like changing scan source, and it may affect a lot of other
options.
I agree that sane_get_parameters will return special values for "raw"
mode, but if application supports "raw" mode, then it will already have
special path for it which could handle sane_get_parameters in a special
way too.
I think, for the "raw" mode sane_get_parameters() should return
SANE_STATUS_INVAL or SANE_STATUS_UNSUPPORTED
--
Wishes, Alexander Pevzner ([email protected])
