Hi, I just started using a Zint for a project to generate Data Matrix codes (actually after having to leave another project that generally produces DMs fine, but would garble some of the ones that I was trying to build). And now, just as a project is rolling out, to my dismay, I'm finding that Zint appears to be also mangling some output (producing an incorrect barcode), by throwing a couple of bad characters on the end (or possibly making an un-readable barcode, my Android barcode scanner app won't read it, and one online reader reads it, but with two extraneous characters on the end).
Using either Zint Barcode Studio (version 2.6, and the previous 2.5.x version do the same thing), or this on the command line:
zint -o test.png -b 71 -d "[)>@06@12S0002@PA2C9757900100@1P40788113AD@31P40788113AD@12VC11011773@10VCHN-TIANJIN@2PAD@20P@6D20170515@14D20180215@30P0@ZN@K0056053139@16K296129@V378271@3S360000041B01@Q8NAR000@20T2@1T170428-055@2T170428-054@1ZNA@@"
produces this bad PNG file, which this website reads as:
https://online-barcode-reader.inliteresearch.com/
[)>@06@12S0002@PA2C9757900100@1P40788113AD@31P40788113AD@12VC110
11773@10VCHN-TIANJIN@2PAD@20P@6D20170515@14D20180215@30P0@ZN@K00
56053139@16K296129@V378271@3S360000041B01@Q8NAR000@20T2@1T170428
-055@2T170428-054@1ZNA@@ÿÿ
(note the trailing 'ÿÿ' characters that shouldn't be there).
Could one of the authors please review?
In case it helps, Zint produces a correct barcode if I drop one of the trailing '@' signs in the data (so I end with '1ZNA@') for some reason.
Thanks for the product, and for reviewing my bug report.
Hi Jll,
I've had a look at this, and it is indeed a bug. I have just applied a patch to correct the problem so if you can get the latest code snapshot and compile it you should find it now works properly with your sample data. Unfortunately since we have just released version 2.6.0 there is unlikely to be another binary release for while, possibly a few months. A more technical explanation (if you're interested) is given below.
Thank you for taking the time to make a bug report. If you find anything else then please do get in touch.
Robin.
Explanation: The problem was in how Zint applies the Unlatch character in EDIFACT encoding if it is still in EDIFACT mode at the end of a symbol. Previously Zint finished the 24-bit EDIFACT block before reverting to ASCII mode, however the relevant section of the ISO standard states "...any remaining bits in the single symbol character shall be filled with zeros." (section 5.2.8.2) ...implying that the unlatch takes effect immediately.
Thank you Robin for the fix !
And thans, jil, to use ISO15434 data structure in the Bosch/Hella/Conti variant ! That is great.
Enjoy,
Harald
Firstly Robin, thanks much for the fix. I can confirm it worked to fix my issue and I'm now using it in production. I'm quite unfamiliar with building projects like these in Windows, and had to really hack around and cobble stuff together (but finally was able to do it with CMake and MingW), so I would add a minor request that the project issue official binaries and a point release including this fix at the developers' convenience. The zint.exe I ended up with requires a couple of DLLs for whatever way I built it where the official binaries have a stand-alone exe, which I'd prefer.
This is not at all to diminish my gratefulness (and pleasant surprise) at the speed with which you responded to and properly fixed the problem -- I'd like to see some big commercial software vendors reply that quickly to an issue (I fear most of them would not), but just a minor follow up.
And Harald, I see that you're familiar with the data structure I'm using in the Datamatrix, eh? Well, I'm happy to have contributed in a minor way to the project by reporting the bug.
Thanks again for the support.
There is a test binary available at
https://sourceforge.net/projects/zint/files/zint/test/zint_2017-05-21.exe/download
which includes this fix, if this is useful, although this binary is not an "official" release.
In the meantime, thanks for this feedback - I will close the ticket.
Robin.
Thanks for the extra effort on the test binary, Robin. Have a good one!