* Update Decoder.java
* Add files via upload
dlusbs.png and dlusbs.txt is a test case for the D/L [digit] U/S B/S sequence, which should end in Upper mode, not Digit mode
* Update number of test cases
* Comment logic of the fix
* Mention fixed issue #642
* Simplify code in bit-twiddling methods, using APIs introduced in Java 5.
* Align code by adjusting whitespace and adding `+0`.
* Convert qrcode DataMask to enum to reduce source code size, which shouldn't change behavior.
* Simplify lists of character constants using string initializer instead of array.
* Remove redundant `+ 0` operations from a recent change.
* Delete the function DataMask.forReference() and inline the logic into all its callers.
* Fixed bug #593
Bug #593 was misleadingly reported as pertaining to another project, but
testing revealed it affected this project as well. The Code128 encoding
algorithm failed when an odd number of digits were followed by FNC1 and
other digits. The code selection algorithm was rewritten. A test case
showing the bug was added, and an old test case was updated to expect
the result of the new algorithm - another valid encoding of the same
length as the old one.
* Fixed bug #593
Bug #593 was misleadingly reported as pertaining to another project, but
testing revealed it affected this project as well. The Code128 encoding
algorithm failed when an odd number of digits were followed by FNC1 and
other digits. The code selection algorithm was rewritten. A test case
showing the bug was added, and an old test case was updated to expect
the result of the new algorithm - another valid encoding of the same
length as the old one.
* Cleaning up
Added a private enum and changed some names to improve readability.
Also some trivial cosmetic changes.
* Further cleanup of Code128 writer test
Removed a private one-liner method used exactly once, alphabetized
imports.
* Simplify conversion RGB -> luminance
Removed testing every pixel for greyness in RGBLuminanceSource, as it
did not appreciably change the speed of converting a greyscale image and
slowed down the conversion of a colour image by a few percent. Besides,
there was no need to treat every row separately; the total number of
pixels was enough.
* Minor improvements to BitArray
Simplified some code, added more accurate error checking, and corrected
small inaccuracies in comments.
* Fixed bug #593
Bug #593 was misleadingly reported as pertaining to another project, but
testing revealed it affected this project as well. The Code128 encoding
algorithm failed when an odd number of digits were followed by FNC1 and
other digits. The code selection algorithm was rewritten. A test case
showing the bug was added, and an old test case was updated to expect
the result of the new algorithm - another valid encoding of the same
length as the old one.
* Fixed bug #593
Bug #593 was misleadingly reported as pertaining to another project, but
testing revealed it affected this project as well. The Code128 encoding
algorithm failed when an odd number of digits were followed by FNC1 and
other digits. The code selection algorithm was rewritten. A test case
showing the bug was added, and an old test case was updated to expect
the result of the new algorithm - another valid encoding of the same
length as the old one.
* Cleaning up
Added a private enum and changed some names to improve readability.
Also some trivial cosmetic changes.
* Further cleanup of Code128 writer test
Removed a private one-liner method used exactly once, alphabetized
imports.
Following Sean Owen's suggestions, I cleaned up my code in the Aztec
decoder and its tests as follows:
1. Made convertBoolArrayToByteArray() package-private.
2. Replaced my own assertEqualByteArrays() with existing
assertArrayEquals().
3. Replaced C-style array declarations with more Javaish ones.
The Aztec decoder now packs the code bits into bytes and returns them as
"raw bytes", even though the error correction codes and stuffing have
been already removed. Also added a couple of tests for the byte-packing
function.
Some barcode generators (e.g. Okapi) seem to generate additional barcode
rows at the end of the barcode, which can be decoded as valid barcode
rows, but actually contain garbage. The barcode metadata states that
these additional rows are not part of the barcode. So we ignore those
addional rows when parsing the barcode. This could potentially also
happen (though quite unlikely) if data after the barcode looks like a
barcode row.
