Add a user defined colourpad (filled margin area)

[michaesc]

Pull request 'Colourpad Addition 1A'

This pull request implements a primitive colour pad, of a user defined size.

Colour padding

Machine reading improves when codes have a large padded area around them, in the same colour as the very thin margin as defined in existing sources.

Improvement

To introduce a user defined padded area, a parameter is added wherever graphic size is referenced (in buffers, allocation, and construction.)

Still broken

The addition of one variable forces the user to define the same padded area size in all four directions, so users trying to fit graphics to a particular screen size will not have the luxury of a well defined area.

Standard conformance

I didn't take the time to read the QR standard, which probably recommends the size of a margin area according to pixel density. I think UPCA codes have similar requirements.

If such a standard exists, then it would be best to:

• Merge this request with a reminder to standardise
• Add a bug report stating the standard requirement
• Rework the changes in this request to conform

Wrong branch

This request is made on the release/v7 branch. Please request the equivalent improvement on master and I'll provide it.

Author's comment

I consider this change to be an improvement, but it suffers from the same API problems as the existing source (no default parameters, poor granularity, and no derived functions.) It's cheap and sloppy but it works great until you need one extra variable, like this colour pad addition. Then it's time to scramble and hack, make an addition without the benefit of function overriding. For this reason, it may be best to reject the request. Rejection would leave the problem of a lacking user defined pad unsolved.

[kisvegabor]

Hi,

Thank you for this update. I wonder whether we can use the padding style properties for this purpose. Although, it seems difficult to handle what to do when the style changes. The buffer needs to be reallocated and the QR recalculated.

But at lest we can save cpad in lv_qrcode_create as a local style property. This way it doesn't need to be repeated in lv_qrcode_update as the padding value can be get by lv_obj_get_style_pad_left(obj, LV_PART_MAIN).

Another solution to the problem could be to place the QR code object on a container that has "QR background" color and padding you need.

What do you think?

[michaesc]

It's true that there are a few valid but independent methods to solve this problem.

Placing the QR code obect ontop of a background fails due to underlying (at least in release/v7) LittleVGL flaws when using 2-bit indexed palettes.

I may be convinced to rework my change if someone tells me exactly what the least worst method to implement the pad is desired, but confidence is not high that this problem can be correctly solved easily.

The most pragmatic choice is to merge this request as is, unfortunately.

[kisvegabor]

Placing the QR code obect ontop of a background fails due to underlying (at least in release/v7) LittleVGL flaws when using 2-bit indexed palettes.

What's this flaw?