> I'd have to disagree with you on this on, Nick. If you have a scanner
> that has an integral barcode/patchcode decoding feature that works on the
> surrently scanned image data in the firmware of the scanner, do we want to
> use SANE just to get the image data? Then do we get an OCR package to
> decode in software, the barcodes out of the saved image data? I've
> observed that the scanner firmware does it more quickly and more reliably,
> than an OCR approach and it does it at scan time rather than a separate
> pass.
Well, you make a very convincing argument, and you do have this hardware
sat in front of you, which I don't. I asked this before, but I can't
remember what exactly you said in response:
Does it make sense to you (considering the TWAIN way of doing it among
other things) for us to provide the results of a stuff like barcode
scans in a SANE Option (just like you can specify the R/G/B exposures
used by an auto-calibrating slide scanner) OR more like the existing
image transfer frames, only with text in?
Initially I thought that using SANE Options was a nicer way, because you
can have something like this (I might be bending SANE's rules here a
little bit, but I think it works today, in theory)
SANE Option "Barcodes", hardware feature, not user alterable, string
constraint { "9 780201 835953", "3 057640 136993", "MULTIM-44-2731" }
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 :)
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com