After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 609490 - The Windows "Window" color isn't honored for the spreadsheet background
The Windows "Window" color isn't honored for the spreadsheet background
Status: RESOLVED OBSOLETE
Product: Gnumeric
Classification: Applications
Component: GUI
1.9.x
Other Windows
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 681715 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-02-10 03:07 UTC by Dan Dascalescu
Modified: 2018-05-22 13:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Dascalescu 2010-02-10 03:07:43 UTC
In Windows, you can go to Control Panel -> Display -> Appearance -> Advanced, pick the "Window" item, and change its color. This reflects in the background color of applications that honor this setting: MS Word, MS Excel, IE etc.

The default color is a bright white, and I've found that when working many hours on a document, this would hurt my eyes. Setting the color to gray makes it much more tolerable. To test, simply open a new Word or Excel document.

Gnumeric unfortunately doesn't honor this accessibility setting so I'll have to stay with Excel for now.
Comment 1 frob 2010-04-21 23:20:59 UTC
I tried to set it to dark grey. gnumeric changed font name/size selection, cell selection/edit and zoom to dark grey. The main sheet area are still white.
Comment 2 Morten Welinder 2010-04-22 00:37:25 UTC
Contrary to common belief "major" does not mean "it happened to me".
Comment 3 Kiri 2010-07-31 18:56:31 UTC
This is not MS OS specific, but I do not see a way for me to alter the OS.  Perhaps you can Dan Dascalescu. It happens with GTK themes too.
Comment 4 Jean Bréfort 2010-08-01 12:55:32 UTC
The grid background must not follow the theme color. Gnumeric is wisiwig as far as possible, and generally people print on white paper, not black. What we can do is add an user option to change the displayed color, or just do nothing and vote for wontfix.
Comment 5 Andreas J. Guelzow 2010-08-03 00:18:40 UTC
If I change my theme to somethingwith a dark window caller (eg. darkroom) then the text area in OOo Write,OOo Calc, Firefox, etc still stays (not unexpectedly) white.

I do note that OOo (but not Firefox) behaves different with "high Contrast Inverse).
Comment 6 Kiri 2010-09-20 14:03:03 UTC
With Firefox, it depends on whether you select "Use system colors" in Preferences.

That would be 1 good way to present a user option.

The white of paper is likely less bright than the brightest white of the screen.  In color management terms, the current strategy is 'saturation' a more WYSIWYG strategy would be 'absolute'.
Comment 7 Urmas 2011-03-28 16:48:23 UTC
> The grid background must not follow the theme color.

Of course it should, the screen color demonstrates colorless paper. If user uses black windows they should use white font to demonstrate default black.

wysiwig real opaque white color for something that not exists like paint on white paper is awful analogy.
Comment 8 Jean Bréfort 2011-03-29 19:47:25 UTC
I don't agree. If we follow theme background, we must map each printed color to a screen color. I don't think themes do that.
In alll case, I'll not make any effort to fix that.
Comment 9 Jean Bréfort 2011-04-22 11:59:29 UTC
What might make sense would be the option to change the defaul background color for the sheet since one can print on colored paper.
Comment 10 Andreas J. Guelzow 2012-08-13 05:58:48 UTC
*** Bug 681715 has been marked as a duplicate of this bug. ***
Comment 11 Olivier 2012-11-20 17:01:59 UTC
I came here because I can’t use Gnumeric because of the white background (it hurts too much). Idealy Gnumeric should use the default background and foreground colours of the theme when displaying on screen, and translate this to black on white when printing.

However I understand that when different than default colours are used, it becomes problematic: if a user can’t stand white backgrounds and uses a dark theme, he will want to use dark bg and bright text on screen, but probably the opposite on paper.

Maybe the simplest solution is to add an “invert brightness” option to change dark colours into bright colours, and bright colours into dark colours, on screen? That would be very helpfull for people who need dark colours on screen.
Comment 12 dicktyr 2017-02-02 20:19:58 UTC
I'm surprised this issue has not received more attention. Computer displays are brighter than ever and white is *maximum intensity*, certainly not paper white (persistent as that assumption may be).

I understand the concerns about printing, but I think the problem is easily solved without ignoring the theme.

Think of layers:

    cell text/graphics: printable
    cell background: printable (*transparent* by default)
    base layer: *not* printable (white)

Currently, the theme background is ignored and replaced with white.

The rationale seems to be that most users print on "white" paper, but paper is essentially transparent; i.e. it is the absence of print/ink. So the problem is: what to display beneath printable objects. Since the theme background essentially corresponds/maps to paper, I see no reason that it should be considered in printing. Cell background should of course be considered in printing.

If the developers still have concerns, an option can be used to select the base layer: white or the theme background.

Please comment.

By the way, I've been using Gnumeric and other spreadsheet software for many years and I don't recall ever printing a spreadsheet. ;}

I also manually change the cell background to avoid eye strain but that strategy is tedious because moving cells by drag/drop removes the background.
Comment 13 Morten Welinder 2017-02-02 22:03:22 UTC
All windows support has ceased.
Comment 14 GNOME Infrastructure Team 2018-05-22 13:35:38 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/131.