Barcode bandwidths

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Sat Sep 13 2003 - 23:04:06 CDT

|If we go the nibble route we can represent the sample data in 22
|nibbles or 11 bytes. (88 bits for those of you who are counting
|bits ).... How many ballot items will we need to represent?

I did a little more research (and also added an update that Jan sent
into the Architecture).

The limit Alan states of aproximately 30 symbols for a readable 1-D
barcode is on target. However,

    [Code128] Character set C enables numeric data to be represented in
    a double density mode. In this mode, two digits are represented by
    only one symbol character saving valuable space.

Moreover,

    UCC/EAN 128 is a very secure symbology so errors are extremely rare.
    It uses two independent self-checking features which improves
    scanning reliability.

So, in other words, we have about 60 decimal digits to work with in
encoding a ballot. That should give us room to do so without excessive
cleverness about the relation between votes and codes. It's not a
*huge* space, but it is comfortable.

Interestingly, going with a 2-D barcode gives us a truly expansive data
space:

    PDF417 is a high-capacity two dimensional bar code developed by
    Symbol Technologies, Inc. A PDF417 symbol can hold approximately
    2000 characters of information, whereas a traditional linear bar
    code has difficulty holding more than 30 characters.

These quotes are from:

    http://www.pdf417.com/

Yours, David...

--
    _/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
   _/_/    ~~~~~~~~~~~~~~~~~~~~[mertz@gnosis.cx]~~~~~~~~~~~~~~~~~~~~~  _/_/
  _/_/  The opinions expressed here must be those of my employer...   _/_/
 _/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them!  _/_/
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Tue Sep 30 23:17:05 2003

This archive was generated by hypermail 2.1.8 : Tue Sep 30 2003 - 23:17:09 CDT