![](https://secure.gravatar.com/avatar/ad5afbb91c8b5ec2b1199838461a8348.jpg?s=120&d=mm&r=g)
There is a problem (by libpng 1.2.7) with PNG inclusion and alpha channel. Greg Roelofs from the png-implement list gave an external workaround
pngtopnm foo.png | pnmtopng > foo-no-alpha.png
Tried it, works. I see how the PNG images with alpha channel "really" should look like: different from what pdftex maybe ever tried to do. Previously the alpha channel was simply stripped. Now certain images are blended to a uniform background (its color might be part of the PNG file, or come separately through the -mix -background option to pngtopnm). But the whole rectangular image area is still opaque, so it hides things underneath. As replacement for the (currently a little buggy) libpng now one could probably adapt the pngtopnm program to get an integral part of pdftex. Now should one just flatten a PNG with alpha so that it blends to an opaque white background (or the one provided with the image), in the way the above external processing does? Then there is no way to supply the background color if it's missing in the image. Apart from this PNG opaque blending, there is also the "Transparency" feature in PDF (PDF Ref. chapter 7). Looks complicated. Has anybody ever played with transparency, e. g. by some \pdfliteral tricks? Or should one stay away from all this alpha and transparency business, flag an error on PNG's with alpha (they likely look wrong anyway), and recommend that alpha needs the shown preprocessing? Maybe it also helps just to do nothing and wait for libpng 1.2.8... Regards, Hartmut
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Hartmut Henkel wrote:
Now should one just flatten a PNG with alpha so that it blends to an opaque white background (or the one provided with the image), in the way the above external processing does? Then there is no way to supply the background color if it's missing in the image.
that is no real problem since one can add backgrounds using tex; keeping the background separate has the advantage that it is less tricky with regards to image reuse (on different backgrounds); it also makes it possible to extract the image as it is afterwards
Apart from this PNG opaque blending, there is also the "Transparency" feature in PDF (PDF Ref. chapter 7). Looks complicated. Has anybody ever played with transparency, e. g. by some \pdfliteral tricks?
sure, it's part of context for years already; one should build some additional resource dicts; i wonder if we have to go that way, since i always thought that transparency of bitmaps is a characteristic of the bitmaps image itself (so, i must look into it)
Or should one stay away from all this alpha and transparency business, flag an error on PNG's with alpha (they likely look wrong anyway), and recommend that alpha needs the shown preprocessing?
preprocessing is ok, since doing that each run takes time as well; but then we must add an howto section to the manual how about transparent images on top of text
Maybe it also helps just to do nothing and wait for libpng 1.2.8..
(btw, having access to the color dict of an image would be a nice feature as well, see some post long ago) and then we don't even talk about image masks Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/ad5afbb91c8b5ec2b1199838461a8348.jpg?s=120&d=mm&r=g)
On Mon, 1 Nov 2004, Hans Hagen wrote:
Hartmut Henkel wrote:
Apart from this PNG opaque blending, there is also the "Transparency" feature in PDF (PDF Ref. chapter 7). Looks complicated. Has anybody ever played with transparency, e. g. by some \pdfliteral tricks?
sure, it's part of context for years already; one should build some additional resource dicts; i wonder if we have to go that way, since i always thought that transparency of bitmaps is a characteristic of the bitmaps image itself (so, i must look into it)
seems so yes: the alpha channel, if it would be properly extracted. Or use a separate image, tried just the maybe most trivial case: \pdfcompresslevel=0 \nopagenumbers \immediate\pdfximage {mask.jpg} \pdfximage attr {/SMask \number\pdflastximage\space 0 R} {img.jpg} \leavevmode \rlap{Hello}% \rlap{\hbox{\pdfrefximage\pdflastximage}}\bye The Hello shines through. Drawback: Seems that xpdf doesn't have any idea of /SMask yet, the example works only with acroread and gs. Instead of the mask.jpg, maybe here one could use the alpha component of a PNG (instead of stripping alpha, so that the transparent PNG parts let things shine through).
preprocessing is ok, since doing that each run takes time as well; but then we must add an howto section to the manual
how about transparent images on top of text
But there are so many special cases... Regards, Hartmut
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Hartmut Henkel wrote:
seems so yes: the alpha channel, if it would be properly extracted. Or use a separate image, tried just the maybe most trivial case:
\pdfcompresslevel=0 \nopagenumbers \immediate\pdfximage {mask.jpg} \pdfximage attr {/SMask \number\pdflastximage\space 0 R} {img.jpg} \leavevmode \rlap{Hello}% \rlap{\hbox{\pdfrefximage\pdflastximage}}\bye
The Hello shines through. Drawback: Seems that xpdf doesn't have any idea of /SMask yet, the example works only with acroread and gs.
Interesting, but it seems that the images must be kind of specisl, since it does not work on arbitrary ones Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/ad5afbb91c8b5ec2b1199838461a8348.jpg?s=120&d=mm&r=g)
On Tue, 2 Nov 2004, Hans Hagen wrote:
\immediate\pdfximage {mask.jpg} \pdfximage attr {/SMask \number\pdflastximage\space 0 R} {img.jpg}
The Hello shines through. Drawback: Seems that xpdf doesn't have any idea of /SMask yet, the example works only with acroread and gs.
Interesting, but it seems that the images must be kind of specisl, since it does not work on arbitrary ones
Soft-mask image must be DeviceGray type. BTW, with libpng-1.2.8beta2 the pdftex crashes during PNG write have gone, and alpha is stripped as before. Regards, Hartmut
participants (2)
-
Hans Hagen
-
Hartmut Henkel