[Dvipng] Re: [Bug-AUCTeX] dvipng transparency and eps

[Jan-Åke Larsson]

(redirecting to the dvipng list)

When using the "-bg Transparent" option to dvipng, any EPS figures
which are included using \includegraphics still keep their
nontransparent background. I tried replacing the
char *device="-sDEVICE=png16m";
line in special.c with
char *device="-sDEVICE=pngalpha";
to make sure that ghostscript spits out images with an alpha channel,
but this didn't work (if the eps is run through ghostscript
separately, the pngalpha device _does_ produce an image with alpha
channel, so it seems to be a problem inside dvipng).

Correct. (It is only recently the pngalpha device has become available
in a released gs) The code used to copy from the gs-rendered image to
the dvipng image handles indexed colors this way, and I have not been
overly enthusiastic about copying pixel-by-pixel. Perhaps I should have
a go.

Now, you _have_ tried --truecolor?

I'll see if I can do anything to make dvipng autodetect what devices are
available.

/JÅ

[Kasper Peeters]

Post by Jan-Åke Larsson
Now, you _have_ tried --truecolor?

I'm not sure what you mean here, but if I add this option to dvipng,
(with or without the "pngalpha" modification) the EPS images in the
TeX document still come out with a coloured background, not a
transparent one. Perhaps I misunderstood what you meant.

Kasper

[Jan-Åke Larsson]

Post by Kasper Peeters

Post by Jan-Åke Larsson
Now, you _have_ tried --truecolor?

I'm not sure what you mean here, but if I add this option to dvipng,
(with or without the "pngalpha" modification) the EPS images in the
TeX document still come out with a coloured background, not a
transparent one. Perhaps I misunderstood what you meant.

Hm. The problem is that the inclusion code (internal to libgd) uses the
gdImageColorClosest call as opposed to the gdImageColorClosestAlpha
call. I was hoping that selecting truecolor would avoid that call
altogether.

[Jan-Åke Larsson]

I'll see what I can do but this will probably not happen straightaway.

When reading the source of gdImageCopy, I see that it apparently uses
the alpha channel correctly. So I decided to try myself. No problem,
after changing to pngalpha.

I have no idea why it doesn't work for you. (Silly question: you have
made sure you use the recompiled binary?)

I'll add some code to see what devices are present in the gs called.
(Although with a white background, the white is overwritten with
transparent pixels, not what I expected, needs to be fixed.)

/JÅ

[Jan-Åke Larsson]

When using the "-bg Transparent" option to dvipng, any EPS figures
which are included using \includegraphics still keep their
nontransparent background.

Try the latest CVS. It contains a few improvements:

a) By using the pngalpha gs device it will no longer overwrite things
already typeset "under" the included EPS image. Unless the EPS
explicitly paints the background of course (Yikes!)
b) It will no longer automatically crop an EPS image to the boundingbox,
but render all that fits on the present page. The boundingbox will be
used for size estimates if -Ttight is used.
c) Images included onto a transparent background will have...a
transparent background(!).
d) If the pngalpha device is not present in your gs, it will revert to
the old behaviour (with a warning).
e) An included image will automatically make the page be output in
truecolor mode. Use --palette to enforce the old behaviour. I will think
some more before releasing this, perhaps people _want_ palette images.
But dvipng has always opted for speed, and this is really the speediest
solution, palettizing an included image is quite time consuming. The
png256 gs device uses a fixed palette so the output is really inferior.

/JÅ

[Kasper Peeters]

Brilliant! Just tried it and it now does everything I need.
Thanks a lot!

Kasper