#202 Android app to fully decode PDF417 or other barcodes

[Michelle Dupuis]

I'm looking for a suggestion for an Android app that will fully decode a barcode (particularly PDF417). Of interest is:
1. Symbology (bar code type)
2. Content type (binary, text, etc)
3. Multiple types (does content/type change multiple times in the barcode)
4. Check digits, and are they correct
5. Leading/trailing characters (like + or A) if this is not returned with the decoded string

I already have one android app that provides minimal info, but hoping for more

[Michelle Dupuis]

Just to clarify, content type is actually "compaction mode", and check digits is ECC. Trying to use the right words :)

[Git Lost]

Hi Michelle, Zint is an encoding library and does not do decoding. Open source decoders that I know of are ZXing (Java) and its C++ offshoot ZXing-C++, both of which can be adapted reasonably easily to return as much info as you want.

[Michelle Dupuis]

I realize that :) In order to diagnose what I think is a Zint problem (with PDF417) I need a barcode reader that shows a lot of detail (most just decode and show the symbology and maybe compaction mode). I'm hoping someone in this project can recommend a great decoder...

[Git Lost]

The 2 mentioned are pretty good! I use ZXing-C++ and hack in various debugging info printfs to check stuff. If you like post the possibly problematic PDF417 here, either image or data, and I'll take a look at it...

[Michelle Dupuis]

I actually opened a ticket, but on Git Hub. I wasn't sure if one/both sites are used for bug tracking. I didn't want to double post in case that annoyed someone.

It would be great to find a good android scanner (since I sometimes scan a user's badge at remote site). I tried 3 different Android scanners and they're OK, but don't show developer level details.

[Git Lost]

Ok I see the ticket at https://github.com/zint/zint/issues/77 This is an old github fork which frankly I didn't know about and hasn't been updated since 2017. The up-to-date github mirror is at https://github.com/woo-j/zint, but here on sourceforge is the place to raise any issues.

I've looked at the examples you've posted, the "good" and the "bad", and put them through ZXing-C++ and both encode the same codewords, using the same encodation. The difference between them I imagine to be down to them using different "clusters" to encode the same codewords, though I'd need to do some more checking to confirm this.

I don't know what version of zint you're using but it's best to use the latest if possible (2.9.1 as of writing). Encoding "M6184590704189385" with ECC 2 and columns 3 using the latest version produces a different barcode again than those given on the ticket.

One thing that's obvious from the "good" and "bad" examples is that the "bad" example is fuzzy. Maybe it's an artifact of how you captured it but if not then any barcode that badly printed will cause scanners issues...

Re android scanners the 2 I mentioned can both be built for android according to their doc but I don't use android so won't comment further...

I'll keep investigating though as I'm interested in why the cluster usage is different (if indeed that's the case).

[Git Lost]

lol managed to put two different versions of the same image (the "good" one) twice through ZXing-C++ above - the 2 barcodes actually encode different data.

The "good" one:

numECCodewords: 8, error 0
Codewords (18): 10 913 77 902 27 367 784 578 10 385 798 506 904 873 743 681 804 652 
 1: 913  MODE_SHIFT_TO_BYTE_COMPACTION_MODE "M"
 3: 902  NUMERIC_COMPACTION_MODE_LATCH "6184590704189385"
Text:     "M6184590704189385"
Format:   PDF_417
Error:    NoError
EC Level: 2

The "bad" one:

numECCodewords: 8, error 0
Codewords (18): 10 900 77 902 27 367 784 578 10 385 779 118 134 857 47 845 115 598 
 1: 900  TEXT_COMPACTION_MODE_LATCH "CR"
 3: 902  NUMERIC_COMPACTION_MODE_LATCH "6184590704189385"
Text:     "CR6184590704189385"
Format:   PDF_417
Error:    NoError
EC Level: 2

(so nothing to do with different clusters)

[Michelle Dupuis]

WOW....so I was using "QR Code Scanner" for android which decodes the number with prefix "CR" . So I tried using "Barcode Scanner" for android it it decodes the number with prefix "M". Any chance the ascii value is 13 which is control-M, or interpreted character "CR" (carriage return). Just looking for how a scanner can make such an obvious mistake.

I suppose this underscores the importance of using a good scanner! (Staying on topic). Thanks for finding that!

[Git Lost]

Yes in text compaction mode 77 = (2 * 30 + 17) = "CR", and in byte latch mode 77 = ASCII = "M", so if the scanner didn't properly parse the mode switch it could easily make that mistake.

Glad that it helped (eventually), let us know if this lets zint off the hook so the ticket can be closed, thanks!

[Michelle Dupuis]

Please close - not a zint issue. (Good lesson for anyone testing barcodes - try multiple scanners) Thanks