[sane-devel] Sane API
pzz at apevzner.com
Fri Oct 23 13:17:43 BST 2020
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
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
> 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 (pzz at apevzner.com)
More information about the sane-devel