Re: XYcolor plots

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]