[sane-devel] Sane API
pzz at apevzner.com
Fri Oct 23 14:43:31 BST 2020
On 10/23/20 1:29 PM, Povilas Kanapickas wrote:
> (I've copied this from another e-mail, sorry for duplication and being
> late to the party :-) )
Better late, that never. I've already responded there :-)
So here I will only comment topics, missed in your previous message.
>> For the following options we don't have enough discipline:
>> - SANE_NAME_SCAN_SOURCE. There is no common names for ADF simplex/ADF
>> duplex, ADF front/ADF back
> A string option for a scan source is much more flexible than e.g. an int
> and should be preserved. What we probably need is just document the
> commonly used values in the existing standard.
I don't object against string options, but these values should be used
Currently we have:
- "Flatbed"/"Transparency Adapter"/"Automatic Document Feeder" (umax.c)
- "Opaque/Normal"/"Transparency"/""AutoFeeder" (microtek.c)
- "Flatbed"/"ADF"/"TMA"/"Filmstrip"/"Slide" (microtek2.h)
- "Normal"/"Transparency"/"ADF Front"/"ADF Back"/"ADF Duplex" (avision.c)
- "Automatic Document Feeder"/"Manual Feed Tray" (bh.h)
- "Flatbed"/"ADF Front"/"ADF Back"/"Card Front"/"Card Back"/"Card
And much, much more.
Note, IPP-scan defines only "adf", "film-reader" and "platen" sources
(with separate control for simplex/duplex ADF), WSD defines "ADF",
"ADFDuplex", "Film" and "Platen" sources
Best place to define standard valies is the saneopts.h, but we need also
to do something with variety of variants, used by existent drivers.
>> sane_airscan_get_parameters() must be accurate immediately after return
>> from sane_start(). It is not always possible, unless sane_start() has to
>> wait until image is available (compare sane-escl and sane-airscan
> Agreed. This case is more difficult. We need a way to preserve both the
> old and new behavior in some way with a possibility for the scan
> application to request either on demand.
If actual image parameters are only available, when image arrives, as
with eSCL/WSD, either somebody must wait until image arrives, or driver
may promise to return an image according to the selected options, and
then adjust actually received image to the promised parameters, as
>> There is no possibility to request image in the device-specific "raw"
>> format. I.e., if I want PDF and device can return PDF, image still will
>> be repacked PDF->sane format->PDF.
> This can be implemented as a special "color" mode in existing standard.
> We would probably need an additional API for that.
These are orthogonal things. For example, my scanner in eSCL mode can
return Gray8 and RGB24, as JPEG or PDF, and also B&W1, but only as PDF.
Wishes, Alexander Pevzner (pzz at apevzner.com)
More information about the sane-devel