* Aztec encoder: add ECI codes according to character set
Added redundant methods to avoid modifying existing tests.
* fix testAztecWriter
- ISO-8859-1 cannot actually encode Euro symbol ('€'); this test case only
passed before because the Decoder wasn't actually doing the bytes→String
decode, but simply round-tripping an unknown byte.
- Add extra test cases for implicit ISO-8859-1 (without ECI code), explicit
ISO-8559-1 (with ECI code), and Shift_JIS
* remove unnecessary conversion between String and byte[] in Aztec EncoderTest and DetectorTest
* Aztec DecoderTest: use constants for charsets
* Aztec Code: remove unnecessary conversion between Charset and Charset.name() strings
* PDF417, QR, DataMatrix: remove unnecessary conversion between Charset and Charset.name() strings
Includes replacing StringUtils.guessEncoding() with .guessCharset(), to return
Charset rather than String.
This change makes the tacit assumption that Shift_JIS charset *will* be
available. There are existing comments suggesting that it might not always
be available… but the existing *tests* assume it will be.
* decode Aztec FLG(n)
Per https://en.wikipedia.org/wiki/Aztec_Code#Character_set,
FLG(0) → FNC1, FLG(1-6) → ECI identifier
Decode FNC1 as 0x1d (ASCII escape character; same as Code128,
DataMatrix, others)
Not doing anything with ECI yet, but this at least fixes
the mis-synchronization of the bit stream that comes from
ignoring the bits that follow it.
* include ecLevel (percentage) in DecoderResult for Aztec
* Aztec decoder: follow character set indicated by ECI codes
Modeled on PDF417's DecodedBitStreamParser
* add testAztecResultECI and testHighLevelDecode to aztec.decoder.DecoderTest
The latter includes non-ECI, ECI, and mixed test cases.
* Make MultiFinderPatternFinder a public class
* Make MultiFinderPatternFinder constructor public
Co-authored-by: Gerard Finol <gfinol@color-sensing.com>
