Re: Bar code researcher volunteer wanted

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Thu Jul 24 2003 - 12:51:41 CDT


At 10:14 AM -0700 7/24/03, Alan Dechert wrote:
>I have a task I'd like to see someone take charge of. I need someone to
>study bar coding schemes and come up with one that we can use on the demo.
>This is something Doug Jones and I disagree on slightly, but I'll put it
>this way: we're going to come up with a bar code scheme for the demo. It's
>not necessarily the way the ultimate product will have it, but we will say,
>"this is a way it could be done." The bar code is critically important to
>address a major issue: how to maintain a secret ballot for blind voters. I
>will explain.
>The bar code will not be human readable (btw, Doug has a scheme that would
>be human readable). Here's why I don't want it human readable: the voter
>will take the printout (8.5 in. x 11 in) from the printer and put it in a
>privacy folder. Imagine this folder is a file folder cut to 12 inches by 8
>inches. This means that 1/2 inch of the long edge will be exposed. This
>exposed area will have the bar code. So, a blind voter can take the
>printout and put it in the folder knowing that no one can read the contents
>of the ballot. But there will be a scanner set up so that the blind voter
>can go there and put on headphones and hear the selections read. A poll
>worker can assist the blind person and can see the bar code while voter
>privacy is preserved.
>Sighted voters will also be allowed to use the scanner to double check their
>ballot and to ensure that the bar code has been printed correctly.
>Having the bar code exposed also gives poll workers an indication of what
>side the print is on so that the ballot can be removed from the folder face
>down when it is about to be placed in the ballot box.
>We will not bar code write-in candidate names. I was thinking maybe we'd
>have a separate bar code for write in names but now I think we should not do
>this for the demo. Also, it may be unnecessary altogether. Some states
>only look at write in names if there are enough write in votes that it could
>possibly impact the election outcome. As I understand it, other states
>require that all the write-in names be tabulated regardless of whether or
>not in could impact the outcome. In these states, they could OCR scan all
>the ballots.
>So, we will only be encoding the bits. For example, in the ballot mockup I
>gave, there are 7 presidential candidates plus write-in. So the possible
>votes are
>We could use a single 8-bit ASCII character to represent the vote for
>president. Actually, we could encode a lot more than this with a single
>8-bit character because only 9 of the 256 possible bit patterns are possible
>vote patterns. I want to look at compression algorithms that analyze the
>ballot and develop a mapping scheme so that all the selections can be
>encoded in just a few characters (maybe 5 or 6 on an average ballot) but we
>won't get into that for the demo.
>Our mock ballot has 126 bits so it would take sixteen 8-bit characters to
>encode the selections. However -- and this is where some research is
>required -- not many bar code schemes can handle all the 8-bit characters.
>We need to find a bar code scheme that is simple and works with a cheap
>commodity reader. With luck, we'll find one that handles at least 128
>characters if it can't handle the 256 8-bit characters. If we have at least
>128, then we'd encode 7-bits at a time so it would take eighteen 7-bit
>characters to represent the 126 bits.
>Along with the selections, we'll encode the date, state, county, and
>precinct. Bar code schemes have various limits on how many characters they
>can handle so we'll need to consider what the length of the bar code will
>be. It would be nice if the bar code is no more than an inch or two long.
>We also need to look at how to print the bar code using Python.
>This may not be the best way to do it but we can't wait for OASIS to tell us
>what the standard format will be for the electronic ballot image. We will
>not claim this is the best way to do it. If someone demonstrates a better
>way, we will adapt to that. But for now, this is a simple doable scheme.
>We need someone to take responsibility for choosing the bar code type and
>figuring out how to make it work.
>-- Alan Dechert

- --
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA 94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
Received on Thu, 24 Jul 2003 10:51:41 -0700

This archive was generated by hypermail 2.1.8 : Wed Aug 06 2003 - 12:50:26 CDT