Description: The tools bar tips such as save button，should display 保存（⌘S）, but the ⌘ can’t be displayed. And the same error with the other buttons. And the Chinese Characters at status bar can not be displayed. This error happens on macOS with M1 cpu version, and the intel cpu is ok. Steps to Reproduce: 1.install apple silicon version LO 2.install simple Chinese language pack 3.set the interface to simple Chinese 4.watch the status bar and put the mouse over the save button wait for the tips Actual Results: ⌘ Display error Expected Results: Status bar Chinese characters Display correct Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.2.6.2 / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 10; OS: Mac OS X 12.3.1; UI render: default; VCL: osx Locale: zh-CN (zh_Hans.UTF-8); UI: zh-CN Calc: threaded
Created attachment 179423 [details] issue’s screenshot
This problem has been more than six months, not only on MacOS , linux also has the same problem, see bug 148477. Hope the problem will be resolved as soon as possible.
*** This bug has been marked as a duplicate of bug 148477 ***
(In reply to Luboš Luňák from comment #3) > > *** This bug has been marked as a duplicate of bug 148477 *** This is not a duplicate question. 14870 contains 14877, and 14870 reported the tools bar problems also, the '⌘' and '⌥' can’t be displayed in toolsbartip for Chinese UI on macOS. And the commit "do not allow reusing already used SalLayoutGlyphs (tdf#148477)" introduced a new bug, the status bar state can't update now. After type some words, the counts of word is still 0, and the pages number is still 1.
There are two problems in this bugreport. The statusbar is a duplicate of bug #148477, and then the toolbar tooltip, which is an unrelated bug.
For the missing "⌘" this suggests the font used for the UI doesn't have the glyph and the glyph fallback for mac doesn't work. It might be worth finding out what font is used there. I think the font used is picked by vcl/osx/salframe.cxx AquaSalFrame::UpdateSettings and I guess that it is the font of aTooltipFont. If you can debug that to find out what font is used there on your system where it doesn't appear to work vs a system where it does it could help find out what the difference is.
(In reply to Caolán McNamara from comment #6) > For the missing "⌘" this suggests the font used for the UI doesn't have the > glyph and the glyph fallback for mac doesn't work. > > It might be worth finding out what font is used there. I think the font used > is picked by vcl/osx/salframe.cxx AquaSalFrame::UpdateSettings and I guess > that it is the font of aTooltipFont. If you can debug that to find out what > font is used there on your system where it doesn't appear to work vs a > system where it does it could help find out what the difference is. I try to debug but I can't get the aTooltipFont's font name. Then I add two line after line 1267, because the menus with '⌘' displays correctly. aStyleSettings.SetHelpFont(aMenuFont); aStyleSettings.SetToolFont(aMenuFont); But it has no effect.
> I try to debug but I can't get the aTooltipFont's font name. dumping it to stderr with something like fprintf(stderr, "fontname is %s\n", aTooltipFont.GetFamilyName().toUtf8().getStr()); might be good enough to get it > Then I add two > line after line 1267, because the menus with '⌘' displays correctly. > aStyleSettings.SetHelpFont(aMenuFont); > aStyleSettings.SetToolFont(aMenuFont); > But it has no effect. On mac I think the menus are rendered by the OS and not directly by us so things are complicated there.
IIRC, LO is using Liberation as its UI font since commit 06299d6c1620e5b2f2a3588d7c93790278397cbd (it used Arial before). It has never behaved correctly in this regard: it should use the platform UI font (see tdf#91400)
(In reply to Caolán McNamara from comment #8) > > I try to debug but I can't get the aTooltipFont's font name. > > dumping it to stderr with something like > > fprintf(stderr, "fontname is %s\n", > aTooltipFont.GetFamilyName().toUtf8().getStr()); > > might be good enough to get it > > > Then I add two > > line after line 1267, because the menus with '⌘' displays correctly. > > aStyleSettings.SetHelpFont(aMenuFont); > > aStyleSettings.SetToolFont(aMenuFont); > > But it has no effect. > > On mac I think the menus are rendered by the OS and not directly by us so > things are complicated there. I got it according to your code: fontname is .AppleSystemUIFont
(In reply to Caolán McNamara from comment #8) > > I try to debug but I can't get the aTooltipFont's font name. > > dumping it to stderr with something like > > fprintf(stderr, "fontname is %s\n", > aTooltipFont.GetFamilyName().toUtf8().getStr()); > > might be good enough to get it > > > Then I add two > > line after line 1267, because the menus with '⌘' displays correctly. > > aStyleSettings.SetHelpFont(aMenuFont); > > aStyleSettings.SetToolFont(aMenuFont); > > But it has no effect. > > On mac I think the menus are rendered by the OS and not directly by us so > things are complicated there. It displays correct when type '⌘ ⌥' in LO writer and then set font to AppleSystemUIFont.
(In reply to Adolfo Jayme Barrientos from comment #9) > IIRC, LO is using Liberation as its UI font since commit > 06299d6c1620e5b2f2a3588d7c93790278397cbd (it used Arial before). It has > never behaved correctly in this regard: it should use the platform UI font > (see tdf#91400) It displays correct when type '⌘ ⌥' in LO writer and then set font to Liberation. There is not no such phenomenons as tdf#91400 except the '⌘ ⌥' characters in tooltip and tip of the day dialogues yet.
(In reply to Caolán McNamara from comment #8) > > I try to debug but I can't get the aTooltipFont's font name. > > dumping it to stderr with something like > > fprintf(stderr, "fontname is %s\n", > aTooltipFont.GetFamilyName().toUtf8().getStr()); > > might be good enough to get it > > > Then I add two > > line after line 1267, because the menus with '⌘' displays correctly. > > aStyleSettings.SetHelpFont(aMenuFont); > > aStyleSettings.SetToolFont(aMenuFont); > > But it has no effect. > > On mac I think the menus are rendered by the OS and not directly by us so > things are complicated there. I find that the tooltip is returned in File vcl/source/helper/commandinfoprovider.cxx Line 291, then add a print line after line 289 like below fprintf(stderr,"sShortCut is %s\n",sShortCut.toUtf8().getStr()); The print like this: sShortCut is xe2x8cx98T sShortCut is xe2x87xa7xe2x8cx98F11 sShortCut is xe2x87xa7F11 sShortCut is xe2x8cx98] sShortCut is xe2x8cx98[ sShortCut is xe2x8cx98B sShortCut is xe2x8cx98I sShortCut is xe2x8cx98U sShortCut is xe2x8cx98D sShortCut is xe2x8cx98N sShortCut is xe2x87xa7xe2x8cx98N sShortCut is xe2x8cx98O sShortCut is sShortCut is xe2x8cx98S // I guess xe2x8cx98 is for ⌘ sShortCut is xe2x87xa7xe2x8cx98S sShortCut is sShortCut is xe2x87xa7xe2x8cx98M sShortCut is sShortCut is xe2x8cx98P If print without toUtf8() , the print like this: fprintf(stderr,"sShortCut is %s\n",sShortCut.getStr()); sShortCut is x18#S // I guess x18# is for ⌘ sShortCut is xe7!x18#S sShortCut is sShortCut is xe7!x18#M 3 sShortCut is sShortCut is x18#P sShortCut is sShortCut is xe7!x18#O sShortCut is x18#X sShortCut is x18#C sShortCut is x18#V
(In reply to Caolán McNamara from comment #6) > For the missing "⌘" this suggests the font used for the UI doesn't have the > glyph and the glyph fallback for mac doesn't work. > > It might be worth finding out what font is used there. I think the font used > is picked by vcl/osx/salframe.cxx AquaSalFrame::UpdateSettings and I guess > that it is the font of aTooltipFont. If you can debug that to find out what > font is used there on your system where it doesn't appear to work vs a > system where it does it could help find out what the difference is. Hello, is there any progress on this issue？
Created attachment 180037 [details] a debugging patch I don't have any solutions, the problem doesn't exist for me on my mac. What might be of some use is the attached patch which outputs the glyph fallback attempts, the glyphs that are missing and the font that macOS suggests. That at least helps to show what code is involved on macOS. For me when I move the mouse over the save icon and the tooltip appears then the output includes a glyph fallback attempt for 0x2318 (the "place of interest" glyph) and for me the suggested font i get back is "Hiragino Sans". And indeed if I then use insert special character and select that font I can see that it does include that glyph which is rendered ok for me in the tooltip.
Created attachment 180042 [details] debug output
(In reply to Caolán McNamara from comment #15) I added debug output file https://bug-attachments.documentfoundation.org/attachment.cgi?id=180042 , thank you for your patience.
The output is double utf-8 encoded but I can reconstruct that the font chosen is 苹方-简 which I believe is "PingFang SC". Looking at the font, then indeed it does not have 0x2318 though it probably does have the other glyphs in the request so it doesn't cover the full set of requested glyphs only some of them. In our Linux fontconfig version of this we would try again with the missing glyphs so I think we need to teach the macOS version to make that attempt.
my attempt at this is https://gerrit.libreoffice.org/c/core/+/134131
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4b693a0c594fb3b73f4a4c1e03e9916f1a107012 tdf#148470 if macOS glyph fallback provided a partial result flag what failed It will be available in 7.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.
(In reply to Caolán McNamara from comment #19) > my attempt at this is https://gerrit.libreoffice.org/c/core/+/134131 Hi, it works, thank you very much!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/e083f38ab8f2ee864b9e20829bf9fe45c415ddff tdf#148470 if macOS glyph fallback provided a partial result flag what failed It will be available in 7.3.4. 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.
*** Bug 108042 has been marked as a duplicate of this bug. ***
*** Bug 123555 has been marked as a duplicate of this bug. ***
*** Bug 148091 has been marked as a duplicate of this bug. ***