#350 accept pre-encoded GS1 data

[Mario Verbruggen]

I have a use case from our customers when we submit pre-encoded GS1 data:

• parenses / brackets are resolved around AIs
• x1D character is added after variable-length data fields, except as last data field
  Currently ZintLib returns error code 251, while data is GS1 compliant.
  I am new in open source community and I have created a solution in my local zintlib repo.
  What are my next steps to solve this?

[Harald Oehlmann]

Are you aware of this syntax (manual, page 58):

zint -b 16 --gs1parens -d "(01)98898765432106(3202)012345(15)991231"

Then, you only need to ignore any included gs. Perhaps, you do a pre-processing by removing all "gs"...

Take care,
Harald

[Mario Verbruggen]

The use case is as followed:
pre-encoded data = 0108033196601203215dqshh(D)h/VT91EE11926FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw=
and should give following AIs
[01]08033196601203
[21]5dqshh(D)h/VT
[91]EE11
[92]6FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw=

Between ..VT91.. there is a x1D character and also between ..1192..

with kind regards,
Mario

[Harald Oehlmann]

Thanks, for this use-case the --gs1parens is not suitable.
You may use plain Data Matrix with a verbatim FNC1 at the front.

Nevertheless, the data is IMHO not unique. At the end of [21] data, there must be an information to include a FNC1/GS.
I don't see that.

Is it me?

THanks for all,
Harald

[Git Lost]

Hi Mario, you can actually do this for Code 128 with the option --extraesc and using"\^1" for FNC1s instead of literal <GS>s. The data must also be prefixed by "\^1" to indicate GS1 mode, e.g.:

zint -b CODE128 --extraesc -d "\^10108033196601203215dqshh(D)h/VT\^191EE11\^1926FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw="

Note the use of CODE128 (20) not GS1_128 (16) as GS1-128 expects bracketed data. Also zint will not verify the data as valid GS1.

If this doesn't suit and/or you prefer your solution then the thing to do is to create a Merge Request , which would be most welcome. Or you could discuss it here before making the Merge Request.

Currently only Code 128 supports manual FNC1s, though there are plans in the fairly short term to extend it to all other barcodes that can encode FNC1s.

There's also a GS1 Syntax Engine syntax which is quite nice, using a simple caret (^) to indicate FNC1s, e.g. "^10108033196601203215dqshh(D)h/VT^91EE11^926FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw=" which zint could be modified to support and would allow verification.

Regards, Martin

[Mario Verbruggen]

Hi Martin, Harald,
The customer of our customer specified that DataMatrix shall be used . So Code128 is not an option.
The sample code I provided didn't start with FNC1 and uses GS as separator. So in a manual mode, I call it pre-encoded or raw data, Zint and other encoders does not create a GS1 compliant DataMatrix (without manipulating customer data).
In my opinion there are a few solutions:

1. Add FNC1 start character to the raw data and use a regular DataMatrix. This has a downside, there will be no validation of data. And from a user perspective confusing: using DataMatrix to generate GS1 DataMatrix
2. If data is GS1 compliant, without brackets/parentheses and contains GS or FNC1 as delimiter for variable-length data fields, thread it as GS1 data
3. convert data back to a Human Readable format
   In the short term we are implementing option 3. Option 2 could be benificial for Zint to make it more robust and still be GS1 compliant.
   With kind regards,
   Mario

[Git Lost]

Hi, implemented option 2, with GS as the FNC1 stand-in, hidden behind the input_mode flag GS1RAW_MODE (CLI "--gs1raw") with commit [9ef5bc] (bug fix -initially [0a8a79] ). Also implemented the GS1 Syntax Engine "Unbracketed AI" caret mode I mentioned, triggered by an initial caret.

They're documented in the manual in Section "4.11.3 GS1 Data Entry and Options" .

Any testing or feedback would be most welcome, regards, Martin

[Git Lost]

Hi, yes, option 2 sounds good for GS1 data. Will give that a go. Will initially accept GS as a separator.

I also like the GS1 Syntax Engine "Unbracketed AI element strings" using carets. This has the advantage of being a recognized GS1 format, and as the code to parse the AIs is basically the same as option 2, will probably implement at some stage.

Option 1 is useful for scenarios other than GS1 also, so will be implemented at some stage.

Thanks for the feedback, Martin

[codemonkey82]

Hi Martin,
Just as info. This feature would be very convinient for me too:

"Currently only Code 128 supports manual FNC1s, though there are plans in the fairly short term to extend it to all other barcodes that can encode FNC1s."

For context: I have gotten this abomination from a customers site:

"^FD>;>80014009895220145656910>600326316^FS"

It begins in GS1 in subset C, but then switches back to subset B while still using GS1. I have never seen this before, but I will have to support it at some point in the future, when the old machines are being thrown out and replaced.

I want to use the same logic in the firmware for all GS1 barcodes. Therefore, it would be nice to manually put FNC1 - and other such characters - in both Code128 and Datamatrix. I would then no longer use the brackets for the GS1 barcodes.

Best regards,
Henrik

[Git Lost]

Hi, nice to hear from you again. Good to hear - Data Matrix is first on the list!