#57 Enhance matrix size choice for Datamatrix

[Harald Oehlmann]

IMHO the Data Matrix size choice may be reviewed.

The current behaviour is as follows:

• A size is given (--vers 1): The given size (in this case 10x10) or a bigger size is chosen, depending on the data. E.G. "zint -b 71 --vers 1 -d 12345678" results in 12x12 matrix image
• Automatic modes are with any format, only square, or square and rectangular (without dmre)

IMHO, the practical use cases are:

• Specify exactly one format. If the data does not fit, throw an error. The target layout and reading infrastructure is fixed to one matrix size (like the Stamp machine code)
• Use automatic mode with square symbols (a given square form should be filled with a code)
• Specify the height of a symbol, the width is chosen following the data (Code height is limited by field size (side of a drug package) or by printing technology (continuous inkjet)

What do you think about the following changes:

• If an exact version is given, throw an error if data does not fit.
• Keep the automatic modes as they are.
• Define a height constraint mode for sizes, where rectangular formats exist.

Any comment welcome,
Harald

[Milton Neal]

Harald, I agree fully that if you specify a symbol size and the data does not fit then throw an exception. After all if you specify a size then that is what you expect, you have obviously selected a specific size for a reason, you don't want the software doing something in the background that your not expecting.
Automatic mode is great, I think it is needed and has its place in any 2D barcode that can support it.
A height option can have it's practical advantages, I was thinking about the options limitations of Zint. Is another "option" available without changing the Symbol structure?

[Harald Oehlmann]

Milton, thank you for the contribution.

Current automatic mode

For me, the issue with the current automatic mode is that you might expect a square symbol, but you get a rectangular, because the current data just fits into this size exactly.
You can just type-in characters in qzint and you will see square and rectangular formats interchanging in automatic mode.

Wether I want a square automatic symbol or a height constrained one.

Height constrained mode

Height constraint example: you have a print height of 12 modules. Choose 12x12 for small data amound and 12x26 or 12x36 for higher data amount. Throw an error, if there is to much data for one of the three formats with height = 12. With DMRE, the situation will get different, as there will be additional rectangular formats. A DMRE revision will probably propose 12x144, so a very rectangular symbol.

Option design

Currently:

• option_1: unused for Data Matrix
• option_2 : --vers, code size and automatic mode (0)
• option_3: --square (value 100), --dmre (value 101)

Design proposals:

One may add option values for height restraint codes. There are maximum 5 of them: (8,12,16,24,26). But the option might be in combination with the DMRE option.
So, there might be:
a)
option_1: wished height
option_3: --height_constrained (value 102) and --height_constrained and --dmre (value 103)
b)
option_1: unused
option_3: new values:
102: height constrained to 8
103: height constrained to 12
104: height constrained to 16
105: height constrained to 8 + DMRE
106: height constrained to 12 + DMRE
...
109: height constrained to 26 + DMRE

[Robin Stuart]

Hi,

Can I get clarity on what you are thinking about the automatic resizing? If using the API Zint will send back a warning ZINT_WARN_INVALID_OPTION if the data does not fit in the specified symbol size. This should be easy to pick up in the API but is currently ignored in the CLI and GUI. Do you think there should be an option to escalate these warnings to errors, or do you think that default behaviour should be to throw an error and stop in this situation. If the latter then this will need to be changed for many symbologies, not just Data Matrix.

With reguards to the option design I think this is a good idea but I suggest managing it with option_1 as the wished height as you suggested, but with option_3 we change the values in zint.h from

DM_SQUARE = 100
DM_DMRE = 101

to

DM_SQUARE = 2;
DM_DMRE = 4;
DM_SETHEIGHT = 8; // Or some other suitable name

Then API users can use the syntax

symbol->option_3 = DM_DMRE + DM_SETHEIGHT;
symbol->option_1 = (desired height);

rather than having yet another table of input values in the manual.

Obviously we would need to check for the user doing

symbol->option_3 = DM_SQUARE + DM_DMRE;

...but that would just be an if statement which throws ZINT_ERROR_INVALID_OPTION.

Robin.

[Harald Oehlmann]

Robin,
Thank you for the insights.

Current automatic mode

I was not aware, that the API sends a warning when the size is not correctly honored.
I think that is o.k.
I suppose, it would be a good idea to have this also in the command line (as possibility), as it is often used as automation tool. For the GUI-Version it is less important but IMHO strange.
I will open an extra ticket for gui and command line tool to (add an option to) respect chosen sizes.

Height constraint mode

You did not comment on this.

Option design

Thank you for the proposal to use a bit-field style.
This is o.k. It is not backward-compatible but the improvement is IMHO better.

I have another idea to eventually keep option_1 free:

DM_SQUARE = 2;
DM_DMRE = 4;
DM_SETHEIGHT = 8; // Or some other suitable name

Then API users can use the syntax

symbol->option_3 = DM_DMRE + DM_SETHEIGHT;
symbol->option_2 = a standard matrix, which is taken as minimum, and where the width is extended, if space is required;

So, in the "DM_SETHEIGHT" mode, a standard matrix is chosen in option_2.
Example: A 12x18 is chosen in option_2

The search conditions are:

• Same height as given height (e.g. 12)
• The smallest width for the given data, but at least equal to the given width (e.g. 18)

What do you think ?

[Robin Stuart]

Re: Current automatic mode

Okay, I will look at implementing this. Shouldn't be too difficult.

Re: Height constraint mode

I see how this could be useful so I think adding it is a good idea.

Re: Option design

Again yes, I think that's a good way forward. I think the backwards compatability issue is likely to be minor. We'll have to think carefully about how to clearly document this, however.

Robin.

[Robin Stuart]

Concerning automatic mode...

The plot thickens... It seems as if Zint is not consistent with how it handles this. Aztec seems to simply throw an error and quit as Milton suggests, Data Matrix throws a warning, QR Code does nothing at all, so perhaps a change of strategy is in order. I will go through and make all symbologies throw an error.

[Harald Oehlmann]

Fix chosen matrix size mode

I also think, it would be good to always throw an error, if the data does not fit into a size selected by the user.

Height constraint mode

I see how this could be useful so I think adding it is a good idea. (Robin)

Please look to https://www.dmre.info/ , section "Use-Cases for extended Data Matrix Rectangular formats", for use cases.

I may also implement the Height Constraint Mode. But I admitt that I don't know now, how to integrate it into qzint.

[Harald Oehlmann]

Commit [5acbff] 2017-04-11 fixed the error issue.
Rectangular grow mode is not implemented, what is ok.
Close the ticket