GNOME Bugzilla – Bug 10546
Add support for opening transparent EPS
Last modified: 2018-05-24 10:28:43 UTC
Name........: Marc Salm
Platform....: AMD K7-700, RedHat 6.1
GIMP Version: 1.1.21
GTK Version.: 1.2.7
-- Other system notes:
-- Problem description:
Transparency is lost, when opening an EPS-file with a transparent layer.
-- How to repeat:
Just open a transparent EPS.
-- Other comments:
------- Bug moved to this database by email@example.com 2001-01-28 10:52 -------
This bug was previously known as bug 10546 at http://bugs.gnome.org/
Originally filed under the gimp product and general component.
The original reporter (firstname.lastname@example.org) of this bug does not have an account here.
Reassigning to the exporter, email@example.com.
Reassigning to the default owner of the component, firstname.lastname@example.org.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Transparency is lost because the PostScript plug-in calls Ghostscript,
which generates a PBM, PGM or PPM file without transparency. This
could be solved by using the PNG driver (pnggray or png16m), but I am
not sure that it would work. Besides, many old versions of gs do not
have the PNG driver.
If you are loading a monochrome EPS file, an easy workaround is to
copy the generated image, paste it into a layer mask and invert the
colors. Then all parts that were white in the converted EPS file
would become transparent. But if the EPS file contains several
colors, then I do not know any good workaround except for Select->By
Color or Filters->Colors->Color to Alpha.
PostScript does not support transparency.
PDF 1.4 does, but not earlier versions.
So EPS files do not have a transparency layer.
Adobe Illustrator files may contain transparency, but the
transparency is not contained in normal PostScript code.
GNU Ghostscript 7.06 has just been released, and contains
a pngalpha driver which writes 24-bit RGB with an alpha
channel. The alpha channel contains pixel coverage.
This driver is a kludge (my fault :-) which translate
the erasepage into a fill page with transparent.
Anti-aliasing is turned on by default for pngalpha.
The result is that for many PostScript and PDF files,
using pngalpha will give you a transparent background
with anti-aliased edges using the alpha channel.
The pngalpha driver does not contains PDF 1.4 transparency
Ghostscript has contained other png drivers since 1996 or so,
but these do not use the alpha channel.
So, you may wish to use the pngalpha device from GIMP.
You could invoke GS using the pngalpha device, and if it
fails because the device is not available, then fall back
to using the pbm/pgm/ppm drivers.
Changes at the request of Dave Neary on the developer mailing list.
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone. Hope that is acceptable.
This is not a Gimp problem, and should be closed in the interests of
In fact it is, because the postscript plugin is part of the gimp and
opening PNGs with the pngalpha driver definitely would help.
The solution suggested in comment #3 sounds good to me and it wouldn't be
difficult to implement. gdk-pixbuf could be used to create a buffer from the PNG
data and code for converting a pixbuf into a GIMP drawable can be taken for
example from the SVG plug-in.
Adding the gnome-love keyword in the hope that someone finds this an interesting
We on Scribus used this very method with pngalpha device for use in our
print-previewer and it has been extremely reliable. You simply need a version
check and anything 7.07+ will work.
Thanks to gimp_layer_new_from_pixbuf(), which is new in the 2.4 API, this should be extremely simple to implement. We can also just assume that GS is new enough these days. Tentatively setting this on the 2.6 milestone.
Could someone please upload an .eps that should appear transparent when imported into GIMP?
Martin, you can use any eps file that isn't rectangular.
I'll upload an example.
Created attachment 99580 [details]
Another option would be to rewrite the Postscript plug-in to use libspectre instead of relying on Ghostscript (see http://libspectre.freedesktop.org/). I actually favor this since calling an external executable is never going to work reliably on all platforms.
There doesn't seem to be much going on here, and it's definitely not crucial for a stable release. Setting target milestone to Future.
I hoped this could be fixed with the latest changes to libgs, but the problem still exists with Gimp 2.7.5 (Windows 7).
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/4.