Comment 38 for bug 1022640

indeed this seems to be something that is happening now in the later gnome3 enabled distros. The
analysis in comment #31 stands ( after debugging again on suse 12.3 where this is reproducible )

So some info Note text colour is taken from the system help text

( strange that equivalent the gnome3 specific stuff in gtk3salnativewidgets-gtk.cxx doesn't seem to get called, it wouldn't make any difference though in this case ) Also in salnativewidget.cxx the HelpText background ( used for setting the Notes background is NOT set ) again in this case it won't make any difference ( because here the Note background doesn't appear to be populated by a system specific colour code index but by a 'real' colour value )

Worse still is that the text for the note and the drawing associated with the note are read in completely different places ( by generic code ) The imported parts are only pulled together much later to create the note.


at this point of the import we could know about the background colour of the note ( drawing object ) The text colour for the note text is gleaned from the the text font ( but the text associated with the note could be rich text with multiple text runs and fonts ) Font related information including the text colour is read from a document wide buffer iirc, so those records are generic and nothing to do with the note itself. I suppose it would be possible to post process and adjust the text colour as necessary ( assuming one can find a function to compare how suitable a much a background and foreground colour contrast each other ) There are always I guess going to be problems when one colour is taken from a system setting and the other is a 'real' setting.

Beyond having some clever colour contrast adjusting code ( which I have no clue about ) I guess the easiest thing to do is to adjust the the colour chosen for a colour index ( e.g. EXC_COLOR_NOTETEXT ) in the hope the colour would be a better match.
However I think that we shouldn't initialise the colours for note text and background from the system but from libreoffice's own colour settings ( that at least would hopefully make it more unlikely that a 'default' colour matched with a real or 'hard' colour would be an unsuitable combination )

I will try to find where that colour information can be accessed and change the code as appropriate