Re: [Libreoffice-ux-advise] [PATCH] fdo#35365 default font color for documents
Am Mittwoch, den 27.06.2012, 10:56 +0200 schrieb Stefan Knorr: Hi all, I am not a user of high-contrast themes, and might not be able to help very much here. I am adding Christophe from a11y here who might be able to share some more ideas. So, High-Contrast... there are two types of high-contrast themes in most OS's, namely dark on light and light on dark. I think the users of the different types have different needs, too. Ooo, and thus, LibO generally cater to light on dark themes (as is evident in our hicontrast theme). Which incidentally, is the type of theme making trouble here. The question is: Should the theme influence the document? What does other application do? Does an image viewer increases the contrast of an image if the user uses a high-contrast theme? Does a PDF viewer displays a PDF file differently if the user uses a high-contrast theme? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] [PATCH] fdo#35365 default font color for documents
Hi all, I am not a user of high-contrast themes, and might not be able to help very much here. I am adding Christophe from a11y here who might be able to share some more ideas. So, High-Contrast... there are two types of high-contrast themes in most OS's, namely dark on light and light on dark. I think the users of the different types have different needs, too. Ooo, and thus, LibO generally cater to light on dark themes (as is evident in our hicontrast theme). Which incidentally, is the type of theme making trouble here. Thus, even though I generally like Benjamin's patch, I am not sure either that it's doing the right thing. Christophe, can you help? Astron. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#35365 default font color for documents
Hi Benjamin, On 2012-06-23 at 19:57 +0200, Benjamin Drung wrote: I am afraid this breaks the way we are handling the hicontrast theme that is supposed to target visually impaired people - we use dark background and white text in the hicontrast case (which wouldn't be the case any more with this patch). Adding the UX advise people what they think - I have no experience with accessibility, so cannot say what is right in this area. If they agree that we should let the hicontrast behavior as it is, I'd prefer: case DOCCOLOR : -aRet = Application::GetSettings().GetStyleSettings().GetWindowColor(); +aRet = Application::GetSettings().GetStyleSettings().GetHighContrastMode()? COL_BLACK: COL_WHITE; break; and similarly for FONTCOLOR - how does that sound to you? Does it make a difference for visually impaired people between black on white and white on black? I have no idea :-( What I wanted to say was that we were handling the color the way I described, but unfortunately I still do not know if it is the correct thing to do, or not - I hope the UX people will be able to help... Is it really a good idea to allow the desktop theme to influence the appearance of the document? Imagine following: I create a document where LibreOffice is configured with black font on white background. I select a brown 1 for the text and save it. Then someone with a hiconstrast theme opens the document and will see dark brown text on a black background. The contrast was reduces instead of increased. ...but you are right that the current handling of hicontrast would make this use case much worse. Please read bug #50861 and the examples given in comment 2 [1]. [1] https://bugs.freedesktop.org/show_bug.cgi?id=50861#c2 BTW, this all color setting thing requires a cleanup - why should we have the baroque StyleSettings class, and on top of that this ColorConfig approach to colors? Are you interested in cleaning up / consolidating the approach to colors as a follow-up? ;-) Yes and no. On the one hand it is appealing to me, but on the other hand other free software projects already consume enough of my spare time. Completely understood :-) All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#35365 default font color for documents
Hi, Am Freitag, den 08.06.2012, 21:47 +0200 schrieb Jan Holesovsky: Hi Benjamin, Benjamin Drung píše v Pá 08. 06. 2012 v 01:18 +0200: here's a patch to fix bug fdo#35365. Please also apply the patch in the 3.5 and 3.6 branch. The underlying bug fdo#50861 is only partially fixed by this patch. At least two solutions comes to my mind for a full fix: 1) Store the default colors in the document. 2) Hardcode the default colors. What do you think? What's the right approach to fix fdo#50861? Thank you very much for the patch! Unfortunately, I am afraid this breaks the way we are handling the hicontrast theme that is supposed to target visually impaired people - we use dark background and white text in the hicontrast case (which wouldn't be the case any more with this patch). Adding the UX advise people what they think - I have no experience with accessibility, so cannot say what is right in this area. If they agree that we should let the hicontrast behavior as it is, I'd prefer: case DOCCOLOR : -aRet = Application::GetSettings().GetStyleSettings().GetWindowColor(); +aRet = Application::GetSettings().GetStyleSettings().GetHighContrastMode()? COL_BLACK: COL_WHITE; break; and similarly for FONTCOLOR - how does that sound to you? Does it make a difference for visually impaired people between black on white and white on black? Is it really a good idea to allow the desktop theme to influence the appearance of the document? Imagine following: I create a document where LibreOffice is configured with black font on white background. I select a brown 1 for the text and save it. Then someone with a hiconstrast theme opens the document and will see dark brown text on a black background. The contrast was reduces instead of increased. Please read bug #50861 and the examples given in comment 2 [1]. [1] https://bugs.freedesktop.org/show_bug.cgi?id=50861#c2 BTW, this all color setting thing requires a cleanup - why should we have the baroque StyleSettings class, and on top of that this ColorConfig approach to colors? Are you interested in cleaning up / consolidating the approach to colors as a follow-up? ;-) Yes and no. On the one hand it is appealing to me, but on the other hand other free software projects already consume enough of my spare time. My current and all future contributions to LibreOffice, unless stated otherwise, are licensed under LGPLv3+/MPL until further notice. If you can send it as a separate mail, ideally with a subject like License statement, that would be most appreciated, so that we can clearly link that from the page where we collect the statements. Done. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#35365 default font color for documents
Hi Benjamin, Benjamin Drung píše v Pá 08. 06. 2012 v 01:18 +0200: here's a patch to fix bug fdo#35365. Please also apply the patch in the 3.5 and 3.6 branch. The underlying bug fdo#50861 is only partially fixed by this patch. At least two solutions comes to my mind for a full fix: 1) Store the default colors in the document. 2) Hardcode the default colors. What do you think? What's the right approach to fix fdo#50861? Thank you very much for the patch! Unfortunately, I am afraid this breaks the way we are handling the hicontrast theme that is supposed to target visually impaired people - we use dark background and white text in the hicontrast case (which wouldn't be the case any more with this patch). Adding the UX advise people what they think - I have no experience with accessibility, so cannot say what is right in this area. If they agree that we should let the hicontrast behavior as it is, I'd prefer: case DOCCOLOR : -aRet = Application::GetSettings().GetStyleSettings().GetWindowColor(); +aRet = Application::GetSettings().GetStyleSettings().GetHighContrastMode()? COL_BLACK: COL_WHITE; break; and similarly for FONTCOLOR - how does that sound to you? BTW, this all color setting thing requires a cleanup - why should we have the baroque StyleSettings class, and on top of that this ColorConfig approach to colors? Are you interested in cleaning up / consolidating the approach to colors as a follow-up? ;-) My current and all future contributions to LibreOffice, unless stated otherwise, are licensed under LGPLv3+/MPL until further notice. If you can send it as a separate mail, ideally with a subject like License statement, that would be most appreciated, so that we can clearly link that from the page where we collect the statements. Thank you a lot, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] [PATCH] fdo#35365 default font color for documents
Hi Benjamin, Benjamin Drung píše v Pá 08. 06. 2012 v 01:18 +0200: here's a patch to fix bug fdo#35365. Please also apply the patch in the 3.5 and 3.6 branch. The underlying bug fdo#50861 is only partially fixed by this patch. At least two solutions comes to my mind for a full fix: 1) Store the default colors in the document. 2) Hardcode the default colors. What do you think? What's the right approach to fix fdo#50861? Thank you very much for the patch! Unfortunately, I am afraid this breaks the way we are handling the hicontrast theme that is supposed to target visually impaired people - we use dark background and white text in the hicontrast case (which wouldn't be the case any more with this patch). Adding the UX advise people what they think - I have no experience with accessibility, so cannot say what is right in this area. If they agree that we should let the hicontrast behavior as it is, I'd prefer: case DOCCOLOR : -aRet = Application::GetSettings().GetStyleSettings().GetWindowColor(); +aRet = Application::GetSettings().GetStyleSettings().GetHighContrastMode()? COL_BLACK: COL_WHITE; break; and similarly for FONTCOLOR - how does that sound to you? BTW, this all color setting thing requires a cleanup - why should we have the baroque StyleSettings class, and on top of that this ColorConfig approach to colors? Are you interested in cleaning up / consolidating the approach to colors as a follow-up? ;-) My current and all future contributions to LibreOffice, unless stated otherwise, are licensed under LGPLv3+/MPL until further notice. If you can send it as a separate mail, ideally with a subject like License statement, that would be most appreciated, so that we can clearly link that from the page where we collect the statements. Thank you a lot, Kendy ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[PATCH] fdo#35365 default font color for documents
Hi,
here's a patch to fix bug fdo#35365. Please also apply the patch in the
3.5 and 3.6 branch.
The underlying bug fdo#50861 is only partially fixed by this patch. At
least two solutions comes to my mind for a full fix:
1) Store the default colors in the document.
2) Hardcode the default colors.
What do you think? What's the right approach to fix fdo#50861?
My current and all future contributions to LibreOffice, unless
stated otherwise, are licensed under LGPLv3+/MPL until further notice.
PS: Thanks to Björn Michaelsen, who helped me to dive into the code on
the LinuxTag.
--
Benjamin Drung
Debian Ubuntu Developer
From 456ec746d130d736caa526dfddc8d138fff6c797 Mon Sep 17 00:00:00 2001
From: Benjamin Drung bdr...@debian.org
Date: Fri, 8 Jun 2012 00:19:25 +0200
Subject: [PATCH] fdo#35365 Set the default font color to black and the
document color to white.
The font and document color of a Writer document or an Impress presentation
should not be derived from a desktop theme. A Writer documents needs to look
good on paper. An Impress presentation may have it's own theme. The appearance
of a document should not change by changing the desktop theme.
With this change a document looks the same on any computer if the user do not
change the default colors.
Change-Id: Ia42ca7882f0d2dd1f2a304db5e4b5aaba23244fc
---
svtools/source/config/colorcfg.cxx | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/svtools/source/config/colorcfg.cxx b/svtools/source/config/colorcfg.cxx
index abdb852..4f899af 100644
--- a/svtools/source/config/colorcfg.cxx
+++ b/svtools/source/config/colorcfg.cxx
@@ -412,12 +412,12 @@ Color ColorConfig::GetDefaultColor(ColorConfigEntry eEntry)
{
static const sal_Int32 aAutoColors[] =
{
-0, // DOCCOLOR
+COL_WHITE, // DOCCOLOR
0xc0c0c0, // DOCBOUNDARIES
0x808080, // APPBACKGROUND
0xc0c0c0, // OBJECTBOUNDARIES
0xc0c0c0, // TABLEBOUNDARIES
-0, // FONTCOLOR
+COL_BLACK, // FONTCOLOR
0xcc, // LINKS
0x80, // LINKSVISITED
0xff, // SPELL
@@ -462,18 +462,10 @@ Color ColorConfig::GetDefaultColor(ColorConfigEntry eEntry)
Color aRet;
switch(eEntry)
{
-case DOCCOLOR :
-aRet = Application::GetSettings().GetStyleSettings().GetWindowColor();
-break;
-
case APPBACKGROUND :
aRet = Application::GetSettings().GetStyleSettings().GetWorkspaceColor();
break;
-case FONTCOLOR :
-aRet = Application::GetSettings().GetStyleSettings().GetWindowTextColor();
-break;
-
case LINKS :
aRet = Application::GetSettings().GetStyleSettings().GetLinkColor();
break;
--
1.7.9.5
signature.asc
Description: This is a digitally signed message part
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
