sane-project-website/old-archive/1999-08/0183.html

<!-- received="Sun Aug 15 17:19:25 1999 PDT" -->
<!-- sent="Sun, 15 Aug 1999 19:34:49 -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>Sun, 15 Aug 1999 19:34:49 -0400</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#183">[ date ]</a><a href="index.html#183">[ thread ]</a><a href="subject.html#183">[ subject ]</a><a href="author.html#183">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0184.html">Stephen Williams: "Re: SANE frames"</a>
<li> <b>Previous message:</b> <a href="0182.html">Nick Lamb: "Re: SANE V2"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Nick Lamb wrote:<br>
<i>&gt; </i><br>
<i>&gt; On Sun, 15 Aug 1999, Tom Martone wrote:</i><br>
<i>&gt; </i><br>
<i>&gt; &gt; I'd have to disagree with you on this on, Nick.  If you have a scanner</i><br>
<i>&gt; &gt; that has an integral barcode/patchcode decoding feature that works on the</i><br>
<i>&gt; &gt; surrently scanned image data in the firmware of the scanner, do we want to</i><br>
<i>&gt; &gt; use SANE just to get the image data?  Then do we get an OCR package to</i><br>
<i>&gt; &gt; decode in software, the barcodes out of the saved image data?  I've</i><br>
<i>&gt; &gt; observed that the scanner firmware does it more quickly and more reliably,</i><br>
<i>&gt; &gt; than an OCR approach and it does it at scan time rather than a separate</i><br>
<i>&gt; &gt; pass.</i><br>
<i>&gt; </i><br>
<i>&gt; Well, you make a very convincing argument, and you do have this hardware</i><br>
<i>&gt; sat in front of you, which I don't. I asked this before, but I can't</i><br>
<i>&gt; remember what exactly you said in response:</i><br>
<i>&gt; </i><br>
<i>&gt; Does it make sense to you (considering the TWAIN way of doing it among</i><br>
<i>&gt; other things) for us to provide the results of a stuff like barcode</i><br>
<i>&gt; scans in a SANE Option (just like you can specify the R/G/B exposures</i><br>
<i>&gt; used by an auto-calibrating slide scanner) OR more like the existing</i><br>
<i>&gt; image transfer frames, only with text in?</i><br>
<i>&gt; </i><br>
<i>&gt; Initially I thought that using SANE Options was a nicer way, because you</i><br>
<i>&gt; can have something like this (I might be bending SANE's rules here a</i><br>
<i>&gt; little bit, but I think it works today, in theory)</i><br>
<i>&gt; </i><br>
<i>&gt; SANE Option "Barcodes", hardware feature, not user alterable, string</i><br>
<i>&gt; constraint { "9 780201 835953", "3 057640 136993", "MULTIM-44-2731" }</i><br>
I didn't respond in detail, other than to say that it was an interesting<br>
suggestion and thanks; I needed to think it through a bit more.  <br>
<p>
The option approach would certainly work and would avoid having to <br>
parse through the text file, which would be nice.  It still requires a<br>
cooperating frontend, knowledgeable about the special properties of the <br>
Barcodes option.  Then you'd have to do something with the data, which <br>
might be done outside the scanning application and you'd end up writing <br>
it out somewhere for further processing.  <br>
<p>
The other thing that was concerning me was all this extra information<br>
about the barcode that's available from the scanner.  Stuff like the<br>
barcode type, coordinates where it was found, time to find it, etc.<br>
I felt a bit uncomfortable throwing that away and it would be hard to<br>
send it all through options.  So what I'm currently doing it encoding<br>
all this in a XML tagged format and spitting it all out to a file.<br>
This doesn't solve the application's parsing chore (it makes it harder,<br>
I guess) but all of the available info is passed along in case it is<br>
ever useful  (e.g. the application will only accept a barcode in a certain<br>
region, of a certain type).  The search time is sort of useful when you're<br>
trying to get the barcode-timeout setting right for a batch of documents.<br>
That, of course, could be output as debug-trace info instead, I guess.<br>
<p>
Here's an example of the stuff the bh backend writes:<br>
<p>
&lt;xml-stream&gt;<br>
&lt;barcode&gt;<br>
 &lt;window-id&gt;0xa0&lt;/window-id&gt;&lt;type&gt;12&lt;/type&gt;<br>
 &lt;status-flag&gt;0x01&lt;/status-flag&gt;<br>
 &lt;orientation&gt;0x01&lt;/orientation&gt;<br>
 &lt;location&gt;&lt;tl&gt;&lt;x&gt;1120&lt;/x&gt;&lt;y&gt;304&lt;/y&gt;&lt;/tl&gt;<br>
 &lt;tr&gt;&lt;x&gt;1120&lt;/x&gt;&lt;y&gt;256&lt;/y&gt;&lt;/tr&gt;<br>
 &lt;bl&gt;&lt;x&gt;1520&lt;/x&gt;&lt;y&gt;304&lt;/y&gt;&lt;/bl&gt;<br>
 &lt;br&gt;&lt;x&gt;1520&lt;/x&gt;&lt;y&gt;256&lt;/y&gt;&lt;/br&gt;&lt;/location&gt;<br>
 &lt;search-time&gt;37&lt;/search-time&gt;&lt;length&gt;7&lt;/length&gt;<br>
 &lt;data&gt;046300M&lt;/data&gt;<br>
&lt;/barcode&gt;<br>
&lt;barcode&gt;<br>
 &lt;window-id&gt;0xa0&lt;/window-id&gt;&lt;type&gt;12&lt;/type&gt;<br>
 &lt;status-flag&gt;0x01&lt;/status-flag&gt;<br>
 &lt;orientation&gt;0x01&lt;/orientation&gt;<br>
 &lt;location&gt;&lt;tl&gt;&lt;x&gt;1104&lt;/x&gt;&lt;y&gt;304&lt;/y&gt;&lt;/tl&gt;<br>
 &lt;tr&gt;&lt;x&gt;1104&lt;/x&gt;&lt;y&gt;272&lt;/y&gt;&lt;/tr&gt;<br>
 &lt;bl&gt;&lt;x&gt;1504&lt;/x&gt;&lt;y&gt;304&lt;/y&gt;&lt;/bl&gt;<br>
 &lt;br&gt;&lt;x&gt;1504&lt;/x&gt;&lt;y&gt;256&lt;/y&gt;&lt;/br&gt;&lt;/location&gt;<br>
 &lt;search-time&gt;24&lt;/search-time&gt;&lt;length&gt;7&lt;/length&gt;<br>
 &lt;data&gt;034443M&lt;/data&gt;<br>
&lt;/barcode&gt;<br>
&lt;barcode&gt;<br>
 &lt;window-id&gt;0xa0&lt;/window-id&gt;&lt;type&gt;12&lt;/type&gt;<br>
 &lt;status-flag&gt;0x01&lt;/status-flag&gt;<br>
 &lt;orientation&gt;0x01&lt;/orientation&gt;<br>
 &lt;location&gt;&lt;tl&gt;&lt;x&gt;1120&lt;/x&gt;&lt;y&gt;304&lt;/y&gt;&lt;/tl&gt;<br>
 &lt;tr&gt;&lt;x&gt;1120&lt;/x&gt;&lt;y&gt;256&lt;/y&gt;&lt;/tr&gt;<br>
 &lt;bl&gt;&lt;x&gt;1504&lt;/x&gt;&lt;y&gt;304&lt;/y&gt;&lt;/bl&gt;<br>
 &lt;br&gt;&lt;x&gt;1504&lt;/x&gt;&lt;y&gt;256&lt;/y&gt;&lt;/br&gt;&lt;/location&gt;<br>
 &lt;search-time&gt;27&lt;/search-time&gt;&lt;length&gt;7&lt;/length&gt;<br>
 &lt;data&gt;398701D&lt;/data&gt;<br>
&lt;/barcode&gt;<br>
&lt;/xml-stream&gt;<br>
<p>
This way you can get multiple barcodes in a single frame and have<br>
a reliable means of separating them.<br>
<p>
Another use of the text frame might be to allow the backend to <br>
report its configuration.  Wouldn't it be nice if the backend information<br>
shown in the Xsane dialog could include a little text area that simply<br>
displayed a textual summary of the scanner's inquired<br>
configuration and capabilities?  This would be especially useful if<br>
the scanner were being accessed through saned.  I don't know the mechanism <br>
by which the front end would ask for this, though.   <br>
<p>
<i>&gt; But if this stuff is just another output from a scan which might also</i><br>
<i>&gt; give us 5 JPEGs and a couple of G32D images, then I guess the text</i><br>
<i>&gt; frame makes a lot of sense. Formatting it would be your problem :)</i><br>
Sure, the formatting and parsing remain problems, but at least we don't<br>
have to get those details into the SANE standard.  I would think that<br>
other backends written for scanners with similar support could follow<br>
practice and use the xml encoding approach.<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="0184.html">Stephen Williams: "Re: SANE frames"</a>
<li> <b>Previous message:</b> <a href="0182.html">Nick Lamb: "Re: SANE V2"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>