[transferred from Email] Providing/exporting a table of plot style properties

[Ethan A M. <merritt@u.washington.edu>]

[from a conversation started off list]
[summary] The question is whether the code in get_data()
plot2d.c lines 327ff   can be replaced by a table-lookup,
or deleted altogether.   This code sets limits min_cols and max_cols
for the number of columns specified in the "using" part of a plot
command.  Ralf's proposed table would also hold properties like
PLOT_STYLE_HAS_FILL that are currently single bits set in the
line style definitions in gp_types.h

On Saturday 03 January 2009, Ralf Juengling wrote:
> 
> On Sat, 3 Jan 2009, Ethan A Merritt wrote:
> 
> > Your patch may be heading towards something useful, I'll wait
> > and see how it ends up.  As I understand it, the idea is not so
> > much to fix or improve gnuplot per se, but to make a table for
> > use by an external program.  I'm not sure it is worth doing this
> > inside gnuplot;  for the same amount of work you could just make
> > the table part of the external program.  That would have the
> > advantage of working with older versions of gnuplot that don't
> > have your table built in.
> 
> While my main motivation for this patch his making plot style
> properties explicit to applications that generate gnuplot
> scripts, it certainly is useful in that it improves clarity
> of the code. And I would not be surprised if having such a
> descriptor table would enable simplifications at other places
> as well. The reason I would rather see it builtin and used
> than external is that this guarantees the table is current.
> 
> Can you think of other properties that would be useful to
> have in the table? I think it would be useful to know that
> a plot style expects non-numeric input (e.g., labels). 

As you move into that kind of question, I start to think that
the whole idea of a fixed set of properties for a given plot
type breaks down.  For instance, any plot command that includes
  using xticlabels(N)
will require reading from column N and will be expecting non-numeric
data.  But this is outside of the count of columns that the code in
get_data() is making, and the expectation of non-numeric data is
tacked on to whatever expectations the plot style already had.

Similarly, each use of the propery "variable" adds a column of
expected input, independent of however many columns were already
expected.   I am not sure that preparing a table in advance 
actually serves any useful purpose, at least internal to gnuplot.
One really has to total up the number of columns referred to in
this specific plot command.  The specific plot style is largely
irrelevant.

It was this kind of argument that made me inclined to delete
all the code tracking min_cols and max_cols.   Other than issuing
an error message if the command fails to provide at least min_cols
of using specs, they aren't much use for anything.  It may not even
generate an error message if you exceed max_cols, as you have already
pointed out with regard to filledcurves.

> What 
> aboutthe has_grid_topology property in struct surface_points?
> Is that not plot-style specific property?

In truth, I know essentially nothing about the 3dgrid code.
Let's move this discussion to the mailing list so that other people
can usefully comment.


-- 
Ethan A Merritt