#2 Another Scanning Bug (I think...)

[Chris Arnesen]

Here's another bug for everyone...

Scanned Raw: .C3nZC3nZC3nZC3PWE3j0C3nX.fHmg.C3b3CND3CW.
What the barcode should convert to: 03414406 [UPC-E]
What UScan is converting it to: 03414402

BTW, this is the barcode on a 10 oz package of Hershey's Reese's Peanut Butter Chips.

Thank you in advance!

[Rob Fugina]

The last version of the perl code I saw posted to the
discussion group here on SF converts that raw string
to the following:

0341440C

All of the UPC-E's that I scan end in a C rather than
reporting the check digit printed on the bar code. I've
*occasionally* scanned a UPC-E where a digit was mis-read
AND instead of a C, it ended in a '#' -- this would indicate
to me an incorrect check digit was read... If you're using
perl, you can use the package Business::UPC to recalculate
the check digit and/or render the full UPC-A code...

Rob

[Daniel Thomas]

Hrrrrm not too familiar with the python code. But all the conversion codes tend to have problems with shorter barcodes... <BR>

The c code I'm modifying to get it ready for release by uscan has the problem that the old perl code mentioned has. Hopefully this will be dealt with by the python code managers<BR>

[Daniel Thomas]

this being the problem that this guy is having not my c code of course

[Taral]

Logged In: YES
user_id=25129

This is a mis-scan. UScan should be printing:

03141440

Since that is all the available data. (There are only 4+4+2
input characters, which translates to 3+3+1 output)