kopia lustrzana https://gitlab.com/sane-project/website
147 wiersze
7.8 KiB
HTML
147 wiersze
7.8 KiB
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>> </i><br>
|
||
<i>> On Sun, 15 Aug 1999, Tom Martone wrote:</i><br>
|
||
<i>> </i><br>
|
||
<i>> > I'd have to disagree with you on this on, Nick. If you have a scanner</i><br>
|
||
<i>> > that has an integral barcode/patchcode decoding feature that works on the</i><br>
|
||
<i>> > surrently scanned image data in the firmware of the scanner, do we want to</i><br>
|
||
<i>> > use SANE just to get the image data? Then do we get an OCR package to</i><br>
|
||
<i>> > decode in software, the barcodes out of the saved image data? I've</i><br>
|
||
<i>> > observed that the scanner firmware does it more quickly and more reliably,</i><br>
|
||
<i>> > than an OCR approach and it does it at scan time rather than a separate</i><br>
|
||
<i>> > pass.</i><br>
|
||
<i>> </i><br>
|
||
<i>> Well, you make a very convincing argument, and you do have this hardware</i><br>
|
||
<i>> sat in front of you, which I don't. I asked this before, but I can't</i><br>
|
||
<i>> remember what exactly you said in response:</i><br>
|
||
<i>> </i><br>
|
||
<i>> Does it make sense to you (considering the TWAIN way of doing it among</i><br>
|
||
<i>> other things) for us to provide the results of a stuff like barcode</i><br>
|
||
<i>> scans in a SANE Option (just like you can specify the R/G/B exposures</i><br>
|
||
<i>> used by an auto-calibrating slide scanner) OR more like the existing</i><br>
|
||
<i>> image transfer frames, only with text in?</i><br>
|
||
<i>> </i><br>
|
||
<i>> Initially I thought that using SANE Options was a nicer way, because you</i><br>
|
||
<i>> can have something like this (I might be bending SANE's rules here a</i><br>
|
||
<i>> little bit, but I think it works today, in theory)</i><br>
|
||
<i>> </i><br>
|
||
<i>> SANE Option "Barcodes", hardware feature, not user alterable, string</i><br>
|
||
<i>> 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>
|
||
<xml-stream><br>
|
||
<barcode><br>
|
||
<window-id>0xa0</window-id><type>12</type><br>
|
||
<status-flag>0x01</status-flag><br>
|
||
<orientation>0x01</orientation><br>
|
||
<location><tl><x>1120</x><y>304</y></tl><br>
|
||
<tr><x>1120</x><y>256</y></tr><br>
|
||
<bl><x>1520</x><y>304</y></bl><br>
|
||
<br><x>1520</x><y>256</y></br></location><br>
|
||
<search-time>37</search-time><length>7</length><br>
|
||
<data>046300M</data><br>
|
||
</barcode><br>
|
||
<barcode><br>
|
||
<window-id>0xa0</window-id><type>12</type><br>
|
||
<status-flag>0x01</status-flag><br>
|
||
<orientation>0x01</orientation><br>
|
||
<location><tl><x>1104</x><y>304</y></tl><br>
|
||
<tr><x>1104</x><y>272</y></tr><br>
|
||
<bl><x>1504</x><y>304</y></bl><br>
|
||
<br><x>1504</x><y>256</y></br></location><br>
|
||
<search-time>24</search-time><length>7</length><br>
|
||
<data>034443M</data><br>
|
||
</barcode><br>
|
||
<barcode><br>
|
||
<window-id>0xa0</window-id><type>12</type><br>
|
||
<status-flag>0x01</status-flag><br>
|
||
<orientation>0x01</orientation><br>
|
||
<location><tl><x>1120</x><y>304</y></tl><br>
|
||
<tr><x>1120</x><y>256</y></tr><br>
|
||
<bl><x>1504</x><y>304</y></bl><br>
|
||
<br><x>1504</x><y>256</y></br></location><br>
|
||
<search-time>27</search-time><length>7</length><br>
|
||
<data>398701D</data><br>
|
||
</barcode><br>
|
||
</xml-stream><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>> But if this stuff is just another output from a scan which might also</i><br>
|
||
<i>> give us 5 JPEGs and a couple of G32D images, then I guess the text</i><br>
|
||
<i>> 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>
|