Re: XYcolor plots

[Jean Bréfort <jean brefort free fr>]

Le samedi 13 novembre 2021 à 15:10 -0700, John Denker via gnumeric-list
a écrit :
> On 11/13/21 1:38 PM, Jean Bréfort wrote:
>
> > Found the issue, this is actually the wanted behavior, the colors are
> > not associated with 0..4 but with 0, 1, 2, 4, and 6.
>
> OK, that explanation fits the facts, but wow, it sure
> is a surprising situation.
>
> Evidently the default colormap is not very user-friendly.
May be, this choice was made because the color differences are more
visible at least to my eyes between, say, yellow and red than between
blue and cyan.

> Note that when I duplicate the default colormap, the colors
> I see are associated with 0, 1, 2, 3, and 4. There is no
> hint that 3 and 5 were ever skipped.

Looks like the editor was implemented with contour plots in mind.
Clearly not optimal.

> When I save the duplicate, and apply it to my plot, I get
> the expected behavior. So AFAICT the moral of the story is,
> never use the default colormap.
>
> ===============
>
> I also just discovered the following:
>
> Assuming you want to use integer codes in the user Z data,
> the color axis Maximum should be set to the highest bin
> defined in the colormap ... not to the highest code in
> the user data.

That would not be a good idea in many cases, IMHO. You can always
choose the axis maximum as you like it.

> In retrospect I can sorta understand the idea behind
> this behavior, but it sure comes as a surprise.
>
> Because of this, at the very minimum there needs to be
> a way for the user to find out what bins are defined in
> the colormap. Perhaps on the "colors" tab, in the listbox
> that selects a colormap, the min and max bin numbers could
> be displayed. This would make the XY colors feature a lot
> more usable.
>
> Also some documentation would make this feature a lot
> more usable. Maybe even an example.
>
> =============
>
> *) Please consider implementing a way to load a colormap on
> the fly from the spreadsheet itself, perhaps from an array
> of 8-character hex strings. This is important because (a)
> designing a colormap is hard, since it requires anticipating
> what the user wants to do with it; then (b) entering a
> colormap click-by-click is tedious and painful, and (c)
> once the colormap is created, it's hard to remember what's
> in it ... especially since there is not an "edit" feature,
> nor even an "inspect" feature.

Please file a request at gitlab.gnome.org/GNOME/goffice

> It's not very convenient for users to guess what's in a
> non-default colormap, which is stored in an undocumented
> directory under a non-mnemonic filename. It's even harder
> to guess what's in the default colormap, which AFAICT is
> not stored anywhere.

It is created on the fly so only visible in the source code.

> *) Or (!) allow the option of bypassing the colormap entirely,
> and just using hex strings as Z-axis data, as previously
> discussed. This would make life a lot simpler.
> _______________________________________________
> gnumeric-list mailing list
> gnumeric-list gnome org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list