#307 DataMatrix Question Ver 2.6 versus 2.12

[Bill Brown]

I recently upgraded from Verson 2.6.0 to Version 2.12.0 to take advantage of your rmQR code. However, I noticed that my output for a Data Matrix barcode looked different from the output between versions. Used the same data for both "A1B2C3D4E5F6G7H8I9J0", tweaked each and every possible setting I could find, include ECI, binary mode, fast encoding, structured append, etc. Could not get them to match in terms of appearance.

I work for a printer company so our customers often care about "compatibility" and might complain that while their barcode scanner sees the same data, it does not look the same.

Is this difference expected or am missing something? I am using your windows applications to compare the output on both, see attached files.

[Harald Oehlmann]

2.6 encodes the following codewords:
230 88 88 40 8 107 147 59 67 126 206 78 126 144 97 254 129 28
ECC: 122 222 250 19 198 18 11 153 105 34 3 128 34 93
And decodes to: "A1B2C3D4E5F6G7H8I9J0"

So, it latches directly to C40 character set.

2.12 encodes the following codewords:
66 50 230 94 193 46 113 113 252 65 172 133 55 84 221 254 129 28
ECC: 80 81 50 147 211 47 29 48 245 96 91 225 133 217
And decodes to: "A1B2C3D4E5F6G7H8I9J0"

So, 2.12 encodes "A1" in ASCII mode and then latches to C40.

I don't understand, why this is done. We have revised the algorithm.
Both have 2 pad codewords, so the efficiency is the same.

Maybe look into this later.

Thank you,
Harald

[Gregory Van Vooren]

I ran into a similar issue (I suspect the same issue) when upgrading from 2.9.1 to 2.13 with the following symbologies:

• QR (ECC Level L, encodinng a GS1 digital link): https://id.gs1.org/01/12345678901231
• QR (ECC Level L): iubcp[nlnx<qv.cvnuoims

There was also a difference in rmQR but apparently there was a bug in rmQR generation in 2.9.1 as scanners weren't able to read those while this works with the rmQR generated in 2.13

[Git Lost]

Re Data Matrix differences, 2 changes occurred which affect encodation in the example.

One, introduced in 2.11.0, was to default to a (near) optimal algorithm (Dijkstra-based) for encodation. This can be overridden using the --fast option (API symbol->input_mode |= FAST_MODE, GUI "Data Matrix" tab -> "Fast encoding" checkbox).

The other change, introduced in 2.10.0, was to conform strictly with the ISO/IEC 16022:2006 standard regarding end-of-data for C40 encodation (section 5.2.5.2) which only stipulates using the C40 pad Shift 1 when 2 C40 values remain and 2 symbol characters remain. In the example, 2 C40 values remain but 5 symbol characters remain, so it now unlatches to ASCII to encode the final 2 characters. So e.g. 2.6 does:

<C40> A1B 2C3 D4E 5F6 G7H 8I9 J0<Shift1> <ASC> <PAD> <PAD>

whereas 2.13.0 (and 2.12.0) with "Fast encoding" checked does:

<C40> A1B 2C3 D4E 5F6 G7H 8I9 <ASC> J 0 <PAD> <PAD>

The latter is the same encodation as BWIPP. It differs from TEC-IT however, which uses the 2.6 encodation. Whether this matters is moot, but Zint strives for full conformance with international standards.

Re the default "non-fast" encodation, which as Harald points out is:

A 1 <C40> B2C 3D4 E5F 6G7 H8I 9J0 <ASC> <PAD> <PAD>

This doesn't result in any savings in this case, but does in other cases, for example "A1B2C3D4", which in fast mode is encoded as:

<C40> A1B 2C3 <ASC> D 4

and in default mode is encoded as:

<EDI> A1B2 C3D4 <PAD>

giving a saving of one codeword (the pad). Such savings can add up with large data.

Re Gregory's QR Code, this is a different issue. The change between 2.9 and 2.13.0 is due to different masks being used (from mask 0 to 7 for the GS1 digital link example, and from mask 5 to 4 for the 2nd example). The evaluation of which mask is best was tweaked in 2.10.0 I think.

P.S. Note 2.13.0 is the latest released version and I'd recommend using it over 2.12.0.

[Git Lost]

Thanks for the feedback Bill (and Gregory). Closing as answered.