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

[Ben Abbott]

On Jan 27, 2009, at 11:11 PM, John W. Eaton wrote:

> 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} {@var{has_feature} = }  
> __gnuplot_has_feature__ (@var{feature})
> ## Undocumented internal function.
> ## @end deftypefn

No problem. That's much easier.

> 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'll make the changes to the "feature" strings.

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

Regarding checking for features, I assume this must be done by sending  
gnuplot some sample commands and checking for an error? ... that  
should work for these 4 cases. However, I'm not sure how to do that  
without writing the commands to files and then making a system call.  
Also, when the features are absent, I expect gnuplot will produce  
errors that will show up in Octave's command window.

The feature check is a more proper solution, so I tend to favor it.  
Any advice on how that should/could be implemented so that it works on  
all platforms?

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

Perhaps it is best to push the present changes and follow up with a  
proper implementation later ... which willl allow some clean up of the  
code and allow features (1) and (2) to be committed as well.

Ben