#159 Row size input for PDF417

[codemonkey82]

This is possible to implement by changing the following codelines:

symbol->row_height[i] = symbol->row_height_input;
//symbol->row_height[i] = 3;

The row height array in the symbol structure needs to be changed to float, and we need a input variable for the rowheight:

float row_height[200]; /* Largest symbol is 189 x 189 Han Xin */
float row_height_input;

Will probably also work for microPDF.

[Harald Oehlmann]

Thank you for the proposal.
Why do you want row_height as a float ?
Is it important to you to have pdf417 row heights like 3.5 to make micro-adjustemnts ?

Row-height of PDF417 is fixed to 3 by the standard. What is your reason to change it ?

Thank you,
Harald

[codemonkey82]

Hi Harald!

Printer protocols often allow that option to be set. One example is the Zebra Programming Language (ZPL).

https://www.zebra.com/content/dam/zebra/manuals/printers/common/programming/zpl-zbi2-pm-en.pdf

Format: ^B7o,h,s,c,r,t

r = number of rows to encode
Values: 3 to 90
Default: 1:2 (row-to-column aspect ratio)
You can specify the number of symbol rows giving control over the height of the symbol. For example, with no row or column values entered, 72 codewords would be encoded into a symbol of six columns and 12 rows. Depending on code-words, the aspect ratio is not always exact.

That option is therefore very important for my work, but if 3 is the official standard, that should probably set used when nothing else is selected.

symbol->row_height[i] = symbol->row_height_input;
if(!symbol->row_height[i])
symbol->row_height[i] = 3;

[codemonkey82]

Regarding the float, you are completly right - I need it for precision. In the end, the content in symbol->row_height[] lands in a float variable in plot_raster_default in raster.c

If symbol->row_height[] is not float, the opportunity for this additional precision is wasted.

The parameter row_height_input could also be used for barcodes like CodaBlock, where the same parameter would be possible to set.

[Harald Oehlmann]

I don't feel very well allowing floats. The original implementation of PDF417 highly dependet on the 3 ratio. And float size is IMHO hard for decoding software, as this is surprising.
Well, it always happens due to optical reasons.

With Codablock F, it can be set and is independent and may be defined freely.

Just some thoughts,
Harald

[Robin Stuart]

Sorry, but I would be reluctant to make this change - I think it would be difficult and time consuming to ensure that symbols are properly formatted for all possible input values in all possible file formats.

[codemonkey82]

Alright, that makes sense. Zint always tries to ensure that the symbol is valid. ZPL instead only does what the user wants, but gives no guarantees that the symbol will scan. This is also the reason for my ticket about an option to replace errors with warnings in Zint. I appriciate your thoughts about this, and it is no big hassle for me to patch Zint in my application.