kopia lustrzana https://gitlab.com/sane-project/website
199 wiersze
10 KiB
HTML
199 wiersze
10 KiB
HTML
<!-- received="Thu Aug 26 18:29:49 1999 PDT" -->
|
||
<!-- sent="Thu, 26 Aug 1999 20:47:39 -0400" -->
|
||
<!-- name="Tom Martone" -->
|
||
<!-- email="tom@martoneconsulting.com" -->
|
||
<!-- subject="Re: SANE V2" -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="SANE V2" -->
|
||
<title>sane-devel: Re: SANE V2</title>
|
||
<h1>Re: SANE V2</h1>
|
||
<b>Tom Martone</b> (<a href="mailto:tom@martoneconsulting.com"><i>tom@martoneconsulting.com</i></a>)<br>
|
||
<i>Thu, 26 Aug 1999 20:47:39 -0400</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#316">[ date ]</a><a href="index.html#316">[ thread ]</a><a href="subject.html#316">[ subject ]</a><a href="author.html#316">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0317.html">Petter Reinholdtsen: "Re: net problem"</a>
|
||
<li> <b>Previous message:</b> <a href="0315.html">Tom Martone: "Re: SANE V2"</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0296.html">Nick Lamb: "SANE V2"</a>
|
||
<!-- nextthread="start" -->
|
||
<li> <b>Next in thread:</b> <a href="0321.html">Oliver Rauch: "Re: SANE V2"</a>
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
Nick Lamb wrote:<br>
|
||
<i>> </i><br>
|
||
<i>> On Wed, 25 Aug 1999, Stephen Williams wrote:</i><br>
|
||
<i>> > --</i><br>
|
||
<i>> > In 3.2.2 Image Transmission you suggest that front ends provide some sort</i><br>
|
||
<i>> > of means of warning or constraining the user from requesting frame formats</i><br>
|
||
<i>> > that it does not support. I contend that this is not in general possible</i><br>
|
||
<i>> > unless optional frame types can be enabled by a well-known option.</i><br>
|
||
<i>> > Without a well-known option, the front end cannot know (in general)</i><br>
|
||
<i>> > how to constrain the backend.</i><br>
|
||
<i>> </i><br>
|
||
<i>> Yes, you may have noticed that the well-known options stuff hadn't changed</i><br>
|
||
<i>> in my draft -- it needs a lot of work, especially given the comment below</i><br>
|
||
<i>> </i><br>
|
||
<i>> There are two factors to concern ourselves about in controlling the data</i><br>
|
||
<i>> format of a scanner, we could combine them or leave them as separate</i><br>
|
||
<i>> options -- opinions about this are sought:</i><br>
|
||
<i>> </i><br>
|
||
<i>> 1. Type of data scanned (RGB, Grey, Lineart...)</i><br>
|
||
<i>> 2. Transmission format (interleaved RGB, JPEG, separate RGB, G32D)</i><br>
|
||
<i>> </i><br>
|
||
<i>> There are already a lot of backends offering a control for the type of</i><br>
|
||
<i>> scanning, but few (none?) control transmission format. The two are of</i><br>
|
||
<i>> course interelated, but SANE can handle this quite nicely as it is.</i><br>
|
||
Number 1. is Scan Mode and is in wide use:<br>
|
||
#define SANE_NAME_SCAN_MODE "mode"<br>
|
||
used in:<br>
|
||
abaton.c, agfafocus.c, apple.c, artec.c, canon.c, coolscan.c, epson.c,<br>
|
||
microtek.c, microtek2.c, mustek.c, pint.c, ricoh.c, sharp.c, snapscan.c,<br>
|
||
tamarack.c, umax.c<br>
|
||
<p>
|
||
Number 2. like you say is not used widely or at all.<br>
|
||
For the Bell+Howell backend the analogous option I've defined is:<br>
|
||
--compression none|g3|g3-2d|g4 [none]<br>
|
||
Sets the compression mode of the scanner. Determines the type of data<br>
|
||
returned from the scanner. Values are:<br>
|
||
none - uncompressed data<br>
|
||
g3 - CCITT G3 1 dimension (MH)<br>
|
||
g3-2d - CCITT G3 2 dimensions (MR, K=4)<br>
|
||
g4 - CCITT G4 (MMR)<br>
|
||
<p>
|
||
I think of this option as enabling a capability of the scanner that<br>
|
||
happens to result in the transmission of different frametypes. I don't<br>
|
||
think that we need to make this option well-known (aka. subject to <br>
|
||
interpretation by a frontend) as long as its default value results in<br>
|
||
the transmission of only required frametypes.<br>
|
||
<p>
|
||
Likewise, the default value for the barcode related options are such<br>
|
||
that barcode decoding is not done by default and therefore the _TEXT<br>
|
||
frames will not be sent by default. <br>
|
||
<p>
|
||
So it is only by the frontend or user choosing a non-default option<br>
|
||
value that any of the optional frames will be sent. This abides by<br>
|
||
our spoken agreement (since put in writing by Nick) that backends will<br>
|
||
not send optional frametypes unless directed to do so.<br>
|
||
<p>
|
||
I don't see the value of having the frontend "disable" the compression<br>
|
||
option to avoid the possibility of letting the user shoot themselves<br>
|
||
in the foot, by requesting a frametype that the frontend can't handle.<br>
|
||
Good frontends will handle this case gracefully, possibly warning the<br>
|
||
user, and the user can heed the warning and stop choosing the option(s)<br>
|
||
that get them into trouble with that frontend. The backend should <br>
|
||
clearly document options that will cause optional frametypes to be<br>
|
||
sent.<br>
|
||
<p>
|
||
If it were helpful, the backend could have a configuration option in its<br>
|
||
.conf file to turn off all optional frametype behavior and it could choose<br>
|
||
how to modify its options to achieve this "plain" behavior. This would<br>
|
||
be trivial to implement, but would most likely go unused -- why would<br>
|
||
an owner of a $16,000 scanner want to disable all it high-end features?<br>
|
||
<p>
|
||
Anyway, I don't think that the user needs to be constrained. Nick's<br>
|
||
language suggesting that "interactive frontends provide some sort<br>
|
||
of warning to the user..." is right on the money.<br>
|
||
<p>
|
||
<i>> > In 4.5.4 Scan area options It might be nice to allow multiple scan</i><br>
|
||
<i>> > areas for devices that support multiple scan areas per page. I know</i><br>
|
||
<i>> > of a couple scanners that support such things.</i><br>
|
||
<i>> ></i><br>
|
||
<i>> > In addition, on scanners we build, each "window" of the page may have</i><br>
|
||
<i>> > a different format (i.e. JFIF for the color and gray, TIFF/G4 for the</i><br>
|
||
<i>> > bitonal) ant it would be nice to specify the frame type within the</i><br>
|
||
<i>> > scan area specification.</i><br>
|
||
<i>> </i><br>
|
||
<i>> Yes, not quite sure how we should do this... perhaps with</i><br>
|
||
<i>> </i><br>
|
||
<i>> tl-x[1] ... tl-x[8] and format[1] ... format[8]</i><br>
|
||
<i>> </i><br>
|
||
<i>> and the appropriate user-interface grouping (we can create Groups in</i><br>
|
||
<i>> SANE options and expect the interface to do something sensible)</i><br>
|
||
<i>> </i><br>
|
||
<i>> Then we also need a way to turn off windows we're not using.</i><br>
|
||
I'll share with you what I've done for the B+H thus far. It's not<br>
|
||
perfect, hence this section under LIMITATIONS in the man page!<br>
|
||
It stays away from the tl-x[1] approach because that seems like trouble<br>
|
||
for two reasons.<br>
|
||
1-Array options seem to be represented as histograms in the gui and<br>
|
||
not at all in the commandline clients.<br>
|
||
2-the tl, and br options are well-known and having 8 different sets <br>
|
||
of them is bound to cause issues with the front-ends.<br>
|
||
<br>
|
||
Limited user control of section support<br>
|
||
While the driver allows the specification of up to 8 user defined sec-<br>
|
||
tions there is no way for the user to specify the operations to per-<br>
|
||
form on those sections. For now, the backend will read the image data<br>
|
||
for all defined sections and search for barcodes (if barcode searching<br>
|
||
is enabled) in all defined sections. If a duplex scan is underway,<br>
|
||
then the sections on the back page will be similarly processed. There<br>
|
||
is no mechanism to specify a different compression type on a section<br>
|
||
by section basis; the main page compression setting is used for all<br>
|
||
sections.<br>
|
||
<p>
|
||
I have an option --barcode-window (which could be better named --window<br>
|
||
or --section) that is defined as follows:<br>
|
||
<p>
|
||
--barcode-window <string> []<br>
|
||
Specifies a series of rectangular windows to search for barcodes<br>
|
||
within. Ordinarily barcodes are searched in the entire front page<br>
|
||
image. You can specify a smaller window in which to conduct the<br>
|
||
search with this option. Doing so can significantly speed up the<br>
|
||
decoding process. Each window is specified in the following format<br>
|
||
(units are in millimeters): (You can specify several windows separated<br>
|
||
by commas)<br>
|
||
<width>x<height>+<top-left-x>+<top-left-y><br>
|
||
For example, 76.2x25.4+50.8+0, identifies an area 3 inches wide and<br>
|
||
1 inch high with a top left corner at the top of the page one inch<br>
|
||
from the left hand edge of the page. If this option is not specified<br>
|
||
the barcode search is conducted in the entire page.<br>
|
||
<p>
|
||
Each section (scanning window) can be the source of an image, or a <br>
|
||
barcode search and this can be on the front and/or back pages. Through<br>
|
||
this one option you can define the rectangles (there can be up to 8<br>
|
||
on this scanner) but currently there's no means to specify what data<br>
|
||
to get from them.<br>
|
||
<p>
|
||
I was thinking of adding function codes (front, back, frontbar, backbar)<br>
|
||
and appending them after the geometry like this:<br>
|
||
<width>x<height>+<top-left-x>+<top-left-y>:<functioncodes><br>
|
||
<p>
|
||
for example,<br>
|
||
76.2x25.4+50.8+0:frontbar<br>
|
||
or <br>
|
||
76.2x25.4+50.8+0:front:back,25.4x25.4+50.8+0:backbar <br>
|
||
<p>
|
||
While this probably looks real ugly, remember that many document scanning<br>
|
||
operations scan a very small set of document types but in huge quantities.<br>
|
||
You want the user to choose the document type from a list and all the ugly<br>
|
||
parameters are hidden from them. So this stuff ends up being stored away<br>
|
||
in a script somewhere once the document type is defined.<br>
|
||
<p>
|
||
Of course, Stephen would have to add format function codes as well<br>
|
||
(jfif, g4, etc) for his scanner(s)...<br>
|
||
<p>
|
||
I like Oliver's suggestion regarding the "Add Selection" button. But <br>
|
||
that would seem to be a GUI centered approach and I'm not sure how/if<br>
|
||
it could translate to a command-line driven frontend.<br>
|
||
<p>
|
||
Tom Martone<br>
|
||
<p>
|
||
<pre>
|
||
--
|
||
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
||
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
||
</pre>
|
||
<!-- body="end" -->
|
||
<p>
|
||
<ul>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0317.html">Petter Reinholdtsen: "Re: net problem"</a>
|
||
<li> <b>Previous message:</b> <a href="0315.html">Tom Martone: "Re: SANE V2"</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0296.html">Nick Lamb: "SANE V2"</a>
|
||
<!-- nextthread="start" -->
|
||
<li> <b>Next in thread:</b> <a href="0321.html">Oliver Rauch: "Re: SANE V2"</a>
|
||
<!-- reply="end" -->
|
||
</ul>
|