Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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

Attachment: signature.asc
Description: This is a digitally signed message part


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.