octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #42543] transparent surface using facealpha is


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #42543] transparent surface using facealpha is not working
Date: Thu, 14 Dec 2017 00:31:13 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #9, bug #42543 (project octave):

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.)

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42543>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]