Bar code researcher volunteer wanted

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Thu Jul 24 2003 - 12:14:44 CDT

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
Received on Thu, 24 Jul 2003 10:14:44 -0700

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