Bug with aztec binary data?

[bonfus]

Thanks for this nice library! I'm encountering a weird behavior with the --raw-bytes option:

For qrcode, everythong as expected:

> ./rxing-cli test.png encode --width 200 --height 200 --data "aaa" qrcode
Encode successful, saving...
Saved to 'test.png'
>  ./rxing-cli test.png decode --raw-bytes
Detection result:
 97 97 97

for aztec:

> ./rxing-cli test.png encode --width 200 --height 200 --data "aaa" aztec
Encode successful, saving...
Saved to 'test.png'
> ./rxing-cli test.png decode --raw-bytes
Detection result:
 224 132 47

I don't quite get the origin of the numbers above (should be 97 97 97). The text representation is correct.

[hschimke]

I'll look into this

[hschimke]

What's happening is that the Aztec code is being returned with the raw bytes read from the symbol. That includes some control codes and packing done by the encoder to fit the symbols into the smallest possible shape.

My conception of "raw bytes" is the bytes encoded by the symbol minus error correction (in this case: [224, 132, 47]).

I'm going to have to look into what is happening with the qrcode, because I don't remember specifically why it is returning those values, but my guess is that they were encoded as bytes into the symbol. I'll double check though.

Does this make sense?

[bonfus]

That makes perfect sense. Notice that zxing-cpp behaves differently so maybe it's worth making this point clear (or maybe it's already in the doc that I didn't read so carefully! ;) )

[hschimke]

I'll look into it, because I think the behavior isn't consistent through the library. The binary output also may not be consistent between the different qrcode readers (there are two). I think there is an issue, primarily that the library isn't consistent. I'm going to reopen and flag it as a bug because it needs to be tracked and at least made consistent.