Description: As the attached screenshot. The "Heading" style level number 1-10 were gone. It didn't happen under English(US) interfaces. In English interfaces I could see "Heading 1" to "Heading 10". But in Traditional Chinese Interfaces I could only see different size of "標題" instead of "標題 1" to "標題 9". However the level 10 of "標題 10" exists. It didn't happen in my 7.4.3.2 Writer. Steps to Reproduce: 1. Open Writer 7.5.0.3 under Traditional Chinese (zh_TW) interface 2. 3. Actual Results: The Heading level labels were gone. Should be "標題 1" "標題 2" ... but only "標題" exists. As shown in the screenshot of 7.5.0. Expected Results: As shown in the screenshot of 7.4.3. Reproducible: Always User Profile Reset: Yes Additional Info: Problematic version: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: zh-TW (zh_TW.UTF-8); UI: zh-TW Calc: threaded Correct version: Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: zh-TW (zh_TW.UTF-8); UI: zh-TW Calc: threaded And previous versions are all correct. Resetting user profile didn't help.
Created attachment 185452 [details] Problematic 7.5.0 screenshot, with Heading level label gone 7.5.0.3 screenshot. You can see in the right side panel that only "標題" there, instead of "標題 1", "標題 2", ...
Created attachment 185453 [details] Correct 7.4.3 screenshot You can see the 7.4.3 screenshot. The Heading level label was there.
I can confirm this issue. Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: 50(Build:3) CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: zh-TW (zh_TW.UTF-8); UI: zh-TW 7.5.0-1 Calc: CL threaded
Same issues on Simplified Chinese, Japanese and Korean UI.
Created attachment 185829 [details] Screenshot for testing this issue We did a few tests and found that if we changed the translated strings the result would be different. If the level number is two-digits it will show. (Like Heading 4 translated to "標題 40" and it could show the whole string.) If we add a space after the number it will show. (Heading 5 translated to "標題 5 " add a space after 5, it showed.) We used to think if it was because of the length, but we translated it into extra long string with a one-digit number after it, the number didn't show. (Header 6 translated to "標題標題標題標題 6" the 6 didn't show.) The translation entries we tested is here: translations/source/zh-TW/sw/messages.po #. DSgQC #: sw/inc/strings.hrc:87 msgctxt "STR_POOLCOLL_HEADLINE1" msgid "Heading 1" msgstr "標 題 1" #. 9Qw5C #: sw/inc/strings.hrc:88 msgctxt "STR_POOLCOLL_HEADLINE2" msgid "Heading 2" msgstr "標 2" #. x44Y5 #: sw/inc/strings.hrc:89 msgctxt "STR_POOLCOLL_HEADLINE3" msgid "Heading 3" msgstr "標 題3" #. Q4MBD #: sw/inc/strings.hrc:90 msgctxt "STR_POOLCOLL_HEADLINE4" msgid "Heading 4" msgstr "標題 40" #. aQXm6 #: sw/inc/strings.hrc:91 msgctxt "STR_POOLCOLL_HEADLINE5" msgid "Heading 5" msgstr "標題 5 " #. mSpb6 #: sw/inc/strings.hrc:92 msgctxt "STR_POOLCOLL_HEADLINE6" msgid "Heading 6" msgstr "標題標題標題標題 6"
Not only in Heading, but also in Index -> Contents 1-10 or similar styles with a number after the name. Same in 7.5.1.2 Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: zh-TW (zh_TW.UTF-8); UI: zh-TW Calc: threaded
Reproduced in the following environment: Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 98f35cf85ee66e995610fec92ea5224fbf28dff3 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
Created attachment 185938 [details] formatting toolbar There seems to be a display problem only in the sidebar Style dropdown list displayed correctly in formatting toolbar Tooltips are displayed correctly even in the sidebar.
Problem introduced in 7.5.0.2 earliest.
85f161ac76a07bcd1dd2080e4bda8f11a600262d is the first bad commit commit 85f161ac76a07bcd1dd2080e4bda8f11a600262d Author: Khaled Hosny <khaled@aliftype.com> Date: Fri Dec 30 18:56:41 2022 +0200 tdf#152737: Fix off-by-one errors Regressions from: commit 718af940435ae9d2ac90374e5880ecb38e96252c Author: Khaled Hosny <khaled@aliftype.com> Date: Fri Dec 16 00:10:34 2022 +0200 tdf#152533: Improve script handling in font preview and: commit bfecacb2487ba9470600e6f64056d9b1816ee96b Author: Khaled Hosny <khaled@aliftype.com> Date: Thu Dec 15 22:51:54 2022 +0200 tdf#152460: Improve script handling in style previews Change-Id: I7b12f5accbd65459d724676efb7bec947a7faaa0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144880 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com> (cherry picked from commit 95f0dc2dc74401a097105fcfe745aba3e571d9c4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144898 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> svx/source/dialog/fntctrl.cxx | 4 +++- svx/source/styles/CommonStylePreviewRenderer.cxx | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-)
(In reply to Franklin Weng from comment #10) > 85f161ac76a07bcd1dd2080e4bda8f11a600262d is the first bad commit > commit 85f161ac76a07bcd1dd2080e4bda8f11a600262d > Author: Khaled Hosny <khaled@aliftype.com> > Date: Fri Dec 30 18:56:41 2022 +0200 > > tdf#152737: Fix off-by-one errors Adding Cc: to Khaled Hosny
@Khaled in svx/source/styles/CommonStylePreviewRenderer.cxx line 417 auto aScript = aEditEngine.GetScriptType({ 0, 0, 0, 0 }); for (sal_Int32 i = 1; i <= maScriptText.getLength(); i++) { auto aNextScript = aEditEngine.GetScriptType({ 0, i, 0, i }); if (aNextScript != aScript) maScriptChanges.emplace_back(aScript, i - 1); else if (i == maScriptText.getLength()) maScriptChanges.emplace_back(aScript, i); aScript = aNextScript; } If the style name is "標題 1" then when the last character '1' met (aNextScript != aScript) (in this case changed from LATIN to CJK), it would be left out without pushing into maScriptChanges, i.e. maScriptChanges.emplace_back(aScript, i); would not be executed. That will explain why we add a space after the number ("標題 1 ") could reveal all the style name because maScriptChanges.emplace_back(aScript, i); will be executed in the last run of the loop. I could add another if to make sure to push everything into maScriptChanges if it was the last character, but I'm not sure if it would make the problem in tdf#152737 back.
(In reply to Franklin Weng from comment #12) > @Khaled > > in svx/source/styles/CommonStylePreviewRenderer.cxx line 417 > > auto aScript = aEditEngine.GetScriptType({ 0, 0, 0, 0 }); > for (sal_Int32 i = 1; i <= maScriptText.getLength(); i++) > { > auto aNextScript = aEditEngine.GetScriptType({ 0, i, 0, i }); > if (aNextScript != aScript) > maScriptChanges.emplace_back(aScript, i - 1); > else if (i == maScriptText.getLength()) > maScriptChanges.emplace_back(aScript, i); > aScript = aNextScript; > } > > If the style name is "標題 1" then when the last character '1' met > (aNextScript != aScript) (in this case changed from LATIN to CJK), it would Sorry, should be changed from CJK to LATIN > be left out without pushing into maScriptChanges, i.e. > maScriptChanges.emplace_back(aScript, i); would not be executed. That will > explain why we add a space after the number ("標題 1 ") could reveal all the > style name because maScriptChanges.emplace_back(aScript, i); will be > executed in the last run of the loop. > > I could add another if to make sure to push everything into maScriptChanges > if it was the last character, but I'm not sure if it would make the problem > in tdf#152737 back.
Thanks for debugging this, please check https://gerrit.libreoffice.org/c/core/+/148986 if you can (I don’t have the localized version, but I tested by making styles named using the same strings above).
(In reply to خالد حسني from comment #14) > Thanks for debugging this, please check > https://gerrit.libreoffice.org/c/core/+/148986 if you can (I don’t have the > localized version, but I tested by making styles named using the same > strings above). Yes, it solved the problem.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a8725c24fa4d89ec2efddf6f341d403abf79865a tdf#153704: Make sure the last script segment is also added It will be available in 7.6.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.
(In reply to خالد حسني from comment #14) > Thanks for debugging this, please check > https://gerrit.libreoffice.org/c/core/+/148986 if you can (I don’t have the > localized version, but I tested by making styles named using the same > strings above). This commit should backport to 7.5 I think?
(In reply to Po-Yen Huang from comment #17) > (In reply to خالد حسني from comment #14) > > Thanks for debugging this, please check > > https://gerrit.libreoffice.org/c/core/+/148986 if you can (I don’t have the > > localized version, but I tested by making styles named using the same > > strings above). > > This commit should backport to 7.5 I think? https://gerrit.libreoffice.org/c/core/+/148970 https://gerrit.libreoffice.org/c/core/+/148971 (Need other devs to approve them)
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/eeacbc5a873f00e0bdd9667d4e2a963774ef63ee tdf#153704: Make sure the last script segment is also added It will be available in 7.5.3. 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.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-5-2": https://git.libreoffice.org/core/commit/0337d29475bcf9374e58d37935408a9ba4fce3fe tdf#153704: Make sure the last script segment is also added It will be available in 7.5.2. 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.
I confirmed that this bug has been fixed in the following versions: Thank you for your efforts. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b06f35de68a555b85bceb5fc29d1a5f426f4bb7 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded