Issue 74816 - system colors are not respected by equation object
Summary: system colors are not respected by equation object
Alias: None
Product: Math
Classification: Application
Component: ui (show other issues)
Version: OOo 2.1
Hardware: All Windows, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: eric.savary
QA Contact: issues@sw
Keywords: accessibility
Depends on:
Reported: 2007-02-23 16:16 UTC by domel72
Modified: 2013-08-07 14:56 UTC (History)
2 users (show)

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

HC screenshot (7.71 KB, image/jpeg)
2007-03-16 18:20 UTC, eric.savary
no flags Details
Sample document to verify the issue (16.80 KB, application/octet-stream)
2009-07-22 14:32 UTC, thomas.lange
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description domel72 2007-02-23 16:16:28 UTC
Under linux with KDE and text color set system-wide to white and background
color to black, entering of math formulas is impossible, Note that color white
{x over y} won't do because the document has to be printed on paper at the end.

Under windows, it's better, but still e.g. the "Hight Contrast Black" scheme is
not fully respected: I can edit the formula seeing what I type, only when I exit
the edit mode at the end the equation is invisible on the (black) background due
to presumably hardcoded default font color (black). Again, font white {x over y}
will not do because of printing. What is needed is automatic font color as is
the case with the normal text color.
Comment 1 michael.ruess 2007-02-26 09:16:40 UTC
Reassigned to ES.
Comment 2 eric.savary 2007-03-16 18:18:49 UTC
I cannot reproduce it (See attachement).
Which KDE are you using and which Color Scheme?
Comment 3 eric.savary 2007-03-16 18:20:26 UTC
Created attachment 43767 [details]
HC screenshot
Comment 4 domel72 2007-03-23 08:41:39 UTC
I use OO 2.0.4 and KDE 3.3.5 (debian testing).
I change bg color in Options to black and leave font color automatic. While I
enter the formula I can see it. As soon as I exit the formula editor the
equation is gone (leaving only a box visible). While entering the equation the
editor background is white and font is black despite my color settings both in
system and in Options. This causes high strain for eyes.
Comment 5 eric.savary 2007-03-23 10:36:09 UTC
TL> this issue is about formula as OLE-cbject. In view mode (not inplace editing
mode), the foreground color appears black on black in HC mode.

BTW: same thing on Windoes.
Comment 6 Mathias_Bauer 2007-12-03 11:00:49 UTC
target 3.x
Comment 7 ace_dent 2008-02-23 14:07:03 UTC
Related to Issue 52511?
Comment 8 eric.savary 2008-09-30 14:27:34 UTC
Retargetting 3.1: This issue makes the use of formula in Writer useless while
using high contrast.
Comment 9 thomas.lange 2009-01-19 14:41:58 UTC
Not time left to fix  this one in OO0 3.1 because of other issues.
Comment 10 tab 2009-01-19 19:45:28 UTC
 Under OO3.0: I chose Turquoise 8 as document background. However, the
'automatic' text colour was black, which is not quite visible on Turquoise 8
(Issues 42330, 45770); so, I set the text to white.
Now, open a Math edit window: The background is white is the text! That
makes it invisible...
If the background is white (apparently, unchangeable), the text colour should
remain black.
Comment 11 malte_timmermann 2009-03-04 14:24:17 UTC
Target 3.2
Comment 12 thomas.lange 2009-03-06 11:34:07 UTC
Comment 13 thomas.lange 2009-03-09 12:44:16 UTC
It works fine with chart OLE objects in Writer but not with starmath OLE objects
when one sets the color scheme to "High Contrast Black".

The reason is: 
At the top in sw the function SwViewImp::PaintLayer is called and sets
DRAWMODE_SETTINGSFILL when changing into high contrast mode. 
At the bottom in Writers function SwNoTxtFrm::PaintPicture the following lines
are called to get the high contrast replacement image
		Graphic* pGraphic = NULL;
   		if ( pOut && ( pOut->GetDrawMode() & DRAWMODE_SETTINGSFILL ) )
			pGraphic = pOLENd->GetHCGraphic();
This works fine with chart but not with starmath objects.
For chart the function is called with DRAWMODE_SETTINGSFILL set but that is not
the case for starmath.
The calltree for this function for startmath objects is different from the one
for chart objects even though both are OLE objects.

The difference occurs in the file objectcontactofpageview.cxx in svx within the
function ObjectContactOfPageView::DoProcessDisplay. Here the code looks like this:
            delete pProcessor2D;
For chart obejects the function pProcessor2D->process is called but not for math
objects since already xPrimitiveSequence.hasElements() returns false.

Thus for math objects the call to SwNoTxtFrm::PaintPicture does not occur within
the call hierachy of SwViewImp::PaintLayer but only after that function, and at
that point DRAWMODE_SETTINGSFILL has already been reset at the end of

TL->AW: The question is since both objetcs are OLE Objects shouldn't they be
handled about the same way by the drawinglayer? That is this issue to be fixed
in the drawing layer or in sw? 
It will be possible to do this in sw, but the available fix there may have more
global effects...

Comment 14 Armin Le Grand 2009-04-01 12:52:40 UTC
AW->TL: I am not sure how OLEs in SW are exactly painted since SW has it's own
OLEs. This should be true for charts and StarMath, though.
In both cases it is not a good idea to transport the HighContrast information in
the DrawMode at th OutputDevice using DRAWMODE_SETTINGSFILL. That test should
always be replaced with the one which initially sets that flag.

When the OLE is a drawinglayer OLE (SdrOle2Obj) the visualisation is done using
primitives which get the MetaFile from the OLE (and getting the HC case when

When the OLE is a SW OLE i guess it's using the mentioned SwNoTxtFrm. In that
case, a callback to that's old paint is done in the renderer. At that time, the
flags at the OutputDevice should be correct.

So currently i am not sure why it is not working and will need to debug myself.
Comment 15 edio 2009-04-06 10:56:30 UTC
Sorry for my English at first.

OOo formula editor does respect system colors.
But all formulas ARE PRINTED with the system color.

The same behaviour is under windows XP and under a archlinux.

Under windows color of formulas depends on COLOR_WINDOWTEXT in win32api

Under archlinux (and I think, the same is under other distrbutions) it depends 
on text[NORMAL] setting in gtk theme.

Do I need to submit this as a different bug/issue?
Comment 16 Armin Le Grand 2009-07-21 18:03:19 UTC
AW->TL: Checked in a DEV300 m52. The OutputDevice where DRAWMODE_SETTINGSFILL is
set in SwViewImp::PaintLayer is the same which is used in
SwNoTxtFrm::PaintPicture, thus pOLENd->GetHCGraphic() is used (and painted). All
is okay there. Pleasecheck if the error still happens in DEV300 m52 at all. If
Yes, it must be inside of GetHCGraphic.
Comment 17 thomas.lange 2009-07-22 14:10:57 UTC
As it turns out this one has to be fixed in SwNoTxtFrm::PaintPicture where the
	if ( pOut && ( pOut->GetDrawMode() & DRAWMODE_SETTINGSFILL ) )
		pGraphic = pOLENd->GetHCGraphic();
should evaluate 
Comment 18 thomas.lange 2009-07-22 14:32:21 UTC
Created attachment 63690 [details]
Sample document to verify the issue
Comment 19 thomas.lange 2009-07-22 14:38:41 UTC
The Windows specific problem (see first comment, second part) is now fixed in
CWS a11y32.

The remaining problem (see first comment, first part) is already addressed by
issue 35482. Thus everything should be fine when that latter one is fixed as well.

Comment 20 thomas.lange 2009-09-10 09:08:59 UTC
Comment 21 eric.savary 2009-09-15 11:54:51 UTC
Verified fix for Windows problem in CWS a11y32
Comment 22 malte_timmermann 2010-01-08 09:18:45 UTC
Fixed and integrated => closing now..