[Bug report] EAN13 code starting with 0 detected as UPC-A

[sertal70]

EAN13 codes starting with 0 are detected as UPC-A code, dropping the leading 0 in the returned code.

To Reproduce
Example Steps to reproduce the behavior in sample app:

1. launch the example app (I used the iOS version but it doesn't matter)
2. Select "Barcode Scanning"
3. Take a photo of this EAN13 code:

6. Tap on "Detect"
7. See result code: it is missing the initial 0 digit

I have modified the source to print out also the format of the detected code.

Here is the result using an EAN13 starting with 0:

As you can see the detected format is 512, which is UPC-A.

Here is the result using an EAN13 not starting with 0:

The detected format is 32, which is EAN13.

Expected behavior
EAN13 codes should be detected as they are, even when the code starts with 0.

SDK Info:
I'm not sure how to get this info, I simply run pod install and this is the result:

$ pod install
Analyzing dependencies
Downloading dependencies
Installing GTMSessionFetcher (3.3.1)
Installing GoogleDataTransport (9.4.1)
Installing GoogleMLKit (5.0.0)
Installing GoogleToolboxForMac (2.3.2)
Installing GoogleUtilities (7.13.0)
Installing GoogleUtilitiesComponents (1.1.0)
Installing MLImage (1.0.0-beta5)
Installing MLKitBarcodeScanning (4.0.0)
Installing MLKitCommon (10.0.0)
Installing MLKitFaceDetection (4.0.0)
Installing MLKitImageLabeling (4.0.0)
Installing MLKitImageLabelingCommon (6.0.0)
Installing MLKitImageLabelingCustom (4.0.0)
Installing MLKitObjectDetection (4.0.0)
Installing MLKitObjectDetectionCommon (6.0.0)
Installing MLKitObjectDetectionCustom (4.0.0)
Installing MLKitPoseDetection (1.0.0-beta12)
Installing MLKitPoseDetectionAccurate (1.0.0-beta12)
Installing MLKitPoseDetectionCommon (1.0.0-beta12)
Installing MLKitSegmentationCommon (1.0.0-beta10)
Installing MLKitSegmentationSelfie (1.0.0-beta10)
Installing MLKitTextRecognition (3.0.0)
Installing MLKitTextRecognitionChinese (2.0.0)
Installing MLKitTextRecognitionCommon (2.0.0)
Installing MLKitTextRecognitionDevanagari (2.0.0)
Installing MLKitTextRecognitionJapanese (2.0.0)
Installing MLKitTextRecognitionKorean (2.0.0)
Installing MLKitVision (6.0.0)
Installing MLKitVisionKit (7.0.0)
Installing MLKitXenoCommon (1.0.0-beta12)
Installing PromisesObjC (2.4.0)
Installing nanopb (2.30910.0)

Smartphone:

• Device: iPhone7 plus

Development Environment:
(For Android issue feel free to skip this section)

• IDE Eversion: Xcode 15.3
• Laptop: MacBook Pro
• Laptop OS/version: macOS 14.4

[JavaLavaMT]

I like this issue, but for now

https://react-native-vision-camera.com/docs/guides/code-scanning#upc-a-vs-ean-13-codes

"You will need to keep this in mind and do the conversion from EAN-13 to UPC-A yourself. This can be done by removing the front 0 digit from the code to get a UPC-A code."

I am sure they would take a PR for a fix

[sertal70]

@JavaLavaMT the issue is actually the opposite: I ask the library to recognize an EAN-13 code but it returns an UPC-A code, which it is not what I asked and it is not what I scanned.

[terryburton]

An EAN-13 beginning with "0" is by definition a UPC-A, at least in so far as the bar space pattern is identical. Only the placement of the human-readable text differs, whose recognition is not within the purview of a typical reader.

The history for this is that when it became clear that the 12-digit numeric code required extending in order to allow some variant of the UPC to be used in the non-US markets, a construction was adopted where certain UPC symbol character sequences (bar space segments) were mirrored on the left-half of the newly-defined EAN-13 symbol, which was otherwise identically encoded. This allowed an additional leading digit to be derived by detecting which segments were mirrored. When no mirroring is taking place (i.e. identical bar/space pattern to UPC-A) then the prefix digit is defined to be "0". The scheme extended UPC-A into a 13-digit space and did so in a way that meant that the new EAN-13 symbols could be adopted universally, with legacy UPC-A only scanners still able to scan the sub subset of new EAN-13s beginning with a "0" that were intended for the US market.

For further illustration of the equivalence of these symbologies, the transfer protocol for scanners defines a "symbology identifier" header that is transmitted ahead of the barcode data to instruct the host about the meaning of the data it is about to receive. It is intended to be "all that matters" from the perspective of reading barcode data. (Other devices such as verifiers may have graphical requirements, of course.)

For EAN-13 and UPC-A the symbology identifier ]E0 is transmitted, followed by 13 digits. The notional twelve digits of UPC-A (there really is no such a thing because by the time of ISO standardisation the original decode algorithm was already replaced by EAN-13) are padded with a zero prefix.

Note that UPC-E is also transmitted as a 13-digit number behind ]E0, requiring its 8-digit numeric contents to be decompacted (reverse the zero-suppression algorithm) prior to transmission. However EAN-8 uses a separate 8-digit number space, transmitted as 8 digits behind ]E4. (However, GS1 has nowadays brought this separate number space into alignment by reserving zero-prefixed space within the 13-digit system.)

Aside:

My experience is the the Barcode Scanning component of ML Kit is inconsistent with following the standards for data transmission, including a symbology identifier in the rawValue for some symbologies (e.g. Code 128) but not others (e.g. EAN/UPC, QR Code, Data Matrix). This is a problem for GS1 AI syntax data whose presence is signalled unambiguously via the "modifier character" of the symbology identifier. In some cases, there is a "proxy" in that a leading FNC1 character is (erroneously, but usefully) transmitted as a GS character, so the presence of FNC1 in first character position can be derived. But not so with a GS1 QR Code in which the leading FNC1 character is unceremoniously dropped with no proxy to indicate that it was ever there.