PDF417 barcode generation bug

[albuic]

The generation of PDF417 seems to be buggy when using line break characters.
You can test the difference between the app and another generator like https://barcode.tec-it.com/en/PDF417?data=hello%0Ahere
It might be a bug in the zxing library but I did not find anything about it on here: https://github.com/zxing/zxing/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+pdf

Otherwise it might be the difference between linux and windows line break encoding: LF vs CR+LF
In that case a checkbox to select the type of line break (per barcode) might be needed.

For information, the 7Eleven stores in the US use this type of barcode for their loyalty cards (named 7Rewards program) and the generated barcode on the 7Eleven card is the same as the one in the URL above.

(Really nice App btw ;-) )

[brarcher]

Hm. Looking at the barcode generator you referenced I do see that the barcode reported by the app is different. It believes the text is the same, though.

I created a card by capturing the 'hello%0Ahere' example, then exported the cards and looked at the strings with xxd. The following is the string as the app understand is:

6865 6c6c 6f0a 6865 7265 hello.here

which means it did correctly capture and encode the LF character.

Could you take a look at the xzing test app on the Play Store and see if the issue is there as well? That may help limit where the issue is.

It might be that there is some additional argument that needs to be passed to the xzing library when generating PDF417 barcodes, and I'm not aware of it.

[albuic]

I tried their app but it cannot generate that barcode unfortunately !
One thing I did not mentioned is that all Apps decode any barcode correctly, the problem is only the barcode generation.

Edit: Just tried SecScanQR (https://github.com/Fr4gorSoftware/SecScanQR) and it also has the same problem when generating the barcode. And you both use the same library 😉