Re: Alternatives to a single bar code

From: Karl Auerbach <karl_at_cavebear_dot_com>
Date: Wed May 05 2004 - 12:57:33 CDT

> > San Francisco is doing its first STV based election. If it catches on we
> > will see a significant increase in the number of bits required to
> > represent a ballot.
> >
> One county. There are 2,219 counties--not many of which do things like they
> do in San Francisco.

Do we really want to limit our system so that it may be used only in small
rural counties?

> > There have been times when ballots here in California have had on the
> > order of 40 to 50 races and questions. If even a small number of those
> > start using ranked counting methods the bit count is going to get rather
> > large.
> >
> Please provide one specific example.

It would take dredging - but there have been times over the last decade
when we have had presidential, senatorial, congressional, state senate,
state assembly, judicial, county boards, school boards etc on the same
ballot with dozens of statewide initiative measures plus several local
referendum and initiative measures. Here in Santa Cruz I do remember
times when my stack of mark-sense cards felt like a program deck from the
days when I used to write software onto punched cards.

> > To me the 2D stuff is a no brainer - it gets nearly two orders of
> > magnitude more bits at no real increase in software cost ....
> >
> Do we have GPL 2-d software?

Such exists - e.g. http://sourceforge.net/projects/pdf417encode/

> > .... and only a tiny increment (an increment that may fade
> > away over time) in hardware cost.
> >
> Maybe. However, so far, this project has zero experience with 2-D. What
> other problems happen with 2-D?

I don't know - but 2D has been adopted by the US post office and Fed Ex.
Those are pretty harsh and demanding environments.

                --karl--
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Mon May 31 23:17:16 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:15 CDT