[Octave-bug-tracker] [bug #49017] drawing grid uses RGBA color syntax incompatible with gnuplot 4.4

[Dan Sebald]

Follow-up Comment #6, bug #49017 (project octave):

Something like the following:


diff --git a/scripts/plot/util/private/__gnuplot_draw_axes__.m
b/scripts/plot/util/private/__gnuplot_draw_axes__.m
--- a/scripts/plot/util/private/__gnuplot_draw_axes__.m
+++ b/scripts/plot/util/private/__gnuplot_draw_axes__.m
@@ -1011,7 +1011,7 @@ function __gnuplot_draw_axes__ (h, plot_
               endif
             else
               colorspec = sprintf ("lc rgb \"#%02x%02x%02x\"",
-                                   round (255*color));
+                                   uint8 (round (255*color)));
             endif
 
             sidx = 1;
@@ -1946,7 +1946,7 @@ function [style, ltidx] = do_linestyle_c
   found_style = false;
   if (isnumeric (linecolor))
     color = linecolor;
-    if (isfield (obj, "alpha"))
+    if (isfield (obj, "alpha") &&  __gnuplot_has_feature__
("alphablend_linecolor"))
       alphastr = sprintf ("%02x", round (255*(1-obj.alpha)));
     else
       alphastr = "";
diff --git a/scripts/plot/util/private/__gnuplot_has_feature__.m
b/scripts/plot/util/private/__gnuplot_has_feature__.m
--- a/scripts/plot/util/private/__gnuplot_has_feature__.m
+++ b/scripts/plot/util/private/__gnuplot_has_feature__.m
@@ -39,7 +39,8 @@ function res = __gnuplot_has_feature__ (
                          "has_termoption_dashed",
                          "needs_color_with_postscript",
                          "linetype",
-                         "dashtype"};
+                         "dashtype",
+                         "alphablend_linecolor"};
   persistent has_features;
 
   if (isempty (has_features))
@@ -49,8 +50,8 @@ function res = __gnuplot_has_feature__ (
       ## Don't throw an error if gnuplot isn't installed
       gnuplot_version = "0.0.0";
     end_try_catch
-    versions = {"4.2.5", "4.2.5", "4.4", "4.4", "4.4", "4.2", "4.2", "4.4",
"4.4", "4.4", "4.4", "4.3", "4.6", "4.6", "5.0"};
-    operators = {">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=", ">=",
">=", ">=", ">=", ">=", ">="};
+    versions =  {"4.2.5", "4.2.5", "4.4", "4.4", "4.4", "4.2", "4.2", "4.4",
"4.4", "4.4", "4.4", "4.3", "4.6", "4.6", "5.0", "4.6"};
+    operators = {   ">=",    ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=", 
">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">=",  ">="};
     have_features = false (size (features));
     for n = 1 : numel (have_features)
       has_features(n) = compare_versions (gnuplot_version, versions{n},
operators{n});


Seems to solve the functional issues.  Although the uint8() keeps the values
within a valid range, the color scaling/translation is obviously off for
"trimesh 1" demo (the negative numbers are a strong indicator).  I think this
comment suggests that the code needs to be revisited:


              ## FIXME: This is the wrong thing to do as edgecolor,
              ## markeredgecolor and markerfacecolor can have different
values
              ## and we should treat them seperately.  However, the code
below
              ## allows the scatter functions to work as expected, where only
              ## one of these values is set.


Should we treat the trimesh example as a separate bug?


    _______________________________________________________

Reply to this item at:

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

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