Re: Bar code researcher volunteer wanted

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Thu Jul 24 2003 - 14:13:29 CDT

Arthur

At 11:20 AM -0700 7/24/03, Alan Dechert wrote:
>This is why I'm saying someone needs to research this. The descriptions on
>the page you cite don't tell us much. For example, I would like to know how
>many characters are represented in the Code 128 sample. If that bar code is
>50 characters long, then I might like it. If it's only 10 characters, then
>we have a problem.
>
>What (and how many) characters can you encode with Code 128? If you have
>128 characters, that's good. What about the others? This page just doesn't
>tell us.
>
>Alan
>
>----- Original Message -----
>From: "Arthur Keller" <arthur@kellers.org>
>To: <voting-project@lists.sonic.net>
>Sent: Thursday, July 24, 2003 10:51 AM
>Subject: Re: Bar code researcher volunteer wanted
>
>
>> Which bar code font do we want to use? Here's a list (and source,
>> although we may want to buy elsewhere).
>>
>> http://www.bizfonts.com/fontpackage/
>>
>> Arthur
>>
>> 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
>> >
>> >10000000
>> >01000000
>> >00100000
>> >00010000
>> >00001000
>> >00000100
>> >00000010
>> >00000001
>> >and
>> >00000000
>> >
>> >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

- --
-
-------------------------------------------------------------------------------
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 12:13:29 -0700

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