Download it now!
Bug 126248 - Calc 6.3: Asian Font is Wrongly Applied to Western Text
Summary: Calc 6.3: Asian Font is Wrongly Applied to Western Text
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Luboš Luňák
URL:
Whiteboard: target:6.5.0 target:6.4.0 target:6.3.5
Keywords: bibisected, bisected, regression
: 125295 128641 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-07-05 16:15 UTC by Ming Hua
Modified: 2020-01-17 15:31 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing the problem (6.22 KB, image/png)
2019-09-17 09:06 UTC, Ming Hua
Details
Opensuse Tumbleweed 20191119 Screenshot (259.67 KB, image/png)
2019-11-22 12:20 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ming Hua 2019-07-05 16:15:22 UTC
Description:
On my Chinese version of Windows, when the style assigns western and Asian texts with different fonts, the newly inputed English text doesn't use the western text font, but use the Asian text font instead.  This is only a problem of displaying the text, as saving the file, closing it, and opening it again shows the English text with the correctly assigned font.

Steps to Reproduce:
1. Create a new spreadsheet file.  Change the "Default" style, set the western text font to something distinctly different from the system's default Asian font, say "Segoe UI".  Keep the Asian text font as the default "Microsoft YaHei" (微软雅黑).

2. Type some English text in a cell, notice it shows as Segoe UI font when typing, but after enter key to confirm, the text in the cell is shown as MS YaHei font.

3. Save the file.  Close it and open it again, now the English text is correcly shown as Segoe UI font.

Actual Results:
The English text is displayed in the Asian text font, instead of the western text font specified in the style.

Expected Results:
English text is displayed in the western text font.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.3.0.0.beta2 (x64)
Build ID: 6c6edded7133daf2d8d0b2ea7ae25b8109c5c064
CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: zh-CN (zh_CN); UI-Language: en-US
Calc: threaded

It shouldn't be related to user profile, as it's reproducible in safe mode.

This is also a regression from 6.1.6 and 6.2.4.
Comment 1 Ming Hua 2019-09-17 09:06:47 UTC
Created attachment 154215 [details]
Screenshot showing the problem

Still reproducible with 6.3.1 on Windows 10.  Attached is a screenshot, using Segoe UI as English font and NSimsun (新宋体 in Chinese) as Asian font to further showcase the problem.

Some more trigger condition - it seems to only happen if "Tools -> Automatic Spell Checking" is turned on, and to only happen for correctly spelled English words.

Version: 6.3.1.2 (x64)
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: zh-CN (zh_CN); UI-Language: en-US
Calc: threaded
Comment 2 Kevin Suo 2019-10-27 10:42:30 UTC
I reproduce this on Fedora and Ubuntu with the latest master build.

Short steps to reproduce:

1. Make sure you have enabled "Asian" in Options - Language Settings - Language - Default Language for Document.

2. Make sure the default style has used different fonts for Western Text and Asian Text (Format - Cells...). For me, I use the default fonts, which is Liberation Sans for Western Text and Noto Sans CJK SC for Asian Text.

3. Type in "Test" in cell A1, hit Enter. Put your cursor back to A1.
--> In the font toolbar you will see that Asian Text font is applied to A1.

The expected behaviour is to apply Western Text font to A1.

This bug makes Calc unusable under Asian Text environment.

Bibisecting has identified the following range:
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=0d58f51d7672c569c93c6e814dbfffa586eebfb7..6f810e3d7dafcd7d0101173a501786226f4d8886

$ git bisect log
# bad: [d69ce43ec33c664199e197a216c76232d3d182ad] source sha:a955330e052cc12c622982f38c5f5d138484013a
# good: [cbe79d197e743d9c38dd1c13c781212e7834bfab] source sha:a20a2d7e0d28658f2d9089da076961a599833a28
git bisect start 'master' 'cbe79d197e743d9c38dd1c13c781212e7834bfab'
# good: [7af8c7915fcf485485c67febdb6686159afa9d3d] source sha:e9c9848d30c90bd430193dd1b408db6889400063
git bisect good 7af8c7915fcf485485c67febdb6686159afa9d3d
# good: [ca2c11c3802cfcba36d9909d799e9f2c7823cb62] source sha:1369a16651aba967c157f41793657369c094df5a
git bisect good ca2c11c3802cfcba36d9909d799e9f2c7823cb62
# bad: [88222e6043bc46a2aeb5483479854c37057b04e2] source sha:a4066c770fec13af06a65a268c306a1f706f2cf0
git bisect bad 88222e6043bc46a2aeb5483479854c37057b04e2
# good: [10636978996509937bd183368dfa2b98accced0c] source sha:665c763e8427155d427f4e580c4b6f26625982e7
git bisect good 10636978996509937bd183368dfa2b98accced0c
# bad: [89c3665b7a3d060afe709d7ba884f930c0f4cfab] source sha:1cbf0ee54519bf81d934609352e8a1a641d8a534
git bisect bad 89c3665b7a3d060afe709d7ba884f930c0f4cfab
# good: [2cc405b5558ba09aadaa78fb02a60e6fbedd222f] source sha:135eb77464a7a4682547e28ac5e291abff145f3c
git bisect good 2cc405b5558ba09aadaa78fb02a60e6fbedd222f
# good: [3b074b0fd5ae88a85044663070657a49e62f8279] source sha:04b055f111be7044bdd97865a8f0b11215b25191
git bisect good 3b074b0fd5ae88a85044663070657a49e62f8279
# bad: [da3ba6146b655bcf12760f771cfac72f48de32fb] source sha:218d2ab43ac2f1c238349a9e45d5c228ad1c62c4
git bisect bad da3ba6146b655bcf12760f771cfac72f48de32fb
# bad: [278e9981f8e7d1622aa7e074184d9a15d6c87ee5] source sha:8e71900531f39cb604e0658316c32e6b75c9dd14
git bisect bad 278e9981f8e7d1622aa7e074184d9a15d6c87ee5
# good: [88d2610c1467605a6cf053cba07425418967cd0c] source sha:b693fb5cf154b177dd03184c789a4ef6b2aaa833
git bisect good 88d2610c1467605a6cf053cba07425418967cd0c
# bad: [f0c44cd1f5b8e734c144e7de1aa7e28a890845d0] source sha:963b9aaa68b3e7be765a283d74205add9465833f
git bisect bad f0c44cd1f5b8e734c144e7de1aa7e28a890845d0
# good: [754fa4c7a758ac0ecaeab278be6369454e79c581] source sha:0d58f51d7672c569c93c6e814dbfffa586eebfb7
git bisect good 754fa4c7a758ac0ecaeab278be6369454e79c581
# bad: [593df06733450e6931aa1d0733bba80a11d88b83] source sha:6f810e3d7dafcd7d0101173a501786226f4d8886
git bisect bad 593df06733450e6931aa1d0733bba80a11d88b83
# first bad commit: [593df06733450e6931aa1d0733bba80a11d88b83] source sha:6f810e3d7dafcd7d0101173a501786226f4d8886

Adding Luboš Luňák to the cc list. Would you please take a look? Thanks.
Comment 3 Ming Hua 2019-11-07 16:43:42 UTC
*** Bug 128641 has been marked as a duplicate of this bug. ***
Comment 4 Kevin Suo 2019-11-22 12:17:21 UTC
*** Bug 125295 has been marked as a duplicate of this bug. ***
Comment 5 Kevin Suo 2019-11-22 12:20:58 UTC
Created attachment 156044 [details]
Opensuse Tumbleweed 20191119 Screenshot

Bug also reproducible with fresh OpenSuse Tumbleweed install. The screenshot explains the problem.
Comment 6 Kevin Suo 2019-12-07 02:44:12 UTC
This is a disaster. We are not able to work in Calc with Simplified Chinese locale with the 6.3+ version. Could someone investigate? I can help to debug on master with a debug build if needed.
Comment 7 Kevin Suo 2019-12-29 04:41:58 UTC
I compiled the source code with debug and dbgutil enabled.

Good in:
    0d58f51d7672c569c93c6e814dbfffa586eebfb7 2019-05-16 12:33:16 +0200

Build error in the following commit ((Ubuntu 18.04 LTS), ignored:
    ace16e500c92797bb47ad580cf535de0702137bd 2019-05-16 12:34:42 +0200 

Bad in:
    6f810e3d7dafcd7d0101173a501786226f4d8886 2019-05-16 12:34:51 +0200

The output message in terminal for both the good and bad commits are identical, so it may not be useful.
Comment 8 Luboš Luňák 2020-01-13 13:11:21 UTC
The only place where I can see those two commits to possibly affect this is https://cgit.freedesktop.org/libreoffice/core/diff/sc/source/core/data/documen6.cxx?id=6f810e3d7dafcd7d0101173a501786226f4d8886 . If you want to debug that, I suggest trying to revert the changes in either of those two functions and seeing what happens, and then possibly debugging why the functions called from there behave differently even though they shouldn't.
Comment 9 Kevin Suo 2020-01-14 02:41:52 UTC
(In reply to Luboš Luňák from comment #8)

It is the following function which caused this bug:
SvtScriptType ScDocument::GetCellScriptType
Specifically, it is related to OUString aStr.

The bug is gone if I use back the following code:
OUString aStr = ScCellFormat::GetString(*this, rPos, nNumberFormat, &pColor, *mxPoolHelper->GetFormTable());

and remove those lines added by that commit.

I see the main difference between these two version is,
previously the aStr is assigned a value:
OUString aStr = ScCellFormat::GetString

but in the new one, aStr is never assigned a value, but rather it is directly used in cCellFormat::GetString call, while the nRet still uses aStr as an arg.

Is this correct? I am not familiar with c++ anyway. I added a std::cout and then print the value of aStr - With the bug code, aStr is always blank (none?) when I type in text in the cell. With the old code, aStr is correctly showing the text I type in.
Comment 10 Luboš Luňák 2020-01-14 11:32:42 UTC
You're right, the one call ignores the return value, my mistake. Does doing this change https://pastebin.com/4ShVezNR also fix the problem for you?
Comment 11 Kevin Suo 2020-01-14 15:45:07 UTC
Proposed pach by Luboš Luňák:
https://gerrit.libreoffice.org/c/core/+/86750

Thanks a lot, I am building and testing.
Comment 12 Kevin Suo 2020-01-14 15:48:24 UTC
See also (bug reported to LibreOffice Chinese community forum):
https://bbs.libreofficechina.org/forum.php?mod=viewthread&tid=2380
Comment 13 Kevin Suo 2020-01-14 23:31:32 UTC
(In reply to Luboš Luňák from comment #10)

I tested on both master and libreoffice-6-3, your patch works perfect.
Comment 14 Commit Notification 2020-01-15 10:34:27 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5a211ba9f5f465c8c898ebce4cc37fa30581acac

do not ignore return value of a (confusing) function (tdf#126248)

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Luboš Luňák 2020-01-15 10:36:50 UTC
Ok, thank you. I'll also cherry-pick this for 6.4 at https://gerrit.libreoffice.org/c/core/+/86835 . I can't judge the seriousness of this for 6.3, so I'll leave that up to you or QA people.
Comment 16 Kevin Suo 2020-01-15 10:45:59 UTC
(In reply to Luboš Luňák from comment #15)

Please do cherry-pick this to libreoffice-6-3 also. It is this bug which stopped many of us from using LibreOffice 6.3.

This revision is safe enough, and I've already tested using Calc with this patch, for one and a half days without any side effects. Version 6.3 is still on its 6.3.5 stage, there are still 6.3.6 and 6.3.7 ahead.
Comment 17 Luboš Luňák 2020-01-15 11:03:15 UTC
https://gerrit.libreoffice.org/c/core/+/86838
Comment 18 Kevin Suo 2020-01-15 11:24:02 UTC
@Luboš Luňák: Thank you for your hard work!
Comment 19 Ming Hua 2020-01-15 12:28:39 UTC
Luboš Luňák, thanks for the fix!

Also thank you Kunlong for the tireless investigation work, I really appreciate it.

I agree with Kunlong that this should be backported to 6.3, to heavy Calc users in CJK world this bug is a showstopper.
Comment 20 Kevin Suo 2020-01-15 12:57:28 UTC
(In reply to Ming Hua from comment #19)
Luboš Luňák has already prepared cherry-pick patches on gerrit for both 6.4 and 6.3. They are under code review and will be merged very soon.
Comment 21 Commit Notification 2020-01-16 00:47:18 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/deeb6f645d4eeb686afd5646b9d64480e54dabea

do not ignore return value of a (confusing) function (tdf#126248)

It will be available in 6.4.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Commit Notification 2020-01-16 00:48:52 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/4c3bde3b4bddb6bcfe0ae5b269d3b0f50c23236f

do not ignore return value of a (confusing) function (tdf#126248)

It will be available in 6.3.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 23 Commit Notification 2020-01-17 15:30:41 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-6-4-0":

https://git.libreoffice.org/core/commit/a18fd80e81fdab190d41f53c9cfe53f500c6034a

do not ignore return value of a (confusing) function (tdf#126248)

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.