Hi John,
I'm sorry for comming back to that thread after such a long period of
silence from my side. And so far I don't yet really understand your
problem and what you really want to do.
Let me give you some general explanations at first:
Yes, we do have palettes in PyX. Palettes are tools which provide a
color for a given continuous variable in range 0 to 1 by the getcolor
method. That's about it for the moment.
Then we have changeable attributes. These objects usually represent
some stroke or fill style to be changed by request. The most simple
case is a attr.changelist instance, which takes a list of style
instances and returns those styles one after the other. Internally
this selection is done by a select method call. A changeable
attribute has such a method and this method returns the corresponding
attibutes. This attribute is selected not just by a single index
number, but at the same time a total number of attributes needed in
this use-case of the changeable attribute is given. So the select
call has the signature: select(index, total). Both are integers and
index is an element of range(total). That's it.
Now it's a coincidence, that a palette is a changeable attribute at
the same time.
Beside that we could at a certain point add a support for an indexed
color space (and it's likely that I'll add this at some later point).
A palette will be a good candidate for construting an indexed color
space with a given number of colors. But the palette represents an
infinite number of colors.
On 27.05.06, John Owens wrote:
> Michael Schindler <michael.schindler <at> physik.uni-augsburg.de> writes:
> >
> > pal = color.functionpalette(functions={"r":red, "g":green, "b":blue},
> type="rgb")
> > c.fill(path.rect(0, 0, 1, 1), [pal.getcolor(0.3)])
> > c.fill(path.rect(1, 0, 1, 1), [pal.getcolor(0.6)])
> > c.fill(path.rect(2, 0, 1, 1), [pal.getcolor(0.0)])
> > c.fill(path.rect(3, 0, 1, 1), [pal.getcolor(1.0)])
BTW: I'm a strong supporter for extending the fill/stroke/draw syntax
by the possibility to pass a list of paths as the first argument and
then doing something similar like the plot command in the graph. You
could than write:
> > c.fill([path.rect(2, 0, 1, 1),
> > path.rect(0, 0, 1, 1),
> > path.rect(1, 0, 1, 1),
> > path.rect(3, 0, 1, 1)], [pal])
The selection would than be performed "behind the scenes" as in the
graph system. I think this could be very useful. (Note that I've
reordered the path instances to make the selection doing the right
thing.)
> This is a very nice example. Thank you. I think this is applicable to my
> needs certainly. However, I'd like to use something slightly different:
> instead of a single-argument getcolor function, I'd like a delayed
> two-argument function, where the second argument is the number of
> rendered points. I figure under the hood this must be used somewhere,
> because the getcolor arguments for a color gradient are not actually
> calculated until all of the calls are made. (How does this work? Clearly
> getcolor will take different arguments if I specify a different number of
> points with a gradient.)
Well, the graph does the bookkeeping. It's done within the "plotitems"
instances of the graph, where all the data to be stroked is collected
at first.
By the way the selection of the attributes is also the reason why you
can't plot further data after the dodata is performed on a graph. (We
have weakened quite some of the restrictions of what can be done after
already processing some parts of the graph, but the style selection is
graph-global (and I do *not* propose to do something similar for the
canvas in the draw/stroke/fill methods) and I very much think its best
to keep this restriction. Compared to earlier restrictions, where one
could easily come up with use-cases to really get into problems with
them this restriction should never really harm and it allows for graph
global changeable attributes ... which is a contrary feature and I
think this should be prefered to be kept.)
> So what I really want for four points is:
>
> pal.getcolor(1, 4)
> pal.getcolor(2, 4)
> pal.getcolor(3, 4)
> pal.getcolor(4, 4)
>
> where the second argument is the number of points rendered (and shouldn't
> be calculated until all the points are specified, hence the delayed nature
> of the function). I can then write the functions appropriately. Any way to
> persuade PyX to do that?
Well, you can first store all point data and delay the selection until
all data has been processed. Then you can just count the number of
points. This is similar to what the graph is doing all the time ...
HTH,
André
--
by _ _ _ Dr. André Wobst
/ \ \ / ) [EMAIL PROTECTED], http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/
_______________________________________________
PyX-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-user
