Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Auto text colour should be white when background is >= 70% gray|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||andreas.martens, issues, kaseyepowers, strobbe|
|Version:||OOo 1.1 RC3|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description caolanm 2003-08-25 13:53:38 UTC
As the example .sxw to be attached shows it is impossible to read auto text when the background is >= 70% gray as the foreground used is black. The competitor uses white for this range.
Comment 1 caolanm 2003-08-25 13:54:08 UTC
Created attachment 8735 [details] .sxw export to .doc to see desired behaviour
Comment 2 caolanm 2003-08-25 13:56:38 UTC
cmc->fme: A 100doctest bug, can we use white for the auto colour for at least the backgrounds where the text says "Test white" ?
Comment 3 caolanm 2003-08-25 14:06:58 UTC
Comment 4 frank.meies 2003-08-25 14:18:42 UTC
FME->CMC: There are functions at the Color class (IsDark, IsBright), which are used for the autocolor calculation. Our code looks like this: if ( pCol->IsDark() && aTmpColor.IsDark() ) nNewColor = COL_WHITE; else if ( pCol->IsBright() && aTmpColor.IsBright() ) nNewColor = COL_BLACK; with pCol = background color, aTmpColor = window text color. The other applications should use the same code. So IsDark/IsBright need some adjustment. Please contact THB for details.
Comment 5 caolanm 2003-08-25 14:29:55 UTC
cmc->thb: What are our criteria for making the "auto" colour white or black ? For ms interoperability, as the example attaches shows, it looks like we should raise the luminance threshold considered dark to at least include these examples.
Comment 6 thb 2003-08-25 16:08:42 UTC
Okay, will have a look. Problem might be, that other places using IsDark/IsBright don't want to copy the competitor's behaviour.
Comment 7 thb 2004-02-19 14:00:13 UTC
THB->CMC: The list of places referencing IsDark()/IsBright() is in fact overwhelming, and includes places like sfx2, vcl, framework etc. Thus, cannot change the existing methods, but would provide you with a set of new (possibly standalone) methods for this task. Should I globally change all occurences in sw, or might there be exceptions? And is this (impress4ea1) bugfixing workspace okay for you, or do need it in one of your CWS?
Comment 8 caolanm 2004-02-19 14:22:43 UTC
cmc->thb: Please co-ordinate with ama/fme. IsBright/IsDark is not used directly by the filters so I nothing of their current sw usages, I just set an "use automatic" colour attribute, and writer/etc uses the output of IsBright/IsDark to decide what colour to display with. But I guess It depends on whether writer (the other applications of calc and impress are likely similiarly affected when importing auto colour from msoffice) just wants to do what ms does and break (fix :-)), older documents that use the current odd edge cases. And so just want to change their IsDark/IsBright calls. Or if they want to have a compatability option (or something of this nature) and want to be able to alternate using new methods instead of IsBright/IsDark. My opinion would be to change the impl of IsBright/IsDark and to hell with the consequences, who wants the current behaviour of auto foreground on dark gray to be invisible anyway :-)
Comment 9 andreas.martens 2004-02-20 11:47:50 UTC
AMA: Please don't change all occurrences in Writer. Only the one in source/core/text and source/core/txtnode. You may use any CWS you want.
Comment 10 thb 2004-02-27 20:17:06 UTC
Significantly changed the behaviour of autocolor fallbacks in sw/source/core/txtnode/fntcache.cxx. The intent of the code must have been to ensure sufficient contrast between background and text color. Now, when the text color (aTmpColor) is not a bright color (i.e. darker than 70% of full luminance), and the background contrasts properly only with white (i.e. darker than 0% of full luminance), then we enforce a white text color. Conversely, when the text color (aTmpColor) is not a dark color (i.e. brighter than 30% of full luminance), and the background contrasts properly only with black (i.e. brighter than 70% of full luminance), then we enforce a black text color. Ultimately, what's needed here is a proper color metric, where the _difference_ between foreground and background color determine autocolor enforcement. I'm a little bit reluctant to do _such_ a change, without knowing exactly what Word is doing here - postponed to Monday, have to consult FME.
Comment 11 thb 2004-03-11 15:54:46 UTC
I can basically fix this problem 98%, by using the following brightness calculation formula: b = 72r + 151g + 32b, with lower threshold 63. With the attached color test bugdoc, there are two cases left, where changes from black to white auto color deviate. I haven't had the time to dive into this much further, but it seems that Word either employs more than one threshold (and some continuity constraint), or maybe gamma-correct or whatever else non-linear function is applied.
Comment 13 thb 2004-03-11 16:02:35 UTC
THB->FL: Unfortunately, this fix will make our accessibility behaviour worse than before. As checked back with ES, some color contrasts in Word are really bad, from an accessibility point of view. Please decide the preference: compatibility or accessibility.
Comment 14 Martin Hollmichel 2004-08-09 14:02:40 UTC
according to http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7690 this issue will be set to OOoLater
Comment 15 Christophe Strobbe 2013-08-08 18:34:35 UTC
Created attachment 81292 [details] ODF sample file and exported PDF showing various colour combinations and their contrast ratios I rechecked this accessibility issue and created a test file with Apache OpenOffice 3.4.0 on Windows 7. This file contains paragraphs with “automatic” foreground colour on a variety of background colours and the contrast ratios for these colour combinations. The contrast ratio calculation is based on the contrast algorithm from the W3C's Web Content Accessibility Guidelines (WCAG) 2.0: http://www.w3.org/TR/WCAG20/#contrast-ratiodef. You can check the contrast ratio using a tool such as The Paciello Group's Contrast Analyser (for Windows and Mac): http://www.paciellogroup.com/resources/contrastAnalyser. I propose a threshold for switching to a white background when the contrast ratio according to WCAG 2.0 is lower than 4,5 to 1 (4,5:1).
Comment 16 Christophe Strobbe 2013-08-08 18:36:30 UTC
Apologies. In the last sentence of my previous comment, I meant "switching to a white foreground".