Does ZXing support GS1 128, GS1 Datamatrix & GS1 QR code barcodes

[Navin]

Hi,

Does ZXing support GS1 128, GS1 Datamatrix & GS1 QR code barcodes?

Regards

Navin

[Sean Owen]

Yes, in the sense that the "GS1" barcodes are no different than the "non-GS1" barcodes. At the format level there is no difference from Code 128, Data Matrix, QR code.

The GS1 bit refers to an interpretation of the contents. There is no special handling of that but the caller can of course parse it as desired.

[Chris Bahns]

Sean, could you please post an example of a GS1 Datamatrix that is encoded by ZXing library and is decoded properly by another tool? Decoding tools typically have a "GS1" status that clearly indicates that the code is GS1 compliant.

Note: I am not an expert in the underlying encoding technology, but I have used it enough to know that if the decoder does not specifically state that it is GS1-formatted, then it probably is not (even if it looks like it should be).

I am using bcTester 5.0.0 (http://www.bctester.de/en/home.html). This programs shows a "Warning: In case of GS1-Data Matrix..." when it reads a GS1 compliant code. Read a non-GS1 code with essentially the same content, and you will not see this warning. Other tools do similar things to tell you that it is GS1.

[Chris Bahns]

Here is an example that DID NOT work for me.

Desired Code Content: "(21)123(20)12"
Encoded Content (expected): {E8}21123{1D}2012 (11 bytes)

Where "{E8}" is ASCII 232 and "{1D}" is ASCII 29. These are the FNC1 characters.

I have attached four codes created by three libraries...
Renderer A: our own internal library, which we need to replace
Renderer B: Matrox code generator library, which we cannot use for production
Renderer C: ZXing 0.14.0.1 for .NET 2.0 (see version file attached)

The "A" and "B" libraries both produce codes with the expected content and reported as GS1-compliant by both bcTester and Matrox code reader. The two "C" (ZXing) examples have content that essentially matches the desired result, but both code reader tools do not report these codes as being GS1-compliant.

In the end, I have this question: What is the input to ZXing that is required on a Data Matrix to get an external decoder to report it as GS1-compliant?

[Bas Vijfwinkel]

> Where "{E8}" is ASCII 232 and "{1D}" is ASCII 29. These are the FNC1 characters.

In a glimpse I notice that these characters don't get encoded as expected.
The other characters seem to be correct.
I'm sorry but I don't have a working setup of ZXing to play around with but as
you mention, it just seems to be the way that the input gets encoded causes the 'incompatibility'.

[Chris Bahns]

> It just seems to be the way that the input gets encoded causes the incompatibility'.

So is this a ZXing defect that must be fixed? Is there another way to provide the same input, which will have the desired result (without the incompatibility)?

[Ben Mead]

On Tuesday, February 2, 2016 at 11:18:42 AM UTC-5, Chris Bahns wrote:
> > It just seems to be the way that the input gets encoded causes the incompatibility'.
>
> So is this a ZXing defect that must be fixed? Is there another way to provide the same input, which will have the desired result (without the incompatibility)?

For compatibility that matches GS1-128, two things must be true. Lack of 1) is probably an issue where we need a new feature. 2) is probably a bug, where we need to enable the feature used in GS-128 for Datamatrix. The two extensions to simple Data Matrix that we need are as follows:

1) The symbology identifier must be "]d2" for GS1 in both levels of compatibility.
2) We need an escape code, for instance the commonly used ^FNC1, that translates to {1D} (Ascii 29, the group separator as explained above) in the Data Matrix bar code.

Those two would provide the ability to generate an equivalent Data Matrix bar code, but some sort of GS1 awareness to translate the readable GS1 string into Data Matrix would be nice. If there's interest, I could probably create a patch on some time scale.