Bug 51300 - VIEWING: Comments are not readable (shown in white over yellow)
Summary: VIEWING: Comments are not readable (shown in white over yellow)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: BSA target:4.1.0 target:4.0.4
Keywords:
: 33954 51839 61986 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-06-21 07:43 UTC by Antonio Martins
Modified: 2013-06-06 16:08 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample spreadsheet created in Excel 2010 saved as xls format. It contains a comment. It was never edited by LibreOffice. (23.00 KB, application/vnd.ms-excel)
2012-06-21 07:43 UTC, Antonio Martins
Details
Spreadsheet with a comment, but after being edited in LibreOffice 3.5.4.2 in Ubuntu 11.10 (6.50 KB, application/vnd.ms-excel)
2012-07-10 15:23 UTC, Antonio Martins
Details
Dependencies from Ubuntu's Libreoffice 3.5.4 on Ubuntu 12.04 (4.31 KB, text/plain)
2012-12-16 14:24 UTC, vulcain
Details
config.log bzipped2 (19.93 KB, application/bzip2)
2012-12-16 14:36 UTC, Julien Nabet
Details
Screenshot from Ubuntu 12.10 LibreOffice 3.6.4 (14.18 KB, image/png)
2012-12-17 21:57 UTC, Antonio Martins
Details
tools-options (54.69 KB, image/png)
2012-12-17 21:58 UTC, Antonio Martins
Details
Bug 51300 screenshot from Windows XP LibreOffice 3.6.3 (91.26 KB, image/jpeg)
2012-12-17 22:14 UTC, bfoman (inactive)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio Martins 2012-06-21 07:43:33 UTC
Created attachment 63306 [details]
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.
Comment 1 bfoman (inactive) 2012-07-05 03:04:56 UTC
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.
Comment 2 vulcain 2012-07-08 01:51:21 UTC
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
Comment 3 Jean-Baptiste Faure 2012-07-08 01:54:35 UTC
*** Bug 51839 has been marked as a duplicate of this bug. ***
Comment 4 vulcain 2012-07-08 12:19:43 UTC
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).
Comment 5 Antonio Martins 2012-07-10 14:53:47 UTC
Could not reproduce with Windows XP home edition and LibreOffice 3.5.2.2
Comment 6 Antonio Martins 2012-07-10 15:04:08 UTC
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?
Comment 7 Antonio Martins 2012-07-10 15:23:04 UTC
Created attachment 64075 [details]
Spreadsheet with a comment, but after being edited in LibreOffice 3.5.4.2 in Ubuntu 11.10
Comment 8 vulcain 2012-07-11 09:42:57 UTC
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
Comment 9 bfoman (inactive) 2012-07-12 07:00:43 UTC
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.
Comment 10 Urmas 2012-12-13 09:29:09 UTC
Into a loonix bin.
Comment 11 Julien Nabet 2012-12-16 11:08:48 UTC
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)?
Comment 12 vulcain 2012-12-16 13:46:50 UTC
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 ??
Comment 13 vulcain 2012-12-16 14:24:37 UTC
Created attachment 71586 [details]
Dependencies from Ubuntu's Libreoffice 3.5.4 on Ubuntu 12.04

From apport-cli --save ~/Desktop/dependencies_libo.txt libreoffice-calc
Comment 14 Julien Nabet 2012-12-16 14:36:37 UTC
Created attachment 71587 [details]
config.log bzipped2
Comment 15 Julien Nabet 2012-12-16 18:29:37 UTC
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.
Comment 16 Antonio Martins 2012-12-16 23:54:57 UTC
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
Comment 17 Antonio Martins 2012-12-17 00:06:06 UTC
Can still reproduce it in Ubuntu 12.10 LibreOffice Version 3.6.4.3 (Build ID: 360m1(Build:3))
Comment 18 Michael Meeks 2012-12-17 21:40:13 UTC
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.
Comment 19 Antonio Martins 2012-12-17 21:57:53 UTC
Created attachment 71700 [details]
Screenshot from Ubuntu 12.10 LibreOffice 3.6.4

This is the requested screenshot.
Comment 20 Antonio Martins 2012-12-17 21:58:42 UTC
Created attachment 71701 [details]
tools-options

All options -> appearance are "automatic".
Comment 21 bfoman (inactive) 2012-12-17 22:14:43 UTC
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.
Comment 22 Antonio Martins 2012-12-17 22:18:33 UTC
After removing ~/.libreoffice, in Ubuntu 12.10 LibreOffice Version 3.6.4.3 (Build ID: 360m1(Build:3)) it can still be replicated.
Comment 23 Antonio Martins 2012-12-17 22:23:57 UTC
(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.
Comment 24 Antonio Martins 2012-12-17 22:25:03 UTC
(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.
Comment 25 Antonio Martins 2012-12-17 22:40:33 UTC
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).
Comment 26 Antonio Martins 2012-12-17 22:41:09 UTC
Tried with LibreOffice Version 4.0.0.0.alpha1 (Build ID: 400m0(Build:1)), but the problem still replicates in Ubuntu 12.10.
Comment 27 vulcain 2012-12-17 23:13:41 UTC
> 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 [details]) in my differents VM.
Comment 28 Antonio Martins 2012-12-17 23:30:55 UTC
Could not reproduce with clean Fedora Core 17, KDE 4.9.3 and LibreOffice 3.5.5.3 
Build ID: 350m1(Build:3)
Comment 29 Michael Meeks 2012-12-18 12:45:01 UTC
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 <noel.power@novell.com>
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 ].
Comment 30 Noel Power 2012-12-18 17:39:34 UTC
(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 ?
Comment 31 Noel Power 2012-12-18 19:12:43 UTC
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
Comment 32 vulcain 2013-01-09 12:12:47 UTC
The problems are always here in LibreOffice 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0)
Comment 33 Cédric Bosdonnat 2013-04-26 12:46:50 UTC
*** Bug 33954 has been marked as a duplicate of this bug. ***
Comment 34 Noel Power 2013-05-07 13:41:17 UTC
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
Comment 35 Commit Notification 2013-05-07 15:49:17 UTC
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.
Comment 36 Jean-Baptiste Faure 2013-05-09 20:28:45 UTC
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
Comment 37 Commit Notification 2013-05-13 10:43:56 UTC
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.
Comment 38 vulcain 2013-05-26 17:17:15 UTC
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
Comment 39 Noel Power 2013-05-27 08:31:41 UTC
(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
Comment 40 vulcain 2013-05-27 13:47:18 UTC
(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
Comment 41 ign_christian 2013-05-27 16:20:15 UTC
set status to UNCONFIRMED -> shouldn't be NEEDINFO ?
Comment 42 Noel Power 2013-05-27 16:33:08 UTC
lets just marked this as fixed, if someone finds the problem ( first attachment only please ) then please reopen
Comment 43 andis.lazdins 2013-05-28 05:52:19 UTC
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
Comment 44 Julien Nabet 2013-05-28 06:04:11 UTC
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
Comment 45 andis.lazdins 2013-05-28 09:03:44 UTC
(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!
Comment 46 vulcain 2013-05-31 19:52:14 UTC
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
Comment 47 papukaija 2013-06-06 16:08:19 UTC
*** Bug 61986 has been marked as a duplicate of this bug. ***