Code128 ResultPoints return incorrect values

Currently the Code128Reader reader is providing a Result information with incorrect coordinates at where the code starts and ends.

Taking the following barcode as an example:

I’m getting the following results:

{
    "text": "foobar\n",
    "rawBytes": "aEZPT0JBUmVKQWo=",
    "numBits": 88,
    "resultPoints": [
    {
        "x": 59,
        "y": 122
    },
    {
        "x": 499,
        "y": 122
    }],
    "resultMetadata": {
        "SYMBOLOGY_IDENTIFIER": "]C0"
    },
    "timestamp": 1656682389903,
    "barcodeFormat": "CODE_128"
}

Now the result point 1 is [59,122], which is in de middle of the Code128 start pattern, not the start of the actual data nor the start of the barcode.

Looking at decodeRow method Code128Reader, the startPatternInfo is found first and the code is decoded. This is all correct, however at the end where the result is constructed the left and right (which are the points returned in the result) are calculated based on the startPatternInfo.

In this case left is calculated as (startPatternInfo[1] + startPatternInfo[0]) / 2.0f; here the startPatternInfo[0] has the actual position (albeit 1 pixel off in the example) of the barcode left coordinate. Right is calculated as lastStart + lastPatternSize / 2.0f which is also incorrect, since it results in the middle of the CODE_STOP of the Code128.

The fix for the left is straightforward, either use startPatternInfo[0] or “calculate it” based on startPatternInfo[1] and startPatternInfo[2] (startPatternInfo[2] - startPatternInfo[1]) which results in the same value as startPatternInfo[0];

From debugging info the startPatternInfo has the following values:

startPatternInfo[0] = 37
startPatternInfo[1] = 84
startPatternInfo[2] = 101

The fix for right requires more investigation.

[srowen]

I can look at returning some other metadata that’s like ‘all points the implementation happened to find, in some impl specific order’ maybe. And leave the current return value as is as a sort of ‘key human readable locations’ Adding a bit of extra existing info to the return seems OK

[axxel]

Just name one alternative that might work a bit better for your application: https://github.com/nu-book/zxing-cpp

During reimplementation of all the 1D codes, I opted for returning ‘everything except the quite zone’ as the position of any barcode, that mostly means ‘from the first black pixel to the last black pixel’. Generally, you still have the limitation that you don’t get the full bounding box. But if you used the ReadBarcodes (multi-barcode version) function and your symbols are properly detectable and horizontally aligned you do in fact get pretty much exactly that: .