search

picqer / php-barcode-generator

Barcode generator in PHP that is easy to use, non-bloated and framework independent.
GNU Lesser General Public License v3.0
1.67k stars 402 forks source link

Make $widthFactor to be float #190

Closed nbulanakov closed 1 month ago

nbulanakov commented 10 months ago

It would be good to have widthFactor to be float instead of int to allow better adjustments.

I found a similar issue https://github.com/picqer/php-barcode-generator/issues/100 and it says it resolved.

but I don't see it's changed for some reason, I need it for PNG generator

masi commented 9 months ago

@nbulanakov It has been resolved for HTML and SVG not for PNG. There are forks around that add exactly this feature.

@casperbakker I don't quite get why the scaling factor is an integer. The actual width in the code is even passed to round() which results a float. Changing the argument to float will not make any difference inside the generating code, but will allow users a more fine grained control over the width.

Anyway, thanks for the code. Besides this small issue the package made my life easier.

casperbakker commented 9 months ago

I don't see why it would be useful, while it can generate a lot of render bugs. The JPG and PNG renderer does not do any anti-aliasing, so it cannot support 1.3 pixels as a bar width. Yes, it is being rounded. But if it results in 1.3 for 1 bar, and 2.6 for 2 bars, you get 1px and 3px bars instead of 1px and 2px. That is wrong. Probably will mostly work on the barcode decoder end, but if the physical barcode is also a bit damaged, this slight bug can make the barcode not read at all.

If you want 1.3 as a factor, it is better to use 2 as a factor and render the resulting image smaller. That way the bars are the proper width in comparison, but the image renderer will make it anti aliased. For example, if you get an resulting image of 170px wide, render it at 130px wide.

But maybe I don't understand the use case that you have, which could change my view. Could you explain to me why it is difficult to work with the current integer setup, and what specific use cases would be better with a float as input. And please explain to me why it will not lead to render bugs.

masi commented 9 months ago

Seems I haven't fully understood the algorithm. But at least I am not alone, at least @shaunluedeke and @luisbmemorandum made the same mistake.

So you suggest to take the generated image as an intermediate step and scale it by some other means (a renderer of my choice)? Ok, not extremely difficult, but not so convenient as a one stop shop :)

As for the use case: you described it very well. The image with a factor of 2 is too large, so 1.x would come in handy.

I see your point. If I had filed the ticket you could close it.

casperbakker commented 9 months ago

Seems I haven't fully understood the algorithm.

No problem, we are here all to learn, including me. :)

So you suggest to take the generated image as an intermediate step and scale it by some other means (a renderer of my choice)? Ok, not extremely difficult, but not so convenient as a one stop shop :)

To be clear: I don't suggest to take another tool (like Imagick) and resize the image afterwards. But if you use the barcode, you will display it somewhere and it will be rendered somewhere. Maybe in a webpage, maybe in a PDF document. In that place you can use it like <img src="generated-barcode-image.jpg" style="width: 130px">, and that will get you the right size.

If I use barcodes on printed documents, I will usually create an image 3 times bigger and display it smaller, so it will be printed as sharp as possible. This is because printers have a better resolution then monitors.