[sane-devel] Sane API

[Alexander Pevzner]

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 (pzz at apevzner.com)