Description: This phenomenon can be reproduced in the Chinese(zh-CN,simplified) version fomula editor. English version does not have this problem。 Problem: Math component - View - Elements, then select Attributes in the elements window, the colors at the bottom, the text always overlap. Steps to Reproduce: 1.Set the language to Chinese(simplified) in menu Tools - Options - Language Settings - User interface. 2.Open Math, select the option of View - Elements. 3.Select Attributes from the drop-down list at the top of the Elements window, and, scroll to the bottom of the Elements window. There you can see it. (Chinese simplied version only) Actual Results: Text overlap. Expected Results: No text overlap. Reproducible: Always User Profile Reset: Yes Additional Info:
Created attachment 150995 [details] Dysfunctional text rendering in the UI of LibreOffice Math (Simplified Chinese) Here is the screenshot of this issue. It can be seen that the text rendering in the UI is dysfunctional.
There is way too much spacing between those Chinese texts, and meanwhile, there are something unidentifiable to me overlapping. (Are they English texts, I guess?)
*too much spacing between those Chinese characters
For OP, which Linux os and Desktop Environment were you using? Also, could you test on a Windows build--NEEDINFO to you. Otherwise, the color strings [1] naming each color used to build the array of the Elements panel [2] are Pootle localized for zh-CN [3]; the zh-TW localization does not yet provide a translation of the strings. Image shows a font shaping issue with the mixed BMP (CJK) and latin unicode glyphs, e.g. "酸橙色 (lime)", assigned for the color names of the control. The CJK glyphs are spaced too wide, and then the western glyphs are being over written. While the localization could be changed (eliminating the mixed string), seems like there is a Harfbuzz shaping issue in composing strings for the element frame. @Khaled, jmux? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/starmath/inc/strings.hrc?r=c89a4996#288 [2] https://opengrok.libreoffice.org/xref/core/starmath/source/ElementsDockingWindow.cxx?r=4a6dc219#571 [3] https://opengrok.libreoffice.org/xref/translations/source/zh-CN/starmath/messages.po?r=dee42a39#1669
@V Stuart Foote The screenshot uploaded by me is of LO 6.2.1 + Windows 10 x64.
(In reply to Petro Diaz from comment #5) > @V Stuart Foote > The screenshot uploaded by me is of LO 6.2.1 + Windows 10 x64. Sorry, I didn't notice that. So it affects all os/DE--but means easier to track (not locale dependent) and more consistent with font handling comments of see also bug 118884
If this is a regression, then it needs to be bisected. Font fallback runs at a different level and is not related to the layout engine used.
Created attachment 151015 [details] strings of CJK and western labeling color names at 5.1.6.2 (In reply to Khaled Hosny (inactive) from comment #7) > If this is a regression, then it needs to be bisected. Font fallback runs at > a different level and is not related to the layout engine used. Able to confirm the issue on /a "server" installs of Windows builds. Went looking to see when it showed up, and it was present before any of the work on HarfBuzz and CommonSalLayout--so good call on that, not a regression. The StarMath "Elements" docking window was brought in at 4.1, colors for formula elements were added to the Attributes array at 4.4. Looks like it was probably picked up for Pootle translation for the 5.1 build (there in 5.1.6.3 for sure) as testing a 5.0.6.3 build had no translations.
Linux Version: This phenomenon can be reproduced in Debian Stretch 9.8/Gnome.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/13e716b2cfce4d093d74b3a552251deb9f3b6832%5E%21 tdf#124944 don't directly adjust fallback layouts It will be available in 6.3.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.
I had download the daily builds (version:libreoffice-6-2~2019-05-03_21.31.32_LibreOfficeDev_6.2.4.0.0_Linux_x86-64_deb.tar.gz) and the language pack (version:libreoffice-6-2~2019-05-03_21.31.32_LibreOfficeDev_6.2.4.0.0_Linux_x86-64_deb_langpack_zh-CN.tar.gz ) The problem is still. I guess it should be that the patch has not been put into the daily build.
(In reply to yichuang驿窗 from comment #11) > I had download the daily builds > (version:libreoffice-6-2~2019-05-03_21.31.32_LibreOfficeDev_6.2.4.0. > 0_Linux_x86-64_deb.tar.gz) > > and the language pack > (version:libreoffice-6-2~2019-05-03_21.31.32_LibreOfficeDev_6.2.4.0. > 0_Linux_x86-64_deb_langpack_zh-CN.tar.gz ) > > The problem is still. I guess it should be that the patch has not been put > into the daily build. This is just fixed in 6.3 / master builds (see whiteboard). I know the commit is just a single removed line, but that completely changes the layouting code for fallback fonts, which you have in this case with mixed asian + western glyphs in a single string. I'm rather reluctant to port this to 6.2, as it's just a minor nuisance with regard to usability and 6.2 is already out since a few months and I don't know what else might break. And FWIW 6.3 has some more changes to Asian layouting, which I think are correct, but can't really verify. So if you still want to verify the fix, please test a master build.
I have tested this version: master~2019-05-04_04.44.35_LibreOfficeDev_6.3.0.0.alpha0_Linux_x86-64_deb.tar.gz, and, the result is good, the problem has been fixed! Thanks.