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 > [email protected] > https://mail.gnome.org/mailman/listinfo/gnumeric-list _______________________________________________ gnumeric-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnumeric-list
