Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present

Oh sorry , I have reset my profile  and test it after i post this bug.  It still has this problem.

No repro

Version: 5.3.3.2
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 2; OS Version: Mac OS X 10.12.4; UI Render: default; Layout Engine: new; 
Locale: zh-CN (fr_FR.UTF-8); Calc: group

using simplified Chinese lang-pack.

I can replicate this.

The issue is the the cmd sign shows up as an empty square with Chinese simplified. In the default English and Norwegian language pack it shows the ⌘ symbol

Version: 5.4.0.3
Build ID：7556cbc6811c9d992f4064ab9287069087d7f62c
CPU 线程：2; 操作系统：Mac OS X 10.12.6; UI 渲染：默认; 
Locale: en-US (en_US.UTF-8); Calc: group

reproduced. I think this issue is related with bug 106148 and bug 114272 .

Version: 5.4.3.2
Build ID: 92a7159f7e4af62137622921e809f8546db437e5
CPU threads: 8; OS: Mac OS X 10.11.6; UI render: GL; 
Locale: ja-JP (ja.UTF-8); Calc: group

*** Bug 106148 has been marked as a duplicate of this bug. ***

Appearing at 5.3 this font fallback issue affecting the UI on OSX. Installing the localized language packs seems to be involved--makes sense as that would bring in a new set of tooltips to be parsed.

@Jay, Khaled -- is this really only going to be CJK? Would expect it to affect fallback for CTL scripts as well on OSX.

(In reply to V Stuart Foote from comment #8)
> @Jay, Khaled -- is this really only going to be CJK? Would expect it to
> affect fallback for CTL scripts as well on OSX.

Possibly, we didn’t do font fallback on OSX before the switch to HarfBuzz as the system was doing everything, so there is a bit of new not very tested code here.

(In reply to Khaled Hosny from comment #9)
> (In reply to V Stuart Foote from comment #8)
> > @Jay, Khaled -- is this really only going to be CJK? Would expect it to
> > affect fallback for CTL scripts as well on OSX.
> 
> Possibly, we didn’t do font fallback on OSX before the switch to HarfBuzz as
> the system was doing everything, so there is a bit of new not very tested
> code here.
So is it possible to make use of HarfBuzz font fallback APIs to do?

(In reply to Volga from comment #10)
> (In reply to Khaled Hosny from comment #9)
> > (In reply to V Stuart Foote from comment #8)
> > > @Jay, Khaled -- is this really only going to be CJK? Would expect it to
> > > affect fallback for CTL scripts as well on OSX.
> > 
> > Possibly, we didn’t do font fallback on OSX before the switch to HarfBuzz as
> > the system was doing everything, so there is a bit of new not very tested
> > code here.
> So is it possible to make use of HarfBuzz font fallback APIs to do?

HarfBuzz does not have font fallback APIs, and we do font fallback after shaping (to a degree) and that is all HarfBuzz has to offer font-fallback wise.

(In reply to Khaled Hosny from comment #11)
> (In reply to Volga from comment #10)
> > (In reply to Khaled Hosny from comment #9)
> > > (In reply to V Stuart Foote from comment #8)
> > > > @Jay, Khaled -- is this really only going to be CJK? Would expect it to
> > > > affect fallback for CTL scripts as well on OSX.
> > > 
> > > Possibly, we didn’t do font fallback on OSX before the switch to HarfBuzz as
> > > the system was doing everything, so there is a bit of new not very tested
> > > code here.
> > So is it possible to make use of HarfBuzz font fallback APIs to do?
> 
> HarfBuzz does not have font fallback APIs, and we do font fallback after
> shaping (to a degree) and that is all HarfBuzz has to offer font-fallback
> wise.
So how does LibreOffice do font fallback well on Windows and Linux?

*** Bug 117932 has been marked as a duplicate of this bug. ***

It seems to occur not only on mac osx, but also on windows 10.
there's a report with korean language pack on mac osx sierra and windows 10.

https://ask.libreoffice.org/ko/question/166572/ribeure-opiseueseo-ilbu-ui-tultib-pabeob-cangyi-hangeul-ponteuga-ggaejibnida/

And I also was able to reproduce it on my high sierra with libreoffice 6.0.x
but no problems on ubuntu 18.04, libreoffice 6.1.0.3

*** Bug 121387 has been marked as a duplicate of this bug. ***

*** Bug 123548 has been marked as a duplicate of this bug. ***

applying version change by Kamei as of https://lists.freedesktop.org/archives/libreoffice-bugs/2019-March/176584.html (outage)

I cannot reproduce with my Windows 10, and I don't have a macOS.

For who can build a macOS applications who wants to offer assistance,
I leave some questions.

Q1. Does the program reach line 84 when this issue occurs ?
Q2. Let me know what the value of pStr is.
Q3. Let me know What the value of rPattern.maSearchName is?

https://opengrok.libreoffice.org/xref/core/vcl/quartz/salgdi.cxx?r=ca2aa307#84

---
helpful documents if you have never built LibreOffice:

https://wiki.documentfoundation.org/Development/BuildingOnMac
-----------
on Windows, when I build LibreOffice,
I often pass enable-sal-log and enable-dbgutil(may be unnecessary?) so that I can use SAL_INFO when <sal/log.hxx> is included.

https://api.libreoffice.org/docs/cpp/ref/a00004.html

at least I can use the macro in the following way, for example. at least we can pass OUString as the second parameter.

SAL_INFO("vcl", OUString::number(3));

be careful not to write

SAL_INFO("vcl", 1 + 2);

but please write this way.

SAL_INFO("vcl", (1 + 2));

I don't know if SAL_INFO's second paramter accepts CFStringRef, but if it doesn't I believe including <quartz/utils.h> 
will let you use OUString GetOUString(CFStringRef)

Created attachment 172325 [details]
fallback font log in vcl/quartz/salgdi.cxx

I put SAL_INFO in line 90 in vcl/quartz/salgdi.cxx and logged it. (Attached file)

> SAL_INFO( "vcl.quartz", "CoreTextGlyphFallbackSubstititution::FindFontSubstitute() rPattern.maSearchName=" << rPattern.maSearchName );

Where the text was displayed correctly, it was in Hiragino Kaku gothic.

> info:vcl.quartz:19628:58067:vcl/quartz/salgdi.cxx:90: CoreTextGlyphFallbackSubstititution::FindFontSubstitute() rPattern.maSearchName=ヒラギノ角ゴシック

Where the text was garbled, it was displayed in Lucida Grande.

> info:vcl.quartz:19628:58067:vcl/quartz/salgdi.cxx:90: CoreTextGlyphFallbackSubstititution::FindFontSubstitute() rPattern.maSearchName=Lucida Grande

The font is incorrectly specified and the text is garbled.

The issue has been fixed! See commit 4b693a0c594fb3b73f4a4c1e03e9916f1a107012

*** This bug has been marked as a duplicate of bug 148470 ***