-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug with aztec binary data? #47
Comments
I'll look into this |
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? |
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! ;) ) |
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. |
Thanks for this nice library! I'm encountering a weird behavior with the
--raw-bytes
option:For qrcode, everythong as expected:
for aztec:
I don't quite get the origin of the numbers above (should be 97 97 97).
The text representation is correct.
The text was updated successfully, but these errors were encountered: