Issue 74816

Reassigned to ES.

I cannot reproduce it (See attachement).
Which KDE are you using and which Color Scheme?

Created attachment 43767 [details]
HC screenshot

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.

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.

target 3.x

Related to Issue 52511?

Retargetting 3.1: This issue makes the use of formula in Writer useless while
using high contrast.

Not time left to fix  this one in OO0 3.1 because of other issues.

 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 and...so is the text! That
makes it invisible...
If the background is white (apparently, unchangeable), the text colour should
remain black.

Target 3.2

.

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:
    if(xPrimitiveSequence.hasElements())
    {
        ...
        if(pProcessor2D)
        {
            pProcessor2D->process(xPrimitiveSequence);
            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
SwViewImp::PaintLayer...

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...

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
needed).

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.

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
http://msdn.microsoft.com/en-us/library/ms724371.aspx

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?

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.

As it turns out this one has to be fixed in SwNoTxtFrm::PaintPicture where the
lines 
	if ( pOut && ( pOut->GetDrawMode() & DRAWMODE_SETTINGSFILL ) )
		pGraphic = pOLENd->GetHCGraphic();
should evaluate 
    GetSettings().GetStyleSettings().GetHighContrastMode()
instead.

Created attachment 63690 [details]
Sample document to verify the issue

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.

.

Verified fix for Windows problem in CWS a11y32

Fixed and integrated => closing now..