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

Bug #1022640 reported by Mozaic on 2012-07-09
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
LibreOffice
Fix Released
Medium
libreoffice (Ubuntu)
Undecided
Unassigned

Bug Description

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

Not reproduce in
*Windows 7 Professional SP1 64 bit
    -LibreOffice 3.5.4.2
    -LibreOffice 3.6.0 beta 3
*Ubuntu 11.10 Gnome Shell
*Fedora 17 x86_64 with Gnome Shell 3.4.2 Libreoffice 3.5.4.2 build ID: 350m1(build:2)

Reproduce in:
*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)
*OpenSUSE 12.1 (x86_64) with KDE : 4.7.2 (4.7.2) "release 5" with LibreOffice 3.4.5 OOO340m1 (Build:1505)

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libreoffice-calc 1:3.5.3-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-26.41-generic 3.2.19
Uname: Linux 3.2.0-26-generic x86_64
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Mon Jul 9 18:56:49 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120328)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

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

Mozaic (mozaic) wrote :

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

Mozaic (mozaic) wrote :

With Lubuntu 12.04, work with Gnumeric 1.10.17. In LibreOffice 3.5.3.2, comment are grey on yellow -> reproduce this bug

Mozaic (mozaic) wrote :

Reproduce in Ubuntu 10.04 32 bits Gnome 3.30.2 OpenOffice.org 3.2.0

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.

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
summary: - VIEWING: Comments are not readable (shown in white over yellow)
+ [Upstream] VIEWING: Comments are not readable (shown in white over
+ yellow)

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

Changed in df-libreoffice:
status: Confirmed → Incomplete

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!

Changed in df-libreoffice:
status: Incomplete → Fix Released

Mozaic, thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed.

This is a significant bug in Ubuntu. If you need a fix for the bug in previous versions of Ubuntu, please do steps 1 and 2 of the SRU Procedure [1] to bring the need to a developer's attention.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Changed in libreoffice (Ubuntu):
status: New → Fix Released
Mozaic (mozaic) wrote :

@ Christopher M. Penalver: It's too big for me, to follow SRU procedure

Mozaic, one would only follow the SRU procedure if you needed a backport of the commit to a release prior to Saucy/Raring, and the LibreOffice PPA would not work for you. Would you need a backport?

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

Mozaic (mozaic) wrote :

I need a backport to Ubuntu 12.04 it's possible ??

Mozaic, have you tested the LibreOffice PPA via https://launchpad.net/~libreoffice/+archive/libreoffice-4-0?field.series_filter=precise to see if the issue is resolved for you in Precise?

Mozaic (mozaic) wrote :

Impossible to be in ppa, the fix in only in 4.0.4 who is in RC or in 4.1 who is in beta. This ppa only give the last stable who is 4.0.3
And i prefer a backport in libreoffice 3.5 who is the official version of LibreOffice in Ubuntu 12.04.

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.