votingworks / vxsuite

https://voting.works
30 stars 5 forks source link

VxMark: Seals are sometimes printed all black #4907

Closed arsalansufi closed 1 week ago

arsalansufi commented 3 months ago
seal

Relevant Slack thread: https://votingworks.slack.com/archives/C03Q42V9MJ5/p1716234851798559

And a relevant note from Drew on that thread:

In this case I don’t think it’s a problem with the SVG. Everything in the seal is just above the B&W threshold. We’d have to perform “dithering” on the seal to emulate grayscale in a B&W printer. At one point I had this in the VSAP prototype code but never productionized it.

arsalansufi commented 3 months ago

Made this high pri to start but could argue that it should be medium pri

arsalansufi commented 1 month ago

If the NH seal prints fine, we can push this to v4.1

carolinemodic commented 2 weeks ago

Facing a lot of inexplicable trouble with this task. Putting my notes here in case someone else takes it over:

Current work: https://github.com/votingworks/vxsuite/compare/caro/test_dither?expand=1

I applied atkinson, and floyd-steinberg dithering to the printing image on VxMark, both print fine I think atkinson looks a little better then floyd-steinberg but both interpret properly. However immediately after printing when VxMark transitions to then scan the ballot it immediately fails with an error, this error seems to change somewhat nondeterminstically between an error saying it got TrailingData from the transferInAcknowledgement function in the driver, or got the value of '0' which it can not parse. I verified that the bitmap chunks I'm creating are the same number as there were before, there are the same number of empty ones as before, the width of each chunk and the size of the data array inside of it is the same as before, etc. The only difference is that there are fewer black pixels in the new version. I think the more complex printing (on/off white/black pixels) is either just breaking the printer or making it slower so it thinks there is still data to flush even though it should all be flushed, or the bit data I'm sending for the image is somehow matching some other command and the driver is misinterpretting it. I don't understand how the driver works though so its hard for me to continue debugging from here. One time it randomly worked and there was no error after I added an extra await driver.print() in the application-driver layer, and then I removed some debug logging and it started failing again....

jonahkagan commented 1 week ago

Here's a seal we used in Moultonborough to test with moultonborough-seal