Menu ▾ ▴

#345 UPC-A and GS1 Databar inconsistencies with Upstream zxing-cpp and zint versions

1.0
open
nobody
None
2025-12-22
2025-12-22
Andre Maute
No

Hi there,

I'm currently testing the state of upstream combinations of zint and zxing-cpp
and I would like to report some inconsistencies I found.

For the reproducer you need a recently updated Fedora 42 with gcc packages and dev tooling installed.

I have just updated my 'zintzxingcppdemo' integration demo project.
For a fixed version build it now uses zint 2.16.0 and zxing-cpp 2.3.0.

https://github.com/a3emdot/zintzxingcppdemo/commits/main

Cloning and building the project with the script './ZintZXingCppDemo.sh' (fixed versions) shows 0 failed tests.
But cloning and building the project with the script './ZintZXingCppDemoUpstream.sh' shows 1 failed test.

$ cat /home/user/tmp/zintzxingcppdemo/build/local/src/Testing/Temporary/LastTest.log
Start testing: Dec 22 12:13 CET
----------------------------------------------------------
1/17 Testing: zintzxingcppdemo-test
1/17 Test: zintzxingcppdemo-test
Command: "/home/user/tmp/zintzxingcppdemo/build/local/src/zintzxingcppdemo-test"
Directory: /home/user/tmp/zintzxingcppdemo/build/local/src
"zintzxingcppdemo-test" start time: Dec 22 12:13 CET
Output:
----------------------------------------------------------
0 --- UPCA-00000012345-200
0 --- UPCA-12345678901-200
0 --- UPCA-000000123457-200
0 --- UPCA-123456789012-200
0 --- UPCA_CHK-000000123457-200
0 --- UPCA_CHK-123456789012-200
0 --- GS1_DBAR_OMN-12345678901231-200
0 --- GS1_DBAR_OMNSTK-12345678901231-200
8 of 419 tests failed
...

The tests use only simple data for these barcodes with a given height of 200
https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/main.cpp#L204
https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/main.cpp#L227

I wonder if zint is behind the latest changes in zxing-cpp.

Regards Andre

Discussion

  • Harald Oehlmann

    Harald Oehlmann - 2025-12-22

    Is it possible, that those codes are filtered out by "-gs1strict" ?
    The first code "0000012345" will probably fail due to a zero company prefix error.
    But this does not apply to UPCA. Is there a 2D component?

     

    • Git Lost

      Git Lost - 2025-12-22

      Hi Harald, no, not in this case, "-gs1strict" isn't being used.

       

  • Git Lost

    Git Lost - 2025-12-22

    Hi Andre, thanks for checking this.

    There were (at least) 2 changes to the way ZXing-C++ returns data (none to do with zint per se!):

    So the zxingFixReadData() function needs to adjusted to allow for these.

    Regards, Martin

     

    • Andre Maute

      Andre Maute - 2025-12-22

      Hi Martin, thanks for posting your insights,

      I wonder if it would be possible to let the two projects converge a little bit more,
      so my fix functionality isn't needed anymore. Perhaps Axel reads this.

      https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/barcode.cpp#L336

      int zintFixZintSymbology(const std::string& input, int zintsymbology);

      and

      https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/barcode.cpp#L509

      std::string zxingFixReadData(
  int zintsymbology,
  const std::string& writtendata,
  const std::string& readdata
);

      Though I haven't checked yet, what has to be done with the zint symbologies EANX, EANX_CHK and the newly provided symbologies EAN8 and EAN13, and why there is still an UPCA_CHK symbology though the EANX_CHK is now tagged 'legacy'.

      I will check with my internal downstream projects what should be done.
      But as time permits, I might not get around to it until next month.

      Kind regards and happy holidays to both of you,
      Andre

       

      • Git Lost

        Git Lost - 2025-12-22

        I think the ZXing-C++ data return format has settled down and won't be changing much (or very little) in the future. Version 2.4.0 is also pretty imminent which would cement the data return format at least for that release.

        Re EANX_CHK being tagged as "legacy" and UPCA_CHK not, it's because EANX_CHK also accepted EAN-8, which made it problematic to distinguish input with separator-less add-on data, which was needed by ZXing-C++. Splitting EANX etc. into EAN13 and EAN8 also makes everything a lot easier to deal with regarding default data, adding leading zeroes, whether a check digit was present or not and other input format options. Note that EANX etc. still work as before, so nothing should need to change from a legacy user point of view.

        Re updating zxingFixReadData(), I currently deal with interfacing with ZXing-C++ in testUtilZXingCPPCmp() in "backend/tests/testcommon.c", so if you like I could do a basic PR for "zintzxingcppdemo" which would address the above changes.

        Anyway all the best for the Winter Solstice and New Year season to you too, regards, Martin

         

  • Harald Oehlmann

    Harald Oehlmann - 2025-12-22

    Sorry for the noise.
    It would be great to use the GS1 demo prefix for any testing, which is 952.
    Examples for ISO/IEC 15240:2024:

    • EAN13: 9520123456788
    • EAN-8: 95200002
    • UPC-A: 012345000484
    • UPC-E: 01234558
    • GTIN-14: (01)09520123456788

    This avoids conflicts with -gs1strict
    Just an idea,
    Harald

     

  • Harald Oehlmann

    Harald Oehlmann - 2025-12-22

    Yes, and I am wrong.
    The code [01]00000000000000
    is not seen as error by -gs1strict.
    Strange, I had this discussion with Terry and we first did not accept a 0 GCP...

    Sorry,
    Harald

     

Log in to post a comment.