Issue 18630 - Auto text colour should be white when background is >= 70% gray
Summary: Auto text colour should be white when background is >= 70% gray
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1 RC3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-25 13:53 UTC by caolanm
Modified: 2014-09-24 03:31 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
.sxw export to .doc to see desired behaviour (7.58 KB, application/octet-stream)
2003-08-25 13:54 UTC, caolanm
no flags Details
Color-test doc (36.99 KB, application/vnd.sun.xml.writer)
2004-03-11 15:58 UTC, thb
no flags Details
ODF sample file and exported PDF showing various colour combinations and their contrast ratios (80.17 KB, application/zip)
2013-08-08 18:34 UTC, Christophe Strobbe
no flags 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. (23.96 KB, application/vnd.oasis.opendocument.text)
2014-09-24 03:18 UTC, Kasey
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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
Setting target
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 12 thb 2004-03-11 15:58:45 UTC
Created attachment 13724 [details]
Color-test doc
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".
Comment 17 Kasey 2014-09-24 03:18:48 UTC
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.