[?] created aztec code does not *visually* match scanned one

[symbolisch1234]

Using PassAndroid 3.4.0 (F-Droid) on Lineage 14.1 (Android 7.1.1) on Xperia M.

---

I take an AZTEC code from DeutscheBahn Ticket (like this one: https://d33v4339jhl8k0.cloudfront.net/docs/assets/530b1935e4b0479ea072e7c5/images/580aab5dc6979105d8636675/file-73GgHfG7lQ.png ) and scan it using the Android Barcode scanner. The scanner returns an encoded string.

I copy-paste this string to PassAndroid's "Create Pass" > "Add Barcode" feature.

If I now scan this Passbook with the Android Barcode scanner it gives me the same encoded string.

However, I would expect this to be the same AZTEC code as on the ticket. On the contrary, the codes are very obviously visually different. Am I missing something obvious about the aztec format? Or is there something wrong here?

[symbolisch1234]

I just used my self-created (and visually different) AZTEC codes, and three different DeutscheBahn conductors scanned and accepted them without any complaints.

So while it still is strange, this is not a bug in the sense that it impedes usability. the visually different AZTEC codes are functionally identical. dear @ligi , if you please you can close this issue

[ligi]

Thanks for the follow-up - but I let this ticket open for now as I want to understand what is going on there. Might also confuse other users. Looks like AZTEC is not deterministic then - but perhaps we get it to behave better in some situations.

[symbolisch1234]

I have read up a bit on this. While I am by no means an expert, I strongly believe the difference comes from different configuration values for the Reed-Solomon error correction. It seems that DeutscheBahn uses a different amount of error correction than the default set by PassAndroid (or more likely zxing).

Background: https://en.wikipedia.org/wiki/Aztec_Code#Structure and http://www.adams1.com/patents/US5591956.pdf

[ligi]

Thanks for the follow-up - interesting & sounds reasonable

[reinhart1010]

I strongly believe the difference comes from different configuration value for the Reed-Solomon error correction.

This is definitely correct, and also reproducible in other 2D barcodes. Here, PassAndroid seems to generate QR Code with correction level M though the original, scanned QR was encoded with correction level L.

[reinhart1010]

There might be some systems which takes correction levels for validation, so the app should generate 2D codes with exact correction levels as the original.