GS1 North America Coupon limited scaling options

[Jaimeman84]

Hello,

We are working with GS1 North America Coupon and we need to scale down scaleY somewhere between 1 and 2 but it is not working as expected or as we think it should work. Does scaleX and scaleY take decimals?

Based on the behavior that we see, scaleY=1.5 does not increase the size of the bars/rows, but instead, it increases the padding between the text and the barcode. Could you please look into it or tell us if we are missing something? Refer to the image below...

Thank you in advance!

[metafloor]

Very odd behavior. The bar code scales correctly i.e. width is x2 and height is x1.5, but the location of the text does not change between scaleY=2 and scaleY=1.5. This is clearly a bwip-js issue (the BWIPP online demo gets it correct).

Going to require some low-level debugging of the cross-compiled postscript to understand where the coordinate mismatch is coming. That will take some time and unfortunately, I am out of town until Tuesday. Should have it resolved in a day or two after that.

[terryburton]

Hi @metafloor. I think you're doing something special with the scale options as the behaviour of BWIPP is different - but broken in another way. (I've only recently added text support to the matrix renderer which reacts to the height option by scaling, thereby stretching the text.)

Nevertheless @Jaimeman84, are you really looking at scaling the image (resulting in stretched text?) or are you just wanting to amend the height of the bars? If the latter then you probably want the barxmult option, e.g. barxmult=17. This isn't documented because when I last checked it was a violation of the GS1 DataBar specification.

[metafloor]

Hi @terryburton, you are correct. The bwip-js renmatrix is based on the old imagemask version as the new path tracing creates serious performance issues. I back-ported your initial text rendering in renmatrix and apparently need to take a look at the changes you made. I have a goal to be able to run the new renmatrix but need time to improve the graphics primitives, especially scanline fill.

[Jaimeman84]

@terryburton we want to modify the height of the bar without stretching the text so barxmult is probably what we want. We want the height as the image on the right (light blue).

What type of violation are you referring to?

This isn't documented because when I last checked it was a violation of the GS1 DataBar specification.

Thank you for your prompt response!

[terryburton]

The relevant standards specify that the height of the bars shall be 34X.

North American Coupon Application Guideline:

5.4 SYMBOL METRICS
The nominal X-dimension for this application shall be 0.0130 inch (0.33 mm). If a specific application requires, the X-dimension may be as small as 0.0100 inch. (0.254 mm) or as large as 0.013 in. (0.33 mm).
The nominal symbol height, as well as the minimum symbol height, may provide a square aspect ratio for each symbol segment. The symbol may be stacked in two to eleven rows. Each row shall be 34X high, and the separator pattern shall be 3X (minimum) high.

ISO/IEC 24724 GS1 DataBar Expanded specification:

RSS Expanded may be stacked in two to eleven rows. Figure 12 illustrates a two row symbol. RSS Expanded Stacked is used when the symbol area or print mechanism is not wide enough to accommodate the full single row symbol. Each row is 34X high with a 3X separator pattern between the rows.

I was unable to find any application specific guidance that amends these constraints when I last looked.

[Jaimeman84]

Terry,

Thank you so much the information. It has been very helpful!

[terryburton]

@metafloor Is the performance hit mostly with your graphical rendition or does my tracing code sting also? There is theoretically a simpler version of my code that does not require an intermediate matrix to track enclosed regions but I ran out of time getting it to work so committed what I had.

"I didn't have time to write a short letter, so I wrote a long one instead." ― Mark Twain

[metafloor]

@terryburton: It is mainly the graphics, especially the fill of an arbitrary shape. The bwip-js graphics interface was never designed for that kind of work and needs a re-write to handle it.

[Jaimeman84]

Terry,

Another quick question - Do you know what this warning mean? Is this due to the specs you sent in the previous comment?

[terryburton]

On Thu, 12 Jul 2018 at 16:52, Jaimeman84 ***@***.***> wrote: Another quick question - Do you know what this warning mean? Is this due to the spec you sent?

A hard fail that appears irrespective of grading scores is usually the result of breaching a pass/fail criterion such as size constraints.

[metafloor]

Bug turned out to be a rounding-down factor multiplied by the number of pixels in the imagemask. Because bwip-js is designed to work in a low-res (96dpi) environment, image pixels are always scaled by integral factors. The scaleY=1.5 was causing the graphic to be scaled down but the text layout was not respecting the same rounding factor. Fixed now.

[terryburton]

@metafloor Is the performance hit mostly with your graphical rendition or does my tracing code sting also? There is theoretically a simpler version of my code that does not require an intermediate matrix to track enclosed regions but I ran out of time getting it to work so committed what I had.

@metafloor Just FYI since I know this isn't the blocking factor, the aforementioned improvement was released in 2019-08-03:

$ git diff --stat 721f99^ 721f99 src/renmatrix.ps
src/renmatrix.ps | 154 ++++++++++++-------------------------
1 file changed, 49 insertions(+), 105 deletions(-)

The kind of commit I like :-)