Android Question Barcode Example not reading Leading '0' from a EAN13 Barcode (Understood and Solved)

[virpalacios]

Hi All, I have a App from 2020 able to read Ean 13 codes from Supermarket Items, everything went fine until a couple days ago. If I read an ean 13 code like 0764460653021 the detector just read 764460653021 without leading 0, it was a recent issue, also I have this app running in IOS and it still working fine, right now I am using the Barcode Example from Erel for testing, if someone can help, please try to read below code, I am using B4A 11.80, APi 29 on Android 11 devices

Thank in Advance, Best Regards

Virgilio

PS this Item was not an EAN-13, it is a UPC-A code!!!

 

[emexes]

I tried it with a barcode app on my phone and it did not list the leading zero.

So now to decode it "by hand", see if the barcode itself actually has the leading zero... although I fear EAN-13 is one of those interleaved codes that makes me dizzy.

 

[emexes]

I tried it with a barcode app on my phone and it did not list the leading zero.

So now to decode it "by hand", see if the barcode itself actually has the leading zero...

Sorry, I was a bit lazy and instead of decoding it myself, I first tried it at:

https://www.onlinebarcodereader.com

which says it is UPC-A and also does not list the leading zero and also says:

UPC-A is a subset of the European Article Numbering (EAN) system, which means that any system that can read EAN/JAN-13 can also read UPC-A.

A UPC-A symbol that is created in the United States can be transformed into an EAN-13 symbol by prefixing it with a zero.

 

[emexes]

Righto, manually decoded, wasn't so bad, only the leading zero is encoded differently. Which I think is probably because they wanted to keep EAN-13 the same width as UPC-A, and they've traded off some error-resisting redundancy to costlessly piggyback/squeeze an extra digit to the left side of the bar code.

Manual decoding was:

W B W B
1 3 1 2 = 7 L
1 1 1 4 = 6 L
1 1 3 2 = 4 L
1 1 3 2 = 4 L
1 1 1 4 = 6 L
3 2 1 1 = 0 L

B W B W
1 1 1 4 = 6
1 2 3 1 = 5
1 4 1 1 = 3
3 2 1 1 = 0
2 1 2 2 = 2
2 2 2 1 = 1

and the leading 0 is "encoded" by the left side being all of digit type L

 

[emexes]

I think what's happening is that an EAN-13 barcode with a leading 0 looks exactly the same as a UPC-A barcode without that leading 0.

And so your barcode reading library is being equally truthful and correct regardless of whether it tells you it's (EAN-13) 0764460653021 (which it is) or (UPC-A) 764460653021, which it also is. ?

I turned off UPC-A recognition in the app I used earlier, and it now reads it as a 13-digit number ie including the leading 0.

Perhaps you can tell your barcode reading library which encodings to read - in your case: EAN-13 yes, UPC-A no - or maybe even the priority of interpretation eg if a barcode is equally-valid for two different encodings, which encoding it should prefer.

 

[virpalacios]

Thank you emexes, today I tried with diferent items (my app is for checking packed food in supermarkets (import permits)). I was just using a canned corn from China and a beans from Guatemala, those two items have troubles, however I test a docen diferent items everthing went fine, it could be an issue with bar code construction. Thank emexes for your time.

Best Regards

Virgilio

 

[emexes]

it could be an issue with bar code construction

To confirm, just in case:

The bar code construction is fine; the issue is what preference your barcode scanning libraries or apps have when they scan a barcode that is validly more than one barcode type.

Your barcode:

is both valid EAN-13 and valid UPC-A. It is impossible to tell from the barcode which of those two types of barcodes it is. We humans with our Mark 1 eyeballs can deduce from the decimal number below the barcode that it is meant to be EAN-13, but the scanner can only "see" the barcode lines, not the decimal number.

If your scanner "prefers" EAN-13, then it will read it as 0764460653021

If you scanner "prefers" UPC-A, then it will read it as 764460653021

If the leading digit of a EAN-13 barcode is anything other than 0, then the barcode pattern would not be valid UPC-A and the scanner would read it as EAN-13, no preference decision necessary.

If you are only expecting EAN-13 barcodes, then try set your barcode scanning libraries or apps to also only expect EAN-13 barcodes. This might also improve the scanning success rate for less-than-pristine barcodes too, if the scanner knows not to (mis)interpret it as another barcode encoding - bonus!

If your barcode scanning libraries or apps insist on reading UPC-A as UPC-A (12 digits) and not EAN-13 (same 12 digits, but with a leading 0) then your simplest solution is probably to tack a leading 0 onto 12 digit barcode scan reads. Yeah, it's a bit kludgy ? welcome to the world in practice, not theory ?

 

[drgottjr]

under some very strict circumstances, it is possible to decode
EAN-13 with mobile vision, mlkit and zxing.

the conditions involve generation of the barcode, quality, size,
orientation and environment (usually cropping) of the image
containing the barcode.

mobile vision (now deprecated) and mlkit are essentially black
boxes, that is, you scan and they do what they've been
programmed to do, however it may be that they have been
programmed. if they cannot decode the image, you are pretty
much limited to trying again. if they can decode the image, and
depending on the circumstances, they may decode an EAN-13
barcode as a UPC-A (minus the leading digit). they do not appear
to be able to decide EAN-13 with extensions.

zxing, on the other hand, can make a distinction between EAN-13
and UPC-A , and it supports EAN-13 with extensions. these
so-called extensions are handled in a "funny" way, but if you're
looking for something specific, the data (actually, metadata) are
there. note: zxing is also capable of identifying EAN-13 barcodes
as UPC-A (and missing the leading digit).

zxing offers a number of "readers", that is, object which specialize
in certain varieties of barcodes. among these are dedicated
ean and upc readers, the former being tweakable to recognize
various barcode extentions.

below please find a few samples. 1 image is the op's ean-13, the
other is an ean-13 with extensions.

 

[virpalacios]

Hi exemes, thanks for your extensive work, for now I am using just EAN13, so in this case I will add the 0, also I can use a like '%value' search in the database.
I read about the deprecating of mobile vision, and the inclusion of mlkit. I think we need a library (paid or included) in out B4X tools, it will ensure no google issues in our code.
By your evaluations do you think zxing libraries should be a way to go?.

Thanks your comments,

And Again My Appreciation for your great research!!

Best Regards

 

[emexes]

By your evaluations do you think zxing libraries should be a way to go?.

I've never actually used any barcode libraries with B4A (or B4X) = I don't know.

Sorry.

Lol, you just made me realise that most of my barcode experience is from the previous century. ?

 

[virpalacios]

a Lot of Lols, You have a great experience with Barcodes!! ?, you are an expert, thanks a lot to enlight everyone with these knowledges ?.

Best Regards and a lot of ???????

 

[vmag]

I tried 7 times to scan with a regular scanner that understands all barcodes your barcode, the problem is not on your side, the problem is in the barcode builder. You can modify the code - if the length of ean-13 is less than 13 characters - add the required number of zeros on the left. So you can adjust the ean-8 to the ean-13 standard

 

[emexes]

I tried 7 times to scan with a regular scanner that understands all barcodes your barcode

That space on the first scan is a bit of a worry. And also why are the first two flush right, and the remaining flush left? ?

the problem is in the barcode builder.

The problem - more of a difference of opinion rather than a problem - is not the barcode or its builder; it is that @virpalacios 's scanner, like yours, is capable of reading many barcode types, and is interpreting that barcode as UPC-A which is entirely a reasonable thing to do, because that pattern of lines is 100% valid UPC-A and UPC-A is 12 digits.

If the scanner can be set to NOT read UPC-A, the scanner should then interpret the pattern of lines as EAN-13 and the problem difference of opinion will be resolved. ?

 

[virpalacios]

That space on the first scan is a bit of a worry. And also why are the first two flush right, and the remaining flush left? ?

View attachment 136009



The problem - more of a difference of opinion rather than a problem - is not the barcode or its builder; it is that @virpalacios 's scanner, like yours, is capable of reading many barcode types, and is interpreting that barcode as UPC-A which is entirely a reasonable thing to do, because that pattern of lines is 100% valid UPC-A and UPC-A is 12 digits.

If the scanner can be set to NOT read UPC-A, the scanner should then interpret the pattern of lines as EAN-13 and the problem difference of opinion will be resolved. ?

Hi @emexes, @drgottjr, @vmag, Yes, I concluded like you, it is a opinion, I was wrong, it was not a problem, it a setting issue. This code is a UPC-A with 12 digits, I think the issue was about how the code was registered in the database, it is a UPC-A, so it has to be registered like a EAN-13, I did additional checking with the customer, so I found other items with similar problems. Thanks again for your time and effort. So We can Check this Post as Solved and Understood (And great learning for me!!) ? ?