Apache OpenOffice (AOO) Bugzilla – Issue 18630
Auto text colour should be white when background is >= 70% gray
Last modified: 2014-09-24 03:31:16 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.
Created attachment 8735 [details] .sxw export to .doc to see desired behaviour
cmc->fme: A 100doctest bug, can we use white for the auto colour for at least the backgrounds where the text says "Test white" ?
Setting target
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.
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.
Okay, will have a look. Problem might be, that other places using IsDark/IsBright don't want to copy the competitor's behaviour.
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?
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 :-)
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.
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.
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.
Created attachment 13724 [details] Color-test doc
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.
according to http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7690 this issue will be set to OOoLater
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).
Apologies. In the last sentence of my previous comment, I meant "switching to a white foreground".
Created attachment 83979 [details] Generally Used Color Test Case Use the preset background color options to check the automatic font color. The problem still seems to exist in several of these cases.