Change output, Palleted PNG with transparency

[Siyfion]

So I'm using this library in a few different ways, but one of which, is as part of a PDF rendering library, which utilises PrawnPDF to create the PDF. Now, I've noticed that when I use your library to generate a PNG I get an error when trying to add it to the PDF (a Prawn error):

Pallete-based transparency in PNG is not currently supported. (Prawn::Errors::UnsupportedImageType)
Which is detailed here: prawnpdf/prawn#783

I was wondering if there was any way that I could change the output format of the PNG such that it is in a supported format? That would be hugely useful!

[metafloor]

One work-around might be to manually set the BWIPP background color option. Assuming you are printing on a white background, try using:

backgroundcolor=FFFFFF

And please let me know if that is an acceptable work-around.

[Siyfion]

Yup @metafloor that worked perfectly, and as a printer cannot print "white" ink, it'll work wonders! Thank you for the rapid response!

[metafloor]

Glad that will work for you.

[Siyfion]

@metafloor Alas, that trick seemed to work okay for a while, (seemingly with EAN13 barcodes) but I've just tried my first Code128 and it's got the same error again. 😫

[Siyfion]

Yup, I've just checked, even with the background flag set, the Code128 rendered the "text" portion of the barcode over a transparent background.

[Siyfion]

Aaaand the same issue with EAN8 barcodes, there's a tiny transparent "line" on the far left-hand side.

[Siyfion]

I've ended up running the images through Imagemagick to remove the transparency, an extra step, but a much-needed one.

[metafloor]

Just released v0.13.0 which changes the handling of the backgroundcolor option. I feel BWIPP's implementation is a bit inconsistent, so the new version overrides the option and puts the background color handling into the bitmap interface, where the entire image is guaranteed to be "covered". See the README for additional information and comparisons of the images produced.

[terryburton]

"I feel BWIPP's implementation is a bit inconsistent"

How can we improve this in BWIPP to make it better for frontends?

[metafloor]

@terry: I have given your question some thought. My thinking is that there are competing needs with background color. Within a PostScript environment, it is fairly straightforward for a user to add a background fill to the region where BWIPP will do its rendering. In such a situation, the current functionality in BWIPP may make sense. But for front-ends that are in the business of rendering individual bar code images, background color has the implied meaning that it covers the entire drawing surface of the image.

So for now, I think there is nothing to change, especially since any change would likely break backward compatibility for your user base. For bwip-js, it was quite straightforward to look for the option, remove it before passing to the BWIPP emulation, and then apply it as part of the image rendering pass. And I think it would be just as easy for other front-ends that desire similar results.

Thanks for all your work.

[Siyfion]

Thanks @metafloor I'll try it out without my "hack" using imagemagick later on today and let you know how it goes, as it'll almost certainly be more efficient to generate it correctly in the first place, than correct it later on. 👍

[Siyfion]

Looks great @metafloor working wonderfully 😀

[terryburton]

"So for now, I think there is nothing to change, especially since any change would likely break backward compatibility for your user base."

Thanks @metafloor. I'm planning a rendering-focused release that could potentially be "API breaking" later this year. You can track here (ignore the description as the focus will primarily be on grid-fitting): bwipp/postscriptbarcode#7

I'll include stretching the background to encompass outlying text as part of this work.