Bug 37658 - text color FORMATING in calc
Summary: text color FORMATING in calc
Status: CLOSED DUPLICATE of bug 38956
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.0 RC1
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Eike Rathke
URL:
Whiteboard: numberformat target:3.5 target:3.4.3
Keywords: regression
: 39122 39571 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-27 02:02 UTC by SURCOUF
Modified: 2011-12-23 14:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample file to illustrate the bug (color format) (8.42 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-05-27 02:02 UTC, SURCOUF
Details
ODS file of English example in Comment 9 (7.91 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-08-01 11:53 UTC, Matt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description SURCOUF 2011-05-27 02:02:28 UTC
Created attachment 47217 [details]
Sample file to illustrate the bug (color format)

Hello,

I made a quick search to see if this bug has already been filed. I didn't find any. Sorry if ever it's the case.

In fact, being a teacher, I use to format my cells in CALC to differentiate marks under 10 using colors. When I do so the color format just disappear from the formatting. All of my assessment files are touched with this bug (files obtained from OOo2.3.0 since several years.

I attached a sample file to illustrate this issue.

Thanks to work on it.

Bunty
Comment 1 vitriol 2011-05-27 02:13:46 UTC
I confirm. Tags [color] will lost in format code.
Function broken and makes some OOo documents incompatible.
Comment 2 Don't use this account, use tml@iki.fi 2011-05-27 02:41:23 UTC
For Kohei presumably, but if you feel overloaded, do assign back to the list.
Comment 3 Johnny Rosenberg 2011-07-17 05:27:56 UTC
Are there any work on this bug?
Comment 4 vitriol 2011-07-28 11:29:58 UTC
*** Bug 39571 has been marked as a duplicate of this bug. ***
Comment 5 Markus Mohrhard 2011-07-28 12:32:47 UTC
I talked to Kohei and I have a look into it
Comment 6 vitriol 2011-07-28 14:41:19 UTC
*** Bug 39122 has been marked as a duplicate of this bug. ***
Comment 7 Markus Mohrhard 2011-07-29 08:12:24 UTC
it seems that bubli has written a nice patch for master that fixes it, will push it to 3-4 in some days if no one complains about it
Comment 8 Matt 2011-07-31 15:27:23 UTC
I know little about timescales for version numbers, but it occurs to me that if 3.4.2 is recommended for enterprise deployments without this patch included, it will damage existing spreadsheets which have colour formatting? Should the recommendation for enterprise deployment be delayed to a later version?
Comment 9 Andreas Säger 2011-08-01 10:27:34 UTC
IMHO, the issue is invalid because 
[RED][<10]00,0;[BLUE][>=12]00,0;00,0
is not a valid number format. It assumes comma as decimal separator while using English colour names RED and BLUE. All English locales assume a decimal point.

[RED][<10]00.0;[BLUE][>=12]00.0;00.0 in English context yields
02.3
12.0
03.2
15.0
13.2

[ROT][<10]00,0;[BLAU][>=12]00,0;00,0 in German context yields
02,3
12,0
03,2
15,0
13,2
Comment 10 Matt 2011-08-01 11:53:24 UTC
Created attachment 49796 [details]
ODS file of English example in Comment 9

The issue is colour tags are removed. The English example in Comment 9 works before saving, but when the file is reloaded, the colours are gone.

As 3.4.2 is already recommended now for enterprises, I cannot see any mention of this bug in the release notes. This bug destroys colour formatting in existing spreadsheets, so it seems the release notes should contain a warning to enterprise users considering installing it.
Comment 11 Eike Rathke 2011-08-01 13:06:07 UTC
Sounds pretty much like a duplicate of bug 38956
Comment 12 Eike Rathke 2011-08-01 13:27:48 UTC
(In reply to comment #9)
> IMHO, the issue is invalid because 
> [RED][<10]00,0;[BLUE][>=12]00,0;00,0
> is not a valid number format. It assumes comma as decimal separator while using
> English colour names RED and BLUE. All English locales assume a decimal point.

The parser accepts English color names in all locales, so that was not the problem.
Comment 13 Eike Rathke 2011-08-01 13:28:36 UTC

*** This bug has been marked as a duplicate of bug 38956 ***