Thu 14 Dec 2017 05:31:12 AM UTC, comment #9:
I wasn't aware of this bug report. Doesn't seem like much has changed in the past couple years. In addition to the behavior described in previous posts, I see for Qt gnuplot toolkit terminal that lines are still visible even after setting 'edgecolor' to 'none'. (I'll investigate that one.) However, in "pngcairo" display there are no edge lines, and transparency works. So, the immediate solution is to use "pngcairo" instead of "png". But similar to noted previously, the line is completely "covered" by the surface--actually I think what is happening there is the line is being segmented according to "hidden line removal" feature of gnuplot. That is, the gnuplot algorithm thinks that line segment can be discarded because that part of the software probably doesn't understand the opacity concept. (I'll investigate.)
Note also that Qt terminal driver in gnuplot has its own "save to file" feature which generates PNG files matching what is on screen.
Back in 2015 I wrote a patch meant to fine tune all these -d driver options that I'm not sure was ever used:
https://savannah.gnu.org/bugs/index.php?44187
It appears to have been updated by others. Maybe equating "png" to "pngcairo" was part of that. Another feature that was part of that patch, as best I remember, was a "demo print" which would create a list dialog of all the possible -d[driver] options and then print the figure with that driver and call some external app for viewing the final result, even if that meant having to run the result through latex and send the result to a secondary viewer. It was a nice way to quickly observe driver feature support for most all terminals and a clue of the syntax needed for utilizing the output format. (I'll look through the current code and see if any elements of the patch I'm referring to have found their way into the current tip.)
|
Thu 14 Dec 2017 02:32:41 AM UTC, comment #8:
The issue seems to be that not many gnuplot terminals actually support transparency. "help transparent" from within gnuplot 5.0.3 returns
In particular, the eps terminal does not seem to support transparency. This is an issue for Octave because printing generally relies on first creating a .eps file, and then using Ghostscript to transform from eps to just about anything else.
There are several workarounds. First, use a terminal that supports transparency such as "svg". Second, go through the cairo series of terminals if they are supported on your computer.
I've added Dan Sebald to the CC list since he is the export on the gnuplot interface. A longterm option for Octave might be to switch from using the "eps" terminal to the "epscairo" terminal to generate the initial eps file. With that change, the rest of the backend plotting routines would work just fine.
|
Wed 11 Mar 2015 10:08:00 PM UTC, comment #7:
I'm now facing the same issue:
1. Alpha is not preserved when using `print` to an image file (e.g. -dpdf, or -dpng).
2. Alpha can be observed on-screen using gnuplot's qt terminal.
How are images generated with `print`? Can that path inherently support alpha?
|
Tue 17 Jun 2014 02:19:01 PM UTC, comment #6:
Using "setenv GNUTERM qt" gives the correct result.
And if I save a PNG from the window's menu, it also contains the transparency.
"print 'output.png'" still does not work.
(file #31572)
|
Tue 17 Jun 2014 01:41:50 PM UTC, comment #5:
To clarify, I get the correct transparency on-screen using gnuplot's qt terminal, but not when the figure is printed to a PNG file.
|
Tue 17 Jun 2014 01:40:13 PM UTC, comment #4:
Both the OP's example and your example work fine for me in gnuplot 4.6 using the qt terminal but not the x11 terminal. Can you confirm if you "setenv GNUTERM qt" in octave and then run your example, you get the correct behavior?
|
Fri 13 Jun 2014 06:10:24 PM UTC, comment #3:
I should add that all I mentioned was done from an up-to-date Arch Linux.
|
Fri 13 Jun 2014 04:10:03 PM UTC, comment #2:
I have exactly the same problem. Monts ago it was working fine.
I'm using Gnuplot toolkit.
I tried this with gnuplot terminal: http://www.gnuplotting.org/?s=transparent and it worked fine.
I have attached the output png.
(file #31545)
|
Thu 12 Jun 2014 01:29:28 AM UTC, comment #1:
Thanks for your bug report. You have reported this as being with gnuplot, are you sure you are using the gnuplot backend and not fltk?
If gnuplot, then this could be specific to gnuplot's windows terminal.
If fltk, then this looks like a duplicate of bug #39535.
|
Wed 11 Jun 2014 10:13:07 PM UTC, original submission:
produces a line that is completely obstructed by surface instead of being partially seen-through as shown here http://stackoverflow.com/questions/12072412/setting-transparancy-of-surface-plot-on-octave/24173227?noredirect=1
So facealpha just makes the plot lighter in color...
|