Re: Aztec code generator [PATCH]

[Sean Owen]

OK... what's the patch? I think the RS generator is correct or else nothing would really work. There is one source, the ISO spec. The rest, I don't know without seeing what you mean.

[Rustam]

By source I mean ISO specs for different formats, they specify RS algo differently.

But OK, not really bugs, more opportunities for improvement. :)

Identified and fixed the following:

- The RSEncoder worked only for QR code.

- The "noError" shortcut in RSDecoder sometimes didn't work on Aztec codes, getting into the euclidian solver unnecessarily.

- The RSDecoder had some barcode-specific workarounds (shouldn't the RS algorithm be universal?)

Also:

- RS code is now exercised thoroughly to verify the key error-fixing capability up to X/2 words for X check words.

- Added Aztec Encoder. Supports compact and full symbols.

Further improvements:

- pom.xml - specified java version as 1.6 instead of 6 - for Maven doesn't matter, but mvn eclipse plugin supports only 1.6 notation.

- Added ImageWriter class for quick PNG and GIF writing to a file or byte array

Disclaimer: this is very very alpha. I use it to generate fairly small symbols, which seems to work fine. Large symbols are mostly untested except for the encode-decode round-trip which seems to work OK.

[Sean Owen]

The Aztec encoder changes are a lot to digest, but that would be a great addition I imagine. This is your own work -- or at least derived from source code that's Apache-licensed? I want to make sure the provenance is OK.

I'm OK on the Maven change though it's a shame about the eclipse plugin.

I'm not sure about the RS change. Reed Solomon describes a general algorithm that just requires a field, an irreducible poly over that field, and some points to evaluate it at in a certain order. Varying any of those gives a "different" RS process. Do the changes still allow all the QR code and DM tests to pass as well as Aztec? whatever it is seems to work so would have to be a generalization.

There's already an MatrixToImageWriter class which may do the same thing as the image utility class.

[Rustam]

The Aztec encoder is entirely my own work, it is written from scratch for my project, using only public information and the ISO standard. I've licensed it Apache-style so it is usable in your project.

The updated RS code of course works with all 3 barcodes, feel free to have a look at the completely rewritten unit tests which clearly verify Aztec, QR and DM modes of usage using real-life data. Yes the RS algorithm is specified with 2 parameters in literature, but as I said due to differences in how different barcode standards define the generator poly, one extra parameter is needed to keep the algo reusable for all three (and any future) barcodes. If you had 3 separate implementations, each one would only need two parameters. But since you try to reuse one implementation, you end up with if-QR, if-DM statements in your code which doesn't really add clarity IMO.

[Sean Owen]

I'm looking at this patch now. The core changes look strong; it needs a little work to fit the code style of the project but that's easy.

Is ImageWriter needed if MatrixToImageWriter already exists? I'd rather avoid duplication.

I'm going to need to look at the unit tests more. It looks like they were mostly overwritten, and that gives me less confidence that the change has not affected behavior -- though it may indeed be fine. There are some minor changes I may have to understand better too.

[Sean Owen]

Nevermind, I understand the rest. It looks strong. I'm going to omit ImageWriter for now as it's not strictly needed. I'll add you to AUTHORS too.

[Rustam]

Sorry I didn't see your posts earlier. Glad its sorted out and the changes made it into the project :) Can't wait until a new version is released!

The ImageWriter isn't really needed, as it duplicates the existing MatrixToImageWriter.

There are still some opportunities for improvement, for example, table switching could be optimized by looking ahead more than one character, and the amount of error check words can be made configurable; the Aztec Encoder does accept it as a parameter (as in encode(byte data[], int minECCPercent)) but the writer interface doesn't support it so currently a default amount of 33% will be used. Maybe the EncodeTypeHints mechanism can be improved to support integer hints.

[Rustam]

Oops, just realized that EncodeTypeHints isn't limited to boolean hints. In fact the first two hints are directly applicable to Aztec codes - ERROR_CORRECTION and CHARACTER_SET.

Attached a patch that makes AztecWriter honor these hints!

[Sean Owen]

Looks good, I'll commit.