The option approach would certainly work and would avoid having to
parse through the text file, which would be nice. It still requires a
cooperating frontend, knowledgeable about the special properties of the
Barcodes option. Then you'd have to do something with the data, which
might be done outside the scanning application and you'd end up writing
it out somewhere for further processing.
The other thing that was concerning me was all this extra information
about the barcode that's available from the scanner. Stuff like the
barcode type, coordinates where it was found, time to find it, etc.
I felt a bit uncomfortable throwing that away and it would be hard to
send it all through options. So what I'm currently doing it encoding
all this in a XML tagged format and spitting it all out to a file.
This doesn't solve the application's parsing chore (it makes it harder,
I guess) but all of the available info is passed along in case it is
ever useful (e.g. the application will only accept a barcode in a certain
region, of a certain type). The search time is sort of useful when you're
trying to get the barcode-timeout setting right for a batch of documents.
That, of course, could be output as debug-trace info instead, I guess.
Here's an example of the stuff the bh backend writes:
<xml-stream>
<barcode>
<window-id>0xa0</window-id><type>12</type>
<status-flag>0x01</status-flag>
<orientation>0x01</orientation>
<location><tl><x>1120</x><y>304</y></tl>
<tr><x>1120</x><y>256</y></tr>
<bl><x>1520</x><y>304</y></bl>
<br><x>1520</x><y>256</y></br></location>
<search-time>37</search-time><length>7</length>
<data>046300M</data>
</barcode>
<barcode>
<window-id>0xa0</window-id><type>12</type>
<status-flag>0x01</status-flag>
<orientation>0x01</orientation>
<location><tl><x>1104</x><y>304</y></tl>
<tr><x>1104</x><y>272</y></tr>
<bl><x>1504</x><y>304</y></bl>
<br><x>1504</x><y>256</y></br></location>
<search-time>24</search-time><length>7</length>
<data>034443M</data>
</barcode>
<barcode>
<window-id>0xa0</window-id><type>12</type>
<status-flag>0x01</status-flag>
<orientation>0x01</orientation>
<location><tl><x>1120</x><y>304</y></tl>
<tr><x>1120</x><y>256</y></tr>
<bl><x>1504</x><y>304</y></bl>
<br><x>1504</x><y>256</y></br></location>
<search-time>27</search-time><length>7</length>
<data>398701D</data>
</barcode>
</xml-stream>
This way you can get multiple barcodes in a single frame and have
a reliable means of separating them.
Another use of the text frame might be to allow the backend to
report its configuration. Wouldn't it be nice if the backend information
shown in the Xsane dialog could include a little text area that simply
displayed a textual summary of the scanner's inquired
configuration and capabilities? This would be especially useful if
the scanner were being accessed through saned. I don't know the mechanism
by which the front end would ask for this, though.
> But if this stuff is just another output from a scan which might also
> give us 5 JPEGs and a couple of G32D images, then I guess the text
> frame makes a lot of sense. Formatting it would be your problem :)
Sure, the formatting and parsing remain problems, but at least we don't
have to get those details into the SANE standard. I would think that
other backends written for scanners with similar support could follow
practice and use the xml encoding approach.
Tom Martone
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com