-
Notifications
You must be signed in to change notification settings - Fork 402
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
Feature Request: Add feature to optionally generate barcodes by width (px) not width factor #195
Comments
I suppose another (maybe better) option could be to add another function within |
If you're taking contributions, I could probably submit a PR, but would only want to do that with input as to which option you'd want me to implement. |
It would add some complexity to support both ways, and not all generators support a float width so that would make it more complex to explain in the docs. It is also not really needed, because you can always display the SVG as 250px wide, without the need for the SVG sizing inside the document to add up to 250px. Maybe for a next big release it will become possible to do the barcode encoding separate from the image encoding, that way you could probably easily do what you suggest here without any extra methods. But that is not something for the coming months. |
What I'm suggesting would only be for generators that support floats.
That's what I thought since SVG is vector, I thought it should stretch. I tried wrapping it in a
You can see from the code that it's specifying the
|
That is because you need to target the SVG, not the div around it. See here an example how you can size the SVG perfectly with CSS. The first example is only targeting the div, the second example is setting the SVG width to 100%, making it match the outer div. |
@casperbakker I appreciate you going the extra mile to show me targeting the SVG, but even this code isn't correctly doing it. If you look at your codepen you'll see that CSS
HTML
You'll notice that it doesn't stretch the width of the barcode. This is because your code is not generating SVG tags with the So even if you don't add the ability to programmatically set the width in px, please consider adding |
Also, when I played around with it, having |
@casperbakker if it's a time thing, I'd be happy to submit a PR for adding the attribute with or without the optional parameter in the barcodeGeneratorSVG() function. |
@objecttothis Thanks for the example with a bigger container. Weird thing is that if you use a smaller container then the image, it works. And that is how I have always used it: I don't like to add too many options that are only for very specific use cases. I don't think that preserveAspectRatio deserves it's own setting. I am in the process of building version 3, where SVG's default method is to give it the desired width and height. If I understand you right, that is what will fix your use case right? I don't want to add preserveAspectRatio right now, because I am looking into how to support text below the barcode. Maybe that option will interfere with it, but I will keep this in mind for v3. Would be nice if you can scale the image bigger and smaller. |
Yeah, I'm not sure what's going on there either.
I understand about not liking to add too many options, however I respectfully disagree that the desire for fixed width is a specific use case if you mean rare that someone would want that. After all, you're already providing a fixed height option.
Yes, this would fix our use case as it is exactly what we need.
Understood. Last thing anyone needs are breaking changes to their code. We generate our text below the barcode separately and would probably keep it that way even if it were an option since we already know what that text is when feeding it to php-barcode-generator. I suspect that since preserveAspectRatio is an SVG tag attribute that if the text were generated as part of the SVG, it would distort the text. If the text is generated outside of the SVG then preserveAspectRatio likely would have no effect. If you need anyone to test for you, I have a vested interest in helping, so let me know. |
If you could see if the new setup in v3 is understandable, that would be really helpful. In that v3 branch I have updated the readme with the new setup. Can you create a SVG with a fixed width with the new SvgRenderer? The more confident I am in the new setup, the sooner I can release it. |
I did see the readme note the other day
The new style seems less readable to me, but I'm assuming that this is so that you can keep backward compatibility with the old style. I looked briefly at the code and if I understand correctly the way I would generate an SVG with width 250px and height 50px is
I usually use npm to install picqer but I assume for the sake of testing I need to move the contents of the V3 branch into my project in place of the existing code. Is that right? |
It is a bit more verbose, but the benefits are that we can make all renderers different so they can have their own options. Also you can create your own barcode types or renderers because they are not linked anymore. Your example is correct.
Do you mean installing via Composer? You can try something like (I am in mobile now): |
Sorry, you are correct. I was just interacting with someone trying to get our project's npm build running so I had that on the brain. I'll just do it through composer. I'm working on another project today through Friday but if I can sneak some time in the evening I'll try it out and let you know. Otherwise I'll do it Monday morning. |
@casperbakker Looks like dev-v3 isn't a thing, but I was able to get v3.x-dev. The only problem I see so far is that it's requiring php 8.2. We are trying to keep our app backward compatible to at least 8.0. Is this just a dev build requirement or is there a reason for it to require 8.2? |
hmmm. @casperbakker For some reason the SVG renderer is generating embedded png, not SVG
There is another problem. In our application the barcode type is stored as a string in our database and this worked because the barcode type was being passed as a parameter.
The new style calls getBarcode() from the Barcode Type class. If I still want to store the selected barcode type in the database I now have to do something like
It also means me adding use statements for all supported barcode types. This is not desirable. |
To be clear, the png isn't the correct width either. It is the correct width in the sense that the image is that dimension, but it's padded whitespace rather than the barcode being stretched to fit the width. |
@casperbakker did you see my testing results above? |
Yes, thank you for testing it. The issues that you found are probably down to a mistake in the implementation than with the library. I looked into several times, but it is not possible to get a PNG with the SVG renderer. It also should not add more whitespace, it really stretches the whole image. The problems with implementing the different types from the database is not something I can fix in the v3 version. The new way is better in a lot of ways, and can certainly also be fed from strings out of a database. But maybe you need to change your code a bit to make it conform to the new version. But it also gives you lot of benefits, like the width definition and in the future the possibility to add margins. I just released the v3 version. If you want to use the widths, you can use the new way. But it is also fully backwards compatible, so no need to change your code if you don't want to. |
For barcode generators which allow float width factors, everything is already there to allow this.
Let's say I want to have an SVG barcode generated to 250px every time (dynamic width factor) In my code I could do this:
then call
$generator->getBarcode($barcode_value, $barcode_type, $widthFactor, $barcode_height]);
The problem with this is thatgetBarcodeData()
is protected so I can't call it outside of theBarcodeGeneratorSVG
class.Please consider adding the ability to send the width in pixels instead of the width factor and do the above calculation in the function.
There are two ways this can be done without breaking existing uses of the function:
getBarcode(string $barcode, $type, float $widthFactor = 2, float $height = 30, string $foregroundColor = 'black', bool $dynamicWidthFactor = false): string
. Then in the function itself if $dynamicWidthFactor is true, assume the value of $widthFactor is in pixels and do the above calculation of what the width factor should be. The rest of the function remains the same. When working with SVGs, pixels can be a float, so widthFactor being a float doesn't break this.getBarcode(string $barcode, $type, int $width, float $height = 30, string $foregroundColor = 'black'): string
and of course the width factor calculation above, but otherwise the function working the same.It seems like it would be a waste to do 2 since the only difference between the two is the width factor being calculated, but it depends on what you're going for.
The text was updated successfully, but these errors were encountered: