Re: support for advanced gnuplot features (was: Plotting semi-trasnparent patches?)

[John W. Eaton]

On 27-Jan-2009, Ben Abbott wrote:

| 
| On Jan 27, 2009, at 2:19 AM, Daniel J Sebald wrote:
| 
| > John W. Eaton wrote:
| >> On 26-Jan-2009, Ben Abbott wrote:
| >> | I agree, we are missing the checkout date, but I'm not sure about  
| >> checking for it. As it would only be useful for developers of  
| >> octave/gnuplot, I think it is safe to assume those running 4.3  
| >> (developers sources) are able to keep their gnuplot up to date.
| >> | | >I think we should require the most recent release version of  
| >> gnuplot
| >> | >(4.2.4) for the octave development tree. If we can *safely*  
| >> determine
| >> | >features of the gnuplot development tree (4.3), those could be  
| >> supported
| >> | >too. But I would do this on case-by-case basis.
| >> | | My understanding is that 4.2.4 is required for the developers  
| >> sources ... 4.2.3 will work but not display 3D plots correctly with  
| >> shading("interp").
| >> | | >I think it is o.k. to require for a new octave release the  
| >> most recent
| >> | >release of gnuplot (4.2.4 at the moment). But others might see  
| >> this
| >> | >different.
| >> | >
| >> | >Kai
| >> | | I'd also like see the conditional support for these  
| >> improvements (figure position and facealpha) added to the gnuplot  
| >> backend.
| >> | | Is there a reason why we wouldn' t want to do that?
| >> I think it would be best to check for individual features, not  
| >> version
| >> numbers.  Even if you can't find a reliable way to check for  
| >> features,
| >> please consider writing something like this in the code that needs to
| >> do different things depending on what features are available:
| >>  if (gnuplot_has_foobar ())
| >>    ...
| >>  else
| >>    ...
| >>  endif
| >>  ...
| >>  function retval = gnuplot_has_foobar ()
| >>    persistent retval = compare_versions (__gnuplot_version__ (),  
| >> "4.2.2", ">=");
| >>  endfunction
| >> This way I think it will be easier to read the code, and simpler to
| >> remove specific checks when/if it is safe to assume that everyone  
| >> will
| >> have a version of gnuplot that supports a given feature.
| >
| > Good idea.  Were you thinking to make it generic, like:
| >
| > gnuplot_has_feature('xyz')
| >
| > so there is only one function rather than possibly many?  If there  
| > were some feedback, one could even send a test script over to  
| > gnuplot to check whether is understand a particular syntax.
| >
| > Dan
| 
| I see value in both suggestions. I've tried to merge both into one  
| function.
| 
| The function, __gnuplot_has_feature__(), supports four conditional  
| gnuplot features I'm aware of.
| 
|       "x11_respects_figure_position" - to be used in gnuplot_drawnow.m
| 
|       "transparency_of_patches" - to be used in __go_draw_axes__.m
| 
|       "epslatex_implies_eps_filesuffix": conditional exists in print.m
| 
|       "epslatexstandalone_terminal": conditional exists in print.m
| 
| A changeset is attached.

For internal functions like this, please simply document them with

## -*- texinfo -*-
## @deftypefn {Function File} address@hidden = } __gnuplot_has_feature__ 
(@var{feature})
## Undocumented internal function.
## @end deftypefn

Anyone who really needs to know the details can look at the code.  If
you'd like to clarify the usage, then put that information as a
separate comment just below the Texinfo doc string.

How about "x11_figure_position" instead of
"x11_respects_figure_position" and "transparent_patches" instead of
"transparency_of_patches"?

I'd still rather have feature tests instead of version checks, but if
that is not possible...

Other than that, I think this is OK, so once you make these changes,
please check it in.

Thanks,

jwe