Re: Scanner, write-ins, printer (was Re: Barcode -- printed ballot)

From: Jan Karrman <jan_at_it_dot_uu_dot_se>
Date: Tue Oct 07 2003 - 05:59:58 CDT

On Sun, 21 Sep 2003, Alan Dechert wrote:

> Ed wrote (quoting me):
> >
> > > We need to keep the string of characters containing the
> > > encoded selections down to a minimum to ensure accuracy
> >
> > Accuracy is ensured by error-correcting coding, that is by adding
> > redundancy in a controlled manner, not by removing all possible
> > redundancy. Error correction must be part of the bar code
> > standard we adopt.
> >
> In light of the testing I've done, I want to re-visit these comments.
> Instead of "ensure accuracy," I should have said "ensure readability."
> Accuracy does not appear to be a problem. When you swipe a barcode, the
> thing either reads or it doesn't. I never saw a mistake in the output --
> either while testing with Jan's barcode or reading codes on various
> household products, books, shampoo bottles, beer cans, etc.

I have actually got the wrong code scanned by the Cue Cat once now.
It got three symbols (pairs of digits) wrong. The checksum character
for both the correct and the faulty code happened to be the same.
The font size was probably a little bit too small, because it took
several tries to get it to read at all.

As I wrote earlier, I always add a leading zero to the decimal number
to make it an even number of digits. To improve the reliability of
the scan, this could instead be a checksum digit we calculate somehow.
This will then not affect the length of the bar code.

The application that reads the input from the scanner should, beside
from checking the checksum digit and length of the string, also issue
some sound to indicate a successful scan.

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Oct 31 23:17:01 2003

This archive was generated by hypermail 2.1.8 : Fri Oct 31 2003 - 23:17:07 CST