On Sat, Aug 22, 2009 at 06:42:21PM -0700, Alan Irwin wrote:
> On 2009-08-22 16:57-0500 Hezekiah M. Carty wrote:
>
> >
> > I do not have a working Ada install yet, so I can not test the effect [of
> this patch]
> > this has on the Ada bindings. I can, however, call plscmap0n with 0,
> > negative and positive values before calling plinit from OCaml,
> > resulting in a proper palette of colors.
> >
> > If it works for you and/or others I will go ahead and commit the change.
>
> The patch solves the Ada colour initialization problems for me. However,
> the
>
> if (ncol0 == 0 || first_allocation == TRUE) {
> plspal0("");
> }
>
> logic in plscmap0n is going to sometimes have quite a different effect than
> the old logic that always initialized colours for the part of the cmap0
> palette that was expanded from the previous call. For example, for the old
> logic if the users code called plscmap0n(3), made some changes to the first
> 3 colours, then followed by plscmap0n(13), the expanded colours (i.e., the
> 4th through 13th colours) would get properly initialized to their default
> values without messing with the first 3 colours. For the new logic the
> expanded colours will just be red. I am having a hard time wrapping my head
> around all the implications of the above if statement so there may be other
> user scenarios where the results are different than before.
>
> Therefore, I think we should do something that mimics the effect of the old
> plscmap0n code much better. The current coding logic is already pretty
> messy because plspal0 calls plscmap0n and vice versa and adding logic to
> plspal0 so that it only overwrites the expanded range of cmap0 indices is
> only going to make it worse. Thus, perhaps the best way out of this mess is
> to go back to what I said I didn't want before which is hard-coded colours
> set inside plcmap0_def (but this time with a comment they must be consistent
> with data/cmap0_default.pal).
>
> If upon reflection you (and others here who are interested) also feel the
> safest thing to do is go back to hard-coded colours, I am willing to take
> your patched version of plctrl.c and do the editing of plscmap0n (to remove
> the call to plspal0) and plcmap0_def (to put back the default colours) but
> otherwise leave your patched version alone (e.g., the is_cmap0_ready logic
> which I like better than the previous logic) to make up for the wasted work
> I caused you. :-)
>
> Let me know what you think.
Let's not have a mix of palette files and hard coded otherwise it will produce
very unexpected results where the user has changed the default palette from
that hard coded into plplot. It may need a little more thought but the right
solution is definitely to disentagle and loops from plspal / plscmap0n.
Andrew
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
