I hava an application that make PDf417 in binary mode, it is save on my database, print it, and them the barcode is readding and compare with the barcode on database.
And i'm finding some cases that the barcode readed is not the same that de barcode saved.
i'm trying to debug this possibles error, how i describe follow:
1. An java class that read an binary file (example_00000011.dat) to byte array (686 bytes)
2. Byte array is converted to string with cp437 charset
3. I make an barcode PDF417 image with barcode4j library and save it on file.
4. I try to read this image with other software (clearImage, IDautomation, for example...) and Symbol DS6707 barcde reader device too and always i read the same: an byte array that is different fo my database byte array on bytes numbers 193,194,196 and 197.
Then we would assume that the error is on barcode4j codification and generation PDF417 code.
thank you very much for read this message and sorry for my english.
Binary data
Image generate with barcode4j
Bytes readed with clearImageSDK PDF471 decoder
Java test code
I can see that there are some differences. I've now spent more than 5 hours tracking stuff down. But so far Barcode4J still looks good IMO. On the other side, I found 3 bugs in ZXing. ZXing was the only barcode decoder I could debug in to see what happens on the decoding side and to isolate potential problem spots. I've isolated a little passage of your message to make it easier to debug. I'm using:
00000000 21 82 9F 09 21 1A 45 F4 09 35 2F 44 3F 09 3F 9A !...!.E..5/D?.?.
00000010 46 5A 09 63 27 82 FF 09 6D 15 41 C9 09 A0 23 46 FZ.c'...m.A...#F
(this is 32 bytes starting at index 176 in your file)
I've also scanned the symbol generated by Barcode4J with bcTester, Axtel Barcode Demo and my Metrologic Focus 1690. Both bcTester and Axtel seem to report the exact data you supplied in the "bin" file. The hardware scanner had quite some differences (except with the smaller example which looks ok), but not the ones you mentioned. Frankly, I'm not yet convinced that Barcode4J is really at fault here.
I don't know how to resolve this right now. I've gone through a subset of your data with the PDF417 spec on the side and what B4J does looks good to me. Of course, I may misinterpret some of the spec but the scanner developers could just as well, as I was able to show in the case of ZXing where I'm not going to post a bug report. Anyway, I cannot invest more time at the moment (free/fun time is spent).