No way to use Code 128 for exact replica of scanned bar codes

[gschwaer]

Hi,

When digitize bar codes, e.g., from loyalty cards onto a smartphone, we want to scan the code and later be able to display the exact same code on the screen. This is what the app Catima does.

For Code 128 bar codes three different sub-types/code sets can be used (A/B/C). The MultiFormatOneDReader/Code128Reader decodes barcodes to a string and also returns the raw data bytes (containing code set information). The OneDimensionalCodeWriter/Code128Writer encodes bar codes from strings. I couldn't find a way to generate a bar code from the raw data. When generating a bar code from a string, the Code128Writer determins the best code set to use on its own (in chooseCode(..)).

A problem arises (see here) when the code set that is used by the original bar code is not the "best" code set that could be used by the encoder. For example the original bar code might contain only digits, but uses an encoding that allows for characters as well (code set B). The Code128Writer will recognize that the string contains only digits and use the code set for only digits (code set C). This way the resulting bar code will contain the same data, but it will be encoded differently. We have to assume that some card reader only support specific code sets, so these bar codes will be unusable. This is also undetectable because the decisions on the code set (or raw output bytes) are not available to the caller.

Is there a way to make this work? Maybe a hint for the writer to force a specific code set? Or some kind of RawCodeWriter, which will generate bar codes from the raw data that was read. Or a way to access the raw bytes of the writer.

I hope somebody has an idea how we can make this work. Thank you for your time!

Gero

[Sean Owen]

Hm, usually it's a good thing that it selects the best encoding, but I understand your use case. I don't believe there is any hint to control this, but you could modify the code of course.

--
You received this message because you are subscribed to the Google Groups "zxing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zxing+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zxing/930fa99b-5397-477f-b988-fc03bf517390n%40googlegroups.com.

[gschwaer]

Hello, thanks for the fast response. I implemented a change here: https://github.com/gschwaer/zxing/tree/dev/force-code-128-code-set

It adds a new encoding hint `FORCE_CODE_SET` which allows to specify one of the code sets as string ("A", "B", "C"). Other values are ignored. I made the `OneDimensionalCodeWriter` stateful to store the hints on the call to encode, rather than handing it down through the functions until reaching the child writer class. If the hints are not used for encoding the state is reset to null to prevent side effects when reusing the same writer. I added a bunch of tests to check the forcing of code sets and the exception cases. The encoding can now additionally throw an exception if a code set is forced, but the given payload contains characters that are not encodable with that code set. In those cases the writer throws an `IllegalArgumentException`. All other and all new tests pass. Currently this patch is made against the 3.3.3 version of zxing, since this is what Catima uses, but I can also rebase it to the main branch and open a pull request.

Let me know what you think! Thank you!

Gero

[gschwaer]

For the record: This was reviewed and merged in https://github.com/zxing/zxing/pull/1411 and scheduled for 3.4.2 release.

Thank you!