Bug 77896 - FORMATTING: Calc do not recognize "text:span" of cell text in ODS file, thus shows wrong font color
Summary: FORMATTING: Calc do not recognize "text:span" of cell text in ODS file, thus ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: high normal
Assignee: Not Assigned
Whiteboard: BSA odf
Keywords: bibisected, bisected, filter:odf, regression
Depends on:
Reported: 2014-04-24 14:07 UTC by Kevin Suo
Modified: 2016-04-15 12:05 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:

Font color in cell A1 should be white. (14.65 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-04-24 14:07 UTC, Kevin Suo
Font color should be white and size should be 20pt (15.23 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-04-24 14:24 UTC, Kevin Suo

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2014-04-24 14:07:24 UTC
Created attachment 97902 [details]
Font color in cell A1 should be white.

Problem description: 
Calc shows font color in A1. Font color should be "white" rather than "black" (auto).
I first notice this behaviour when I open an xlsx file in which LO shows wrong font color. Then I copy-and-pasted one cell to the attached new ods file.

Steps to reproduce:
1. Open the attached ods file.

Current behavior:
Font color for A1 text is black (auto).

Expected behavior:
Font color fot A1 text should be white.

This can be seen from "cell formating", or by un-zip the ods file. When unzip, it shows the following in /content.xml:

<style:style style:name="T1" style:family="text"><style:text-properties fo:color="#000000"...
<text:span text:style-name="T1">物料描述</text:span>

Operating System: Windows 7
Version: Master
Comment 1 Kevin Suo 2014-04-24 14:15:19 UTC
Chaned version to, as there was no such version in BSA.
Comment 2 Kevin Suo 2014-04-24 14:22:44 UTC
Changing the title, as I discovered the following:

1. I unzip the ods file of the 1st attachment, changed font size from 10pt to 20pt:

<style:style style:name="T1" style:family="text"><style:text-properties fo:color="#000000" fo:font-size="10pt"


<style:style style:name="T1" style:family="text"><style:text-properties fo:color="#000000" fo:font-size="20pt"

2. I zip the folder and rename it to "font size 2.ods", reopen, font size is still 10pt.

So, Calc does not know the "<text:span text:style-name="T1">" attribute.
Comment 3 Kevin Suo 2014-04-24 14:24:12 UTC
Created attachment 97904 [details]
Font color should be white and size should be 20pt
Comment 4 Kevin Suo 2014-05-09 00:43:42 UTC

*** This bug has been marked as a duplicate of bug 77537 ***
Comment 5 Kohei Yoshida 2014-05-09 21:25:31 UTC
This is not a duplicate of bug 77537.
Comment 6 Kohei Yoshida 2014-05-09 21:49:00 UTC
BTW, you seem to be aggressively closing unrelated bugs as duplicates, but please don't do that.  That really won't help us.
Comment 7 Kohei Yoshida 2014-05-09 21:51:19 UTC
This needs to be triaged by a qualified QA person.  Since I can't set the status back to UNCONFIRMED, I set this to NEEDINFO.
Comment 8 Kohei Yoshida 2014-05-09 21:52:44 UTC
Ah, here we go.  Now I can set this UNCONFIRMED.  Weird bugzilla...
Comment 9 Yousuf Philips (jay) (retired) 2014-06-24 09:59:03 UTC
Confirmed in Linux Mint in 4.1.6, 4.2.5, 4.3.0 and master. It works fine in 4.0.6 and 3.3.0.
Comment 10 Joel Madero 2014-07-09 05:31:50 UTC
This bug should be separated into two separate bug reports as I can confirm one as a regression (the font color) but not the font size. I'm bibisecting now and updating title to fit what I'm bibisecting. Please open a new bug report for the font size problem.
Comment 11 Joel Madero 2014-07-09 06:07:56 UTC
 a7e54955e9f49e8b59dfd8c4533785a680b1796c is the first bad commit
commit a7e54955e9f49e8b59dfd8c4533785a680b1796c
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed Oct 16 11:07:50 2013 +0000

    commit 5da10275a7475efdbfd9de14ea58cf8f4c6c1582
    Author:     Stephan Bergmann <sbergman@redhat.com>
    AuthorDate: Fri Mar 1 17:09:45 2013 +0100
    Commit:     Stephan Bergmann <sbergman@redhat.com>
    CommitDate: Fri Mar 1 17:18:29 2013 +0100
        Related rhbz#915743: Abort UCB call from SvtMatchContext_Impl::Stop
        ...as otherwise the SvtMatchContext_Impl thread can continue to run for
        arbitrarily long, and the other thread calling Stop() and join() will block.
        However, especially the WebDAV UCP does not properly support aborting commands,
        see 260afe56fd6b2f34de8290f3cdb7d1df5b88f8a8 " neon commands cannot be aborted",
        so this is not yet enough to actually fix rhbz#915743 "thread deadlock/slow
        join in insert->hyperlink in impress."
        Change-Id: I0da899f824763e1b3d19bb5b38d906feb690b623

:100644 100644 fd22aadcebcf1ca20b6c2fcdb9e135deeb9b5885 8a0f14e1bb71d7ecdf8086c62e9769bb7f2d09b8 M	autogen.log
:100644 100644 5af869ab53b50329a270e7d4e2587f802bf68afb 8519bf956c5e06a85818d380070eedc0ef846790 M	ccache.log
:100644 100644 63cd7351c9d6feb098661a5783d51bb172d8a306 33abac29aad7182260562465482b493d94b78a83 M	commitmsg
:100644 100644 e9ea867065a69fa4f0fbbb5c2abb40baeeabd307 21fc5294b2cb922862b78327b6b8a3cd953f38b5 M	dev-install.log
:100644 100644 4c087a5ff52a8cef08f31417ac650666b1d9d0af c1cc87465560a589137349c81641a62968242386 M	make.log
:040000 040000 ece742cbaf9101d015210ea8da6c00ad7a4457c7 9ff9cbceea1fe6b0ad1b17fe9068b2c8e32a6cbb M	opt

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# good: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect good 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# bad: [8ad82bc1416a07501651e8d96fe268e47d3931d3] source-hash-13821254f88d2c5488fba9fe6393dcf4ae810db4
git bisect bad 8ad82bc1416a07501651e8d96fe268e47d3931d3
# bad: [238338bc4111eb82429ea47384d4012bcd7cdc3e] source-hash-b6ba04639b9922f6717f79ac4be215e09691d7a9
git bisect bad 238338bc4111eb82429ea47384d4012bcd7cdc3e
# bad: [89dc8a802d1625e0efd88ba0fb720b22be87f3f0] source-hash-da03bb1ee6a69d2f4fef4c3ca0adc0ba9588bd19
git bisect bad 89dc8a802d1625e0efd88ba0fb720b22be87f3f0
# bad: [fe956dc63cc7ed1831f0e7e9e7253ea4d8c99549] source-hash-b15f095293c6127ecaef2f0fa3a1683e72392835
git bisect bad fe956dc63cc7ed1831f0e7e9e7253ea4d8c99549
# good: [cd762eb968ba8783f726b67d9d70b0a76f4eb55d] source-hash-c9562064740baed3a9978723c5fe77b44a13a7aa
git bisect good cd762eb968ba8783f726b67d9d70b0a76f4eb55d
# bad: [a7e54955e9f49e8b59dfd8c4533785a680b1796c] source-hash-5da10275a7475efdbfd9de14ea58cf8f4c6c1582
git bisect bad a7e54955e9f49e8b59dfd8c4533785a680b1796c
# good: [5e90d936616ff95724eaa3e3a0a7c7a9747e9b44] source-hash-ba446dd58a4ad324d242afcd5b28d3b4dff5a881
git bisect good 5e90d936616ff95724eaa3e3a0a7c7a9747e9b44
# first bad commit: [a7e54955e9f49e8b59dfd8c4533785a680b1796c] source-hash-5da10275a7475efdbfd9de14ea58cf8f4c6c1582
Comment 12 Kevin Suo 2014-07-09 07:26:15 UTC
(In reply to comment #10)
> This bug should be separated into two separate bug reports as I can confirm
> one as a regression (the font color) but not the font size.

Sorry, it was my mistake, the second part is not a bug. When I was changing the font size in comment 2, not only "fo:font-size", but I should change all these:

  fo:font-size="20pt" style:font-size-asian="20pt" style:font-size-complex="20pt"

When change all of these three font-size, libreoffice shows correctly 20pt font size.
Comment 13 Matthew Francis 2015-01-16 07:54:21 UTC
The font colour, weight, etc. seem to have gone wrong as of the below commit.
(among other issues, the fact that the text is permanently bold suggests that the font-weight-asian attribute isn't being set/reset properly)

commit fa23b694c1979254c9a045bcf51d281c29d80c8d
Author: Kohei Yoshida <kohei.yoshida@gmail.com>
Date:   Fri Feb 8 19:43:22 2013 -0500

    Import formatted spans correctly.
    There are more format types to cover. I'm not done yet.
    Change-Id: I42fab04f65810733e5b25fbbc2c92df7e05c05cf
Comment 14 Robinson Tryon (qubit) 2015-12-14 05:20:00 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
Comment 15 Kevin Suo 2016-02-16 06:43:16 UTC
Still reproduciable with
Version: (x64)
Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc
CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; 
Locale: zh-CN (zh_CN)
Comment 16 Markus Mohrhard 2016-04-15 08:29:37 UTC
There is no bug here. The color is specified as black in the file.

Maybe there was a bug in older versions but it is surely correct right now.
Comment 17 Yousuf Philips (jay) (retired) 2016-04-15 12:05:15 UTC
So i went digging through the xml and this is what i found.

The "ce1" table-cell style is specifying a blue cell background, chinese font name, bold 10pt font size, and white font color. On the other hand, the "T1" text style specifies a black font color and bold 10pt font size.

The <table:table-column> entry has table:default-cell-style-name="ce1" and the <table:table-cell> entry has a child <text:span> entry that has text:style-name="T1".

Opening the ods in Excel 2010 and Calligra Sheets 2.8.5 show the text with white text. Though libreoffice 5.2 does show black text in the cell, if you open the formatting dialog, it shows the text in white. So one of these are wrong and should be fixed.

@regina, @jos: CCing you so can give your opinion on what the correct formatting should be for this according to ODF.