https://bugs.freedesktop.org/show_bug.cgi?id=51300
--- Comment #34 from Noel Power <[email protected]> --- 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 http://opengrok.libreoffice.org/xref/core/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx#3788 ( 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. see http://opengrok.libreoffice.org/xref/core/sc/source/filter/excel/xiescher.cxx#1739 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 -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
