| Summary: | text color FORMATING in calc | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | SURCOUF <bunty.surcouf> |
| Component: | Calc | Assignee: | Eike Rathke <erack> |
| Status: | CLOSED DUPLICATE | ||
| Severity: | major | CC: | cno, futuria2004, guraknugen, matt0454-bug, vitriol_vitriol |
| Priority: | medium | Keywords: | regression |
| Version: | 3.4.0 RC1 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | All | ||
| Whiteboard: | numberformat target:3.5 target:3.4.3 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
Sample file to illustrate the bug (color format)
ODS file of English example in Comment 9 |
||
I confirm. Tags [color] will lost in format code. Function broken and makes some OOo documents incompatible. For Kohei presumably, but if you feel overloaded, do assign back to the list. Are there any work on this bug? *** Bug 39571 has been marked as a duplicate of this bug. *** I talked to Kohei and I have a look into it *** Bug 39122 has been marked as a duplicate of this bug. *** 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 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? 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 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. Sounds pretty much like a duplicate of bug 38956 (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. *** This bug has been marked as a duplicate of bug 38956 *** |
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