RE: Manually typeset ballots

["Ken Clark" <ken@gesn.com>]

Thanks Jeff.  It sounds, then, like the candidate positions were fixed for
for all ballots?  In other words the oval position was the same for a given
candidate on all ballots?

I don't think we would want to have that limitation for GEMS, but on the
other hand it means a lot more "data entry" if they can float from ballot to
ballot (you have to enter the positions for every ballot).

Ken

> -----Original Message-----
> From: Jeff Hintz [mailto:jhglobal@earthlink.net]
> Sent: Thursday, March 18, 1999 3:42 PM
> To: 'Ken Clark'
> Subject: RE: Manually typeset ballots
>
>
> When I worked at AIS (ES&S), we had several accounts in the state
> of New Jersey and they laid out the candidates across the ballot.
>  At that time, we had no ballot layout software, I am not sure if
> they have any now that can support this either.  But as for the
> programming of the machines to count the ballots, we specified
> oval positions for each candidate.  At that time they had 36
> positions per column, 3 columns per side, 2 sides.  So for
> example, when programming a race, the ovals could be 1, 37, and
> 73 for a 3 candidate race going across the ballot.
>
> -----Original Message-----
> From:	Ken Clark [SMTP:ken@gesn.com]
> Sent:	Wednesday, March 17, 1999 2:29 PM
> To:	support@gesn.com
> Subject:	RE: Manually typeset ballots
>
>     VTS does not allow candidate oval positions to be 'entered' manually.
> What it does allow is, in the BallotEditor, to move candidates to
> any unused
> voting location on the ballot.
> Thanks Tab.
>     Some of these adjusements that were required in VTS are no longer
> required in GEMS since it provides a better method of doing ballot layout
> and more options than VTS did.
>
> Right.  The GEMS theory is that we would add any reasonable layout options
> to handle whatever cases we came across.  GEMS also allows
> movement of races
> outside of the column paradigm (by quarter inch), which helps a lot.  This
> falls down in the face of this "Grid Layout" however since it doesn't look
> (to me) like any reasonable race options are going to lay out the ballot
> automatically.
>     This would be a nice feature to have since it would allow us to tell
> customers who have weird layouts that they can manually lay the
> ballots out,
> BUT I would not suggest doing it until we get some very solid demand from
> the support and or sales group
>
> Right again.  From Frank's email it looks like many of the New England
> states want this, and Don Vopalenski has put the requirement on the table.
>     The major 'problem' with this is that GEMS stores the layout for the
> 'base' rotation and then rotates the candidates through the set
> of positions
> defined for the race.  Therefor 'special' rotation fixes cannot be done
> using this.
>
> I thought about this, and should have brought it up in the
> original mail.  I
> think the GEMS rotation design is sound (in fact I think it is a major
> unique feature of GEMS) and is outside the manual layout issue.  In GEMS,
> rotation is independent of layout.  This would remain the case for manual
> layout.  We may *also* need to support manual rotation, but that would
> entail entering in the rotation number for the race for a given
> baseunit-ballot.  Manual layout would be done using "rotation 0"
> (like it is
> done, albeit with less flexibility, now).
>     If we were to implement this I would suggest allowing the
> candidates to
> be moved within the race rectangle.
>
> I think the devil is in the details here.  How, exactly, are candidates
> "moved within the race rectangle"?  What happens to the candidates after
> they have been moved if the race rectangle is resized?  This is currently
> well defined in GEMS, but would not be if we allow the candidates to move
> freely.
>
> Another possibility is to just attach "tags" to the ovals (ie the
> candidate
> label) and allow them to be freely dragged around the a card,
> independent of
> race boxes.  The ballots would not be layed out and then adjusted, but
> rather positioned manually from the start.  I think this better
> matches the
> fact that the artwork is being typeset manually (and independently) by the
> printer.  It sidesteps the "overlapping race box" issue you bring up also.
> I have not really thought through all the implications of this solution
> however.
>
> Does anyone know how ES&S does this?  I get the impression that they and
> these "SAT Test" scanning systems can enter oval positions based on the
> typeset artwork, but I don't know the details (and can't guess either).
>
> Ken
>
>  << File: ATT00000.htm >>
>