Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make $widthFactor to be float #190

Open
nbulanakov opened this issue Dec 28, 2023 · 4 comments
Open

Make $widthFactor to be float #190

nbulanakov opened this issue Dec 28, 2023 · 4 comments

Comments

@nbulanakov
Copy link

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

I found a similar issue
#100 and it says it resolved.

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

@masi
Copy link

masi commented Jan 11, 2024

@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
Copy link
Member

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
Copy link

masi commented Jan 11, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants