Number 2. like you say is not used widely or at all.
For the Bell+Howell backend the analogous option I've defined is:
--compression none|g3|g3-2d|g4 [none]
Sets the compression mode of the scanner. Determines the type of data
returned from the scanner. Values are:
none - uncompressed data
g3 - CCITT G3 1 dimension (MH)
g3-2d - CCITT G3 2 dimensions (MR, K=4)
g4 - CCITT G4 (MMR)
I think of this option as enabling a capability of the scanner that
happens to result in the transmission of different frametypes. I don't
think that we need to make this option well-known (aka. subject to
interpretation by a frontend) as long as its default value results in
the transmission of only required frametypes.
Likewise, the default value for the barcode related options are such
that barcode decoding is not done by default and therefore the _TEXT
frames will not be sent by default.
So it is only by the frontend or user choosing a non-default option
value that any of the optional frames will be sent. This abides by
our spoken agreement (since put in writing by Nick) that backends will
not send optional frametypes unless directed to do so.
I don't see the value of having the frontend "disable" the compression
option to avoid the possibility of letting the user shoot themselves
in the foot, by requesting a frametype that the frontend can't handle.
Good frontends will handle this case gracefully, possibly warning the
user, and the user can heed the warning and stop choosing the option(s)
that get them into trouble with that frontend. The backend should
clearly document options that will cause optional frametypes to be
sent.
If it were helpful, the backend could have a configuration option in its
.conf file to turn off all optional frametype behavior and it could choose
how to modify its options to achieve this "plain" behavior. This would
be trivial to implement, but would most likely go unused -- why would
an owner of a $16,000 scanner want to disable all it high-end features?
Anyway, I don't think that the user needs to be constrained. Nick's
language suggesting that "interactive frontends provide some sort
of warning to the user..." is right on the money.
> > In 4.5.4 Scan area options It might be nice to allow multiple scan
> > areas for devices that support multiple scan areas per page. I know
> > of a couple scanners that support such things.
> >
> > In addition, on scanners we build, each "window" of the page may have
> > a different format (i.e. JFIF for the color and gray, TIFF/G4 for the
> > bitonal) ant it would be nice to specify the frame type within the
> > scan area specification.
>
> Yes, not quite sure how we should do this... perhaps with
>
> tl-x[1] ... tl-x[8] and format[1] ... format[8]
>
> and the appropriate user-interface grouping (we can create Groups in
> SANE options and expect the interface to do something sensible)
>
> Then we also need a way to turn off windows we're not using.
I'll share with you what I've done for the B+H thus far. It's not
perfect, hence this section under LIMITATIONS in the man page!
It stays away from the tl-x[1] approach because that seems like trouble
for two reasons.
1-Array options seem to be represented as histograms in the gui and
not at all in the commandline clients.
2-the tl, and br options are well-known and having 8 different sets
of them is bound to cause issues with the front-ends.
Limited user control of section support
While the driver allows the specification of up to 8 user defined sec-
tions there is no way for the user to specify the operations to per-
form on those sections. For now, the backend will read the image data
for all defined sections and search for barcodes (if barcode searching
is enabled) in all defined sections. If a duplex scan is underway,
then the sections on the back page will be similarly processed. There
is no mechanism to specify a different compression type on a section
by section basis; the main page compression setting is used for all
sections.
I have an option --barcode-window (which could be better named --window
or --section) that is defined as follows:
--barcode-window <string> []
Specifies a series of rectangular windows to search for barcodes
within. Ordinarily barcodes are searched in the entire front page
image. You can specify a smaller window in which to conduct the
search with this option. Doing so can significantly speed up the
decoding process. Each window is specified in the following format
(units are in millimeters): (You can specify several windows separated
by commas)
<width>x<height>+<top-left-x>+<top-left-y>
For example, 76.2x25.4+50.8+0, identifies an area 3 inches wide and
1 inch high with a top left corner at the top of the page one inch
from the left hand edge of the page. If this option is not specified
the barcode search is conducted in the entire page.
Each section (scanning window) can be the source of an image, or a
barcode search and this can be on the front and/or back pages. Through
this one option you can define the rectangles (there can be up to 8
on this scanner) but currently there's no means to specify what data
to get from them.
I was thinking of adding function codes (front, back, frontbar, backbar)
and appending them after the geometry like this:
<width>x<height>+<top-left-x>+<top-left-y>:<functioncodes>
for example,
76.2x25.4+50.8+0:frontbar
or
76.2x25.4+50.8+0:front:back,25.4x25.4+50.8+0:backbar
While this probably looks real ugly, remember that many document scanning
operations scan a very small set of document types but in huge quantities.
You want the user to choose the document type from a list and all the ugly
parameters are hidden from them. So this stuff ends up being stored away
in a script somewhere once the document type is defined.
Of course, Stephen would have to add format function codes as well
(jfif, g4, etc) for his scanner(s)...
I like Oliver's suggestion regarding the "Add Selection" button. But
that would seem to be a GUI centered approach and I'm not sure how/if
it could translate to a command-line driven frontend.
Tom Martone
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com