[Upstream] VIEWING: Comments are not readable (shown in white over yellow)

Created attachment 63306
Sample spreadsheet created in Excel 2010 saved as xls format. It contains a comment. It was never edited by LibreOffice.

Problem description:
If you open a simple file in xls format, cell comments are shown in white over yellow colors. As a result, user cannot see the comment.

Steps to reproduce:
1. Create new spreadsheet in Excel 2007 or 2010
2. Insert a comment for one cell
3. Save as xls format
4. Open spreadsheet in LibreOffice

Current behavior:
The comment is in white over yellow

Expected behavior:
The comment should be in color "Automatic" and not white

Platform (if different from the browser):

Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1

Tested in LibreOffice 3.5.4, but same behavior in previous versions.

Checked with:
LO 3.5.4.2
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Could not reproduce. Comment is displayed as black text over yellow box. The same as in Excel 2010.

I reproduce with
*Ubuntu 11.10 Unity with ttf-mscorefonts
     -LibreOffice 3.4.4 OOO340m1 (Build:402) from Ubuntu
     -LibreOffice 3.6.0.0.beta3 (Build ID: 3e2b862)
*Ubuntu 12.04 Unity x86_64
     -LibreOffice 3.5.3.2 Version ID : 350m1(Build:2) from Ubuntu
     -LibreOffice 3.6.0.0.beta3 (Build ID: 3e2b862)

Don't reproduced (fr-discuss) with Ubuntu 11.10 Gnome Shell

May be similar like this one:
https://bugs.freedesktop.org/show_bug.cgi?id=51839

*** Bug 51839 has been marked as a duplicate of this bug. ***

Reproduce
* a fresh install of openSUSE 12.1 (x86_64) with KDE : 4.7.2 (4.7.2) "release 5" with LibreOffice 3.4.5 OOO340m1 (Build:1505) (without ttf-mscorefonts, i think)

Don't reproduce with a fresh install of Fedora 17 x86_64 with Gnome 3.4.2 and hardest install of Libreoffice 3.5.4.2 build ID: 350m1(build:2).

Could not reproduce with Windows XP home edition and LibreOffice 3.5.2.2

From the comments, it seems to affect only Ubuntu and OpenSuse distributions.

I was initially mislead because if the file is edited (like one single character added) to the original attached sample, then the issue starts showing in every platform. The attached version is simply the first one, but after opening in Ubuntu LibreOffice. you should notice that the problem is now actually saved in the file and it is shown in LO or excel in any platform.

Can you please verify this?

Created attachment 64075
Spreadsheet with a comment, but after being edited in LibreOffice 3.5.4.2 in Ubuntu 11.10

No it's affect Fedora KDE too

I continue tests with other distribution

Reproduce in
*Mageia 2 x86_64 with KDE 4.8.2 LibreOffice 3.5.3.2 Version ID : 350m1(Build:2)
*Ubuntu 10.04 32 bits Gnome 2.30.2 OpenOffice 3.2.0
*Xubuntu 12.04 64 bits Xfce Gnumeric 1.10.17
*Lubuntu 12.04 64 bits LXDE LibreOffice 3.5.3.2 Version ID : 350m1(Build:2) -> color Grey on yellow
*Xubuntu 12.04 64 bits Xfce 4.8 LibreOffice 3.5.3.2 Version ID : 350m1(Build:2) -> color Grey on yellow

Don't reproduce
*Mageia 2 (thornicroft) x86_64 in GNOME 3.4.1 Noyau Linux 3.3.6-desktop-2.mga2 *LibreOffice 3.5.3.2 Version ID : 350m1(Build:2)
*Xubuntu 12.04 64 bits Xfce 4.8 Gnumeric 1.10.17
*Lubuntu 12.04 64 bits LXDE Gnumeric 1.10.17
*Linux Mint 13 Maya x86_64 GNOME 3.4.1 Cynammon LibreOffice 3.5.3.2 Build ID: 350m1(Build:2)
*Debian 6 x86_64 Gnome 2.30.2 Openofice.org 3.2.1 OOO320m19 (Build9505) ooo-build 3.2.1.4, Debian package 1:3.2.1-11+squeze6

comment-test-after-LO.xls: Never see the comment. Tested:
*Ubuntu 12.04 Unity x86_64 LibreOffice 3.5.3.2
*Ubuntu 11.10 Unity LibreOffice 3.4.4 OOO340m1
*Fedora 17 x86_64 with Gnome 3.4.2 Libreoffice 3.5.4.2
*Mageia 2 x86_64 with KDE 4.8.2 LibreOffice 3.5.3.2 Version ID : 350m1(Build:2)
*Mageia 2 x86_64 in GNOME 3.4.1 LibreOffice 3.5.3.2 Version ID : 350m1(Build:2)
*Linux Mint 13 Maya x86_64 GNOME 3.4.1 Cynammon LibreOffice 3.5.3.2 Build ID: 350m1(Build:2)
*OpenSUSE 12.1 (x86_64) with KDE : 4.7.2 (4.7.2) "release 5" with LibreOffice 3.4.5 OOO340m1 (Build:1505)
*Ubuntu 10.04 32 bits Gnome 2.30.2 OpenOffice 3.2.0
*Xubuntu 12.04 64 bits Xfce 4.8 Gnumeric 1.10.17 or LibreOffice 3.5.3.2 Version ID : 350m1(Build:2)
*Lubuntu 12.04 64 bits LXDE Gnumeric 1.10.17 or LibreOffice 3.5.3.2 Version ID : 350m1(Build:2)
*Debian 6 x86_64 Gnome 2.30.2 Openofice.org 3.2.1 OOO320m19 (Build9505) ooo-build 3.2.1.4, Debian package 1:3.2.1-11+squeze6

Confirmed with:
LO 3.5.5.3
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

comment-test-after-LO.xls - comment is invisible (white color) with gfx artifacts of comment frame after fading out.

Into a loonix bin.

On pc Debian x86-64 with 3.6 sources updated some days ago, I don't reproduce this.

1) I retrieved first attachment, opened it, the comment was written on black on light yellow, so ok.
2) I changed a cell, saved in xls, reopen the file, same behaviour

On Win7 64 with 3.6.4.3, idem.

Antonio, Vulcain, bfoman: could you give a try with a newer LO version (3.6.4)?

Don't see comments of this two files with:
* Libo 3.6.2.2 (Build ID:360m1 (build2)) from Ubuntu 12.10.It's the pakage from Ubuntu
* Apache OpenOffice 3.4.1 on Ubuntu 12.10
* Version 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7) on Ubuntu 12.04.1
* OpenOffice.org 3.4.1 AOO341m1 (Build:9593) - Rev 1372282 2012-08-13 06:23:26 (Mon, 13 Aug 2012 - Linux x86_64 on Ubuntu 12.10

May, a forgotten package with Ubuntu ??

Created attachment 71586
Dependencies from Ubuntu's Libreoffice 3.5.4 on Ubuntu 12.04

From apport-cli --save ~/Desktop/dependencies_libo.txt libreoffice-calc

Created attachment 71587
config.log bzipped2

Michael: Vulcain did a lot of tests and is keeping on right now with newer versions.
Do you have any idea how to dig about this to understand why sometimes it works, sometimes it doesn't? We don't succeed in finding the discriminant element.

I can still reproduce it in Ubuntu 12.10, LO Version 3.6.2.2 (Build ID: 360m1(Build:2))

I will try with a newwer version of LO

Can still reproduce it in Ubuntu 12.10 LibreOffice Version 3.6.4.3 (Build ID: 360m1(Build:3))

Can't reproduce with master, 4.0 latest, 3.5 suse version, or 3.6.1.2 on SUSE.
In every case I have one hidden comment, which when shown shows up in black fonts on a yellow note background as ~expected.

Can someone attach a screenshot of this ? Does it do the same with a clean profile ? what does tools->options->appearance say (are any of those not 'automatic').

vulcain - how are you testing so many distros ? :-) it's amazing. Do you transfer anything between machines ? do you do any configuration ?

3.5.x is a dead branch now for this sort of fix.

So - is there anyone apart from vulcain who has managed to reproduce this in 3.6 or preferably 4.0 ?

Also - quite why this is a 4.0 MAB is unclear to me - if anything it should be 3.6 - I'll drop from 4.0 for now.

Created attachment 71700
Screenshot from Ubuntu 12.10 LibreOffice 3.6.4

This is the requested screenshot.

Created attachment 71701
tools-options

All options -> appearance are "automatic".

Created attachment 71703
Bug 51300 screenshot from Windows XP LibreOffice 3.6.3

(In reply to comment #9)
> Confirmed with:
> LO 3.5.5.3
> Build ID: own W7 debug build
> Windows 7 Professional SP1 64 bit
>
> comment-test-after-LO.xls - comment is invisible (white color) with gfx
> artifacts of comment frame after fading out.

Confirmed with:
LO 3.6.3.2
Build ID: 58f22d5
Windows XP Professional SP3

Screenshot attached.

After removing ~/.libreoffice, in Ubuntu 12.10 LibreOffice Version 3.6.4.3 (Build ID: 360m1(Build:3)) it can still be replicated.

(In reply to comment #21)
> Created attachment 71703 [details]
> Bug 51300 screenshot from Windows XP LibreOffice 3.6.3
>
> (In reply to comment #9)
> > Confirmed with:
> > LO 3.5.5.3
> > Build ID: own W7 debug build
> > Windows 7 Professional SP1 64 bit
> >
> > comment-test-after-LO.xls - comment is invisible (white color) with gfx
> > artifacts of comment frame after fading out.
>
> Confirmed with:
> LO 3.6.3.2
> Build ID: 58f22d5
> Windows XP Professional SP3
>
> Screenshot attached.

Please make sure that you use comment 63303. After opening once with LO and saving the file there, the comment gets really saved white over yellow in the file. Just take the attachment, open it and check if it shows white over yellow or not.

(In reply to comment #23)
> (In reply to comment #21)
> > Created attachment 71703 [details]
> > Bug 51300 screenshot from Windows XP LibreOffice 3.6.3
> >
> > (In reply to comment #9)
> > > Confirmed with:
> > > LO 3.5.5.3
> > > Build ID: own W7 debug build
> > > Windows 7 Professional SP1 64 bit
> > >
> > > comment-test-after-LO.xls - comment is invisible (white color) with gfx
> > > artifacts of comment frame after fading out.
> >
> > Confirmed with:
> > LO 3.6.3.2
> > Build ID: 58f22d5
> > Windows XP Professional SP3
> >
> > Screenshot attached.
>
> Please make sure that you use attachment 63303. After opening once with LO and
> saving the file there, the comment gets really saved white over yellow in
> the file. Just take the attachment, open it and check if it shows white over
> yellow or not.

Sorry about the noise in the last two comments. What i meant is that you should use the first attachment (the one never edited by LibreOffice).

Tried with LibreOffice Version 4.0.0.0.alpha1 (Build ID: 400m0(Build:1)), but the problem still replicates in Ubuntu 12.10.

> vulcain - how are you testing so many distros ? :-) it's amazing. Do you
> transfer anything between machines ? do you do any configuration ?

No,
For comment #8 i downlaod the ISO, load it on Virtualbox. Inside Virtualbox, i launch Firefox for downlaod the files and launch LibreOffice. I only update distros, no install (for exemple in Ubuntu, i don't install Base - except for Ubuntu 12.04.1). Each Virtualbox are separed with the other, no data share.

For comment #12, i launch Ubuntu 12.10 in VM, i delet LibreOffice with sudo apt-get remove and install Apache OpenOffice.org 3.4.1 AOO341m1 (with dpkg -i *.deb)

I see the same screenshot like Antonio Martins (attachment 71700) in my differents VM.

Could not reproduce with clean Fedora Core 17, KDE 4.9.3 and LibreOffice 3.5.5.3
Build ID: 350m1(Build:3)

Noel - as I recall you did a load of fixing in this area for a recent LibreOffice - perhaps you can help unwind this.

Please avoid cluttering the bug with details about 3.5.x versions - development of and new releases for that branch is long dead. Also anything prior to 3.6.2 is also not that useful we had significant fixes in this area for 3.6.3:

commit 46f9e6ce6b9fc6c21c1d682a35954523ed435647
Author: Noel Power <email address hidden>
Date: Thu Aug 9 11:15:43 2012 +0100

    misc comment import/export fixes

    a) fix vmldrawing.vml for xlsx export ( changed from frame to textbox, added
    support for shadow element with attributes, shadow color, shadow obscured )
    b) use proper fillcolor attribute
    c) detect whether note/comment is shown on import
    d) export state of note ( shown/hidden )

etc. - that fixed note show/hide serialization, and added a number of other features to import/export there.

Thanks Antonio for this:

> After removing ~/.libreoffice, in Ubuntu 12.10 LibreOffice Version 3.6.4.3
> (Build ID: 360m1(Build:3)) it can still be replicated.

it's good to know it's not profile related :-)

bfoman - thanks for the screenshot; it really is extraordinary - I still can't repeat the problems on load here [ and the save/re-load thing is not good to tangle up with this bug IMHO ].

(In reply to comment #29)
> Noel - as I recall you did a load of fixing in this area for a recent
> LibreOffice - perhaps you can help unwind this.
well the work I did was around xlsx not binary format stuff ( and it was export ) But I admit I am confused here, I just spent quite some time trying to reproduce this by import then export/saving and also reading the export related code ( perhaps I didn't read the comments above carefully enough ) but I see in comment #25 ( and indeed in the previous comment at the end ) that this is an import problem, is that right ?

ok I this is a system - gnome/kde/whatever settings thing

after chasing through the binary format, in sample doc the colour id
associated with the font used for the caption text has an id of 0x51,
there is no colour palette associated with this document so we fall down into

ColorData XclDefaultPalette::GetDefColorData( sal_uInt16 nXclIndex ) const
{
    ColorData nColor;
    if( nXclIndex < mnTableSize )
        nColor = mpnColorTable[ nXclIndex ];
    else switch( nXclIndex )
    {
        case EXC_COLOR_WINDOWTEXT3:
        case EXC_COLOR_WINDOWTEXT:
        case EXC_COLOR_CHWINDOWTEXT: nColor = mnWindowText; break;
        case EXC_COLOR_WINDOWBACK3:
        case EXC_COLOR_WINDOWBACK:
        case EXC_COLOR_CHWINDOWBACK: nColor = mnWindowBack; break;
        case EXC_COLOR_BUTTONBACK: nColor = mnFaceColor; break;
        case EXC_COLOR_CHBORDERAUTO: nColor = COL_BLACK; break; // TODO: really always black?
        case EXC_COLOR_NOTEBACK: nColor = mnNoteBack; break;
        case EXC_COLOR_NOTETEXT: nColor = mnNoteText; break;
        case EXC_COLOR_FONTAUTO: nColor = COL_AUTO; break;
        default:
            OSL_TRACE( "XclDefaultPalette::GetDefColorData - unknown default color index: %d", nXclIndex );
            nColor = COL_AUTO;
    }

where 0x51 corresponds to EXC_COLOR_NOTETEXT and mnNoteText is initialised with

in sc/source/filter/excel/xlstyle.cxx

mnNoteText is initialised

  mnNoteText = rSett.GetHelpTextColor().GetColor();

presumably that is picked up from the system ( and must be white in the reporters case )

don't know what the real solution is here though to ensure that we have a decent
colour, maybe Michael has an idea

The problems are always here in LibreOffice 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0)

*** Bug 33954 has been marked as a duplicate of this bug. ***

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

Noel Power committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=64fed0c4fde695bb7978390d2e0a303dc6d53fe7

fix for fdo#51300

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Hmmm, that's weird: I do not reproduce the bug anymore with LO 4.0.3. And it works as expected with the current master (Version: 4.1.0.0.alpha1+
Build ID: 64670c3ea25b0f8c8975946971b041b71f36206). What changed for me is that now I use XFCE instead of Gnome-shell. As a consequence I can't confirm that the Noel's patch fixes the problem. So, can somebody else try again with LO 4.0.3 and the master ?

Best regards. JBF

Noel Power committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=08cfff8437bf8ec13bd9c1ccfa99ad2a7bde6756&h=libreoffice-4-0

fix for fdo#51300

It will be available in LibreOffice 4.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

With LibreOffice 4.1.0.0.beta1
Build ID: 3a2c2d2417101e45fe07cfd8358acf2204a98f3 on Ubuntu 12.04.2 x86_64

We can see only the comments in comment-test.xls, dont work with coment-test-after-LO.xls

(In reply to comment #38)
> With LibreOffice 4.1.0.0.beta1
> Build ID: 3a2c2d2417101e45fe07cfd8358acf2204a98f3 on Ubuntu 12.04.2 x86_64
>
> We can see only the comments in comment-test.xls,
That's good, seems like things are working then
> dont work with coment-test-after-LO.xls
That's expected, this is an import problem ( where the colour of the import note text is not what it should be ), "coment-test-after-LO.xls" like it's name suggests is the previously imported file ( with badly imported colours ) exported ( which of course will now also contain incorrect colours ) I am pretty sure if you open that file in Excel you wont be able to see the comments either

(In reply to comment #39)
> I am
> pretty sure if you open that file in Excel you wont be able to see the
> comments either

I could not confirm that, Microsoft don't sell it on GNU/Linux :-p

set status to UNCONFIRMED -> shouldn't be NEEDINFO ?

lets just marked this as fixed, if someone finds the problem ( first attachment only please ) then please reopen

The problem is still there in Libreoffice 4.0.3, Ubuntu 12.04 Mate desktop environment, Metacity window manager. The comment in the first attachment is not visible in Libreoffice

Andis: as indicated in Whiteboard, the bug is fixed from 4.0.4 version.
Don't hesitate to reopen if it's still there with 4.0.4

(In reply to comment #42)
> lets just marked this as fixed, if someone finds the problem ( first
> attachment only please ) then please reopen

Sorry for misunderstanding!

I just tested it on Version: 4.1.0.0.beta1 Build ID: 3a2c2d2417101e45fe07cfd8358acf2204a98f3 and comments appears just like they should.

And thank you for excellent fix!

We can see comment of comment-test.xls with LibreOffice 4.0.4.1 (Build ID: 7fdd5ee61c1c7379dd088f5d50265f0adbccf53) (Don't wotk for coment-test-after-LO.xls)

Thanks for the backport

*** Bug 61986 has been marked as a duplicate of this bug. ***