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.
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
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 a955330e052cc12c622982f38c5f5d138484013a # good: [cbe79d197e743d9c38dd1c13c781212e7834bfab] source a20a2d7e0d28658f2d9089da076961a599833a28 git bisect start 'master' 'cbe79d197e743d9c38dd1c13c781212e7834bfab' # good: [7af8c7915fcf485485c67febdb6686159afa9d3d] source e9c9848d30c90bd430193dd1b408db6889400063 git bisect good 7af8c7915fcf485485c67febdb6686159afa9d3d # good: [ca2c11c3802cfcba36d9909d799e9f2c7823cb62] source 1369a16651aba967c157f41793657369c094df5a git bisect good ca2c11c3802cfcba36d9909d799e9f2c7823cb62 # bad: [88222e6043bc46a2aeb5483479854c37057b04e2] source a4066c770fec13af06a65a268c306a1f706f2cf0 git bisect bad 88222e6043bc46a2aeb5483479854c37057b04e2 # good: [10636978996509937bd183368dfa2b98accced0c] source 665c763e8427155d427f4e580c4b6f26625982e7 git bisect good 10636978996509937bd183368dfa2b98accced0c # bad: [89c3665b7a3d060afe709d7ba884f930c0f4cfab] source 1cbf0ee54519bf81d934609352e8a1a641d8a534 git bisect bad 89c3665b7a3d060afe709d7ba884f930c0f4cfab # good: [2cc405b5558ba09aadaa78fb02a60e6fbedd222f] source 135eb77464a7a4682547e28ac5e291abff145f3c git bisect good 2cc405b5558ba09aadaa78fb02a60e6fbedd222f # good: [3b074b0fd5ae88a85044663070657a49e62f8279] source 04b055f111be7044bdd97865a8f0b11215b25191 git bisect good 3b074b0fd5ae88a85044663070657a49e62f8279 # bad: [da3ba6146b655bcf12760f771cfac72f48de32fb] source 218d2ab43ac2f1c238349a9e45d5c228ad1c62c4 git bisect bad da3ba6146b655bcf12760f771cfac72f48de32fb # bad: [278e9981f8e7d1622aa7e074184d9a15d6c87ee5] source 8e71900531f39cb604e0658316c32e6b75c9dd14 git bisect bad 278e9981f8e7d1622aa7e074184d9a15d6c87ee5 # good: [88d2610c1467605a6cf053cba07425418967cd0c] source b693fb5cf154b177dd03184c789a4ef6b2aaa833 git bisect good 88d2610c1467605a6cf053cba07425418967cd0c # bad: [f0c44cd1f5b8e734c144e7de1aa7e28a890845d0] source 963b9aaa68b3e7be765a283d74205add9465833f git bisect bad f0c44cd1f5b8e734c144e7de1aa7e28a890845d0 # good: [754fa4c7a758ac0ecaeab278be6369454e79c581] source 0d58f51d7672c569c93c6e814dbfffa586eebfb7 git bisect good 754fa4c7a758ac0ecaeab278be6369454e79c581 # bad: [593df06733450e6931aa1d0733bba80a11d88b83] source 6f810e3d7dafcd7d0101173a501786226f4d8886 git bisect bad 593df06733450e6931aa1d0733bba80a11d88b83 # first bad commit: [593df06733450e6931aa1d0733bba80a11d88b83] source 6f810e3d7dafcd7d0101173a501786226f4d8886 Adding Luboš Luňák to the cc list. Would you please take a look? Thanks.
*** Bug 128641 has been marked as a duplicate of this bug. ***
*** Bug 125295 has been marked as a duplicate of this bug. ***
Created attachment 156044 [details] Opensuse Tumbleweed 20191119 Screenshot Bug also reproducible with fresh OpenSuse Tumbleweed install. The screenshot explains the problem.
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.
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.
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.
(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.
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?
Proposed pach by Luboš Luňák: https://gerrit.libreoffice.org/c/core/+/86750 Thanks a lot, I am building and testing.
See also (bug reported to LibreOffice Chinese community forum): https://bbs.libreofficechina.org/forum.php?mod=viewthread&tid=2380
(In reply to Luboš Luňák from comment #10) I tested on both master and libreoffice-6-3, your patch works perfect.
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.
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.
(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.
https://gerrit.libreoffice.org/c/core/+/86838
@Luboš Luňák: Thank you for your hard work!
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.
(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.
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.
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.
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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7d48001ccf35417cb20ca7ea8bb772082583c79c tdf#126248: sc: Add UItest It will be available in 7.2.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.