Hi Povilas,
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
uniformly.
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
Duplex" (canon_dr.c)
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
approach).
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
sane-airscan does.
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 ([email protected])
