<p>I worked in the scanning and data extraction business for about ten years. This is something I actually understand!</p>
<p>The technology used in those “scanners” is a combination of several components. First, there is a paper scanner that transports the paper past an imaging system that makes an electronic image of the document. Any imperfections in the mechanical system can produce an imperfect image. Any of you have ever had a weirdly stretched Xerox copy can understand this – it’s the same problem. Scanned images are imperfect. The scanned image will be a single-bit (black and white) image, probably scanned at 200 dots per inch, although it might be scanned at 300 dpi. Rarely is a mark-sense application scanned at the sort of resolutions we’ve come to expect in photo scanners, and rarely would it be done in grayscale or color. The image sizes get very large, very quickly when done at higher resolutions or in multi-bit color, and the results can actually be worse than in single-bit mode at lower resolution. Sometimes the simple answer is best.</p>
<p>Once the image is created, the software takes over. There are marks on the page that the software can use to standardize the image, and to detect whether it was scanned upside-down, or even bottom-end first. The standardization marks allow the software to rescale the image to a standard form if the paper transport was not running at exactly the right speed, or if it skewed during transport. The standardization routines can fix may errors, but they can’t do magic. It is possible to generate a bad image. By the way, the paper transport can work perfectly on one page, mess up the next one, and then work perfectly on the third one. Something as simple as a voter who ate a glazed donut just before handling their ballot can cause problems in the transport. The software that detects orientation and page order is pretty robust stuff, and works well. It’s not likely to introduce errors of its own, but it may miss problems with the source image.</p>
<p>Once the image is oriented and standardized, the optical mark recognition (OMR) software will attempt to tell whether a certain box is filled in or not. It does this my comparing the number of dark pixels in a certain area of the image to the number of dark pixels in other areas. In other words, the person who set the system up will program the software to look over 200 pixels from the edge of the image (or actually from the standardized registration marks on the document – but lets keep it simple), and 300 pixels from the top edge of the doc, and then count the dark pixels in the box from 200-250 pixels on the x-axis, and from 300-350 pixels on the y-axis. The proportion of dark to light pixels is analyzed to determine “is this box marked.” It then will conduct the same analysis for every check box on the form. I’m not sure how the ballot scanners are programmed (I worked on the core software, but we had thousands of customers using it to develop their own specific applications, like voting), but most people doing OMR will then program logic like, “Box 1 is 5% dark, box 2 is 90% dark, box 3 is 1% dark, and box 4 is 11% dark, therefore the user meant box 2.” The OMR software just tells the developer how many black dots there are – the developer needs to figure out what that means. They could have a rule that says, “To be a valid selection, only one box can have more than 80% dark. If there are two boxes that are more than 50% dark, I’ll reject this selection. If no box is more than 80% dark, I’ll reject it. If one box is more than 80% dark, no other box can be more than 20% dark. I will only accept an answer if one and only one box is more than 80% dark, and the others are all less than 20% dark.”</p>
<p>I dragged you through that to demonstrate that even ballot scanners are computerized processes, that they could be manipulated by software developers of fairly limited skills, and that even if the paper is sitting in front of a person, they have to develop rules, because people will make stray marks, will get jelly donut on the ballot, will not follow instructions, and generally will act just like they are trying to mess things up on purpose.</p>
<p>As a long-time professional software developer, paper is about the worst choice you can make. Humans suck at repetitive processes, and if there is anything more repetitive than hand-counting ballots I don’t know what it is. Scanning paper generates its own problems. In most applications, this scanning and OMR process is acceptable with an error rate of up to a couple of percent. This would have had a material effect on several national- and state-wide elections in the last ten years. I am NOT a big fan of using paper for voting.</p>
<p>If you are willing to accept that the system was not written by someone with active criminal goals, a pure software system with a computer terminal of some kind is by far the most likely to reflect the wishes of the data entry operator (the voter). </p>
<p>I’ll leave you with this, why don’t we fill out little slips of paper and then insert them into our ATMs for our personal financial transactions? It’s because it is time-consuming and error-prone compared to letting users simply use a keypad and screen to enter information. Why do we trust ATMs but don’t think the same people can build a trustworthy voting system?</p>