Bug 91400 - LibreOffice doesn’t use system font since OS X 10.10+
Summary: LibreOffice doesn’t use system font since OS X 10.10+
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other macOS (All)
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval, topicUI
Depends on:
Blocks: MacOS-Wishlist Font-Rendering
  Show dependency treegraph
 
Reported: 2015-05-19 21:57 UTC by Adolfo Jayme Barrientos
Modified: 2022-08-23 07:33 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot of LibreOffice calc not using system font (113.01 KB, image/png)
2016-04-05 01:11 UTC, Xavier Valarino
Details
screenshot (124.89 KB, image/png)
2018-01-22 15:59 UTC, Jano
Details
the offending font file (58.06 KB, font/ttf)
2021-04-16 15:47 UTC, dorian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adolfo Jayme Barrientos 2015-05-19 21:57:59 UTC
It should, but only to maintain consistency with the rest of OS X applications and system.

To get the “UI-optimized” version of Helvetica Neue, it should be called with [NSFont systemFontOfSize:] as described here [1]. The font’s name, “Helvetica Neue”, should not be hardcoded anywhere.

[1]: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/index.html#//apple_ref/occ/clm/NSFont/systemFontOfSize:
Comment 1 Armin 2015-06-01 06:12:45 UTC
I can confirm this. LibreOffice on 10.10.3 (at least on my machine) uses Arial instead Helvetica Neue (see: Bug 91607).
Comment 2 Robinson Tryon (qubit) 2015-12-13 11:24:28 UTC Comment hidden (noise)
Comment 3 Xavier Valarino 2016-04-05 01:11:31 UTC
Created attachment 124076 [details]
Screenshot of LibreOffice calc not using system font

I have also been experiencing this issue on OSX 10.11.4

It looks like LibreOffice is using Gill Sans Ultra Bold Regular for the active row and column, as well as the active sheet in the GUI.
Comment 4 خالد حسني 2017-01-13 15:18:42 UTC
The system font in newer versions of OS X is hidden and needs a special parameter to the font listing functions to show it. We don’t do that right now and end up not finding the requested font and use a fallback. We can’t also just pass that flag since it will make the font visible in the fonts drop down and we don’t want to do that, so we need to list the font internally but not show it in the fonts drop down.
Comment 5 QA Administrators 2018-01-16 03:29:23 UTC Comment hidden (noise)
Comment 6 Jano 2018-01-22 15:59:08 UTC
Created attachment 139266 [details]
screenshot

This is still a huge problem for me. For some reason libreoffice is not just using some other font but a font that does not really exist, my UI just consists of rectangles... iMac late 2012, 10.13.2, Libreoffice 5.4.1.2
Comment 7 Kamei 2018-03-28 01:22:12 UTC
Me too.

And HarfBuzz of font layout system seem not to do font fallback.
As a result, some text is garbled like squares when LO doesn't use system font.

I think this is reproduced only Language Pack installed.


Version: 6.0.0.3
Build ID: 64a0f66915f38c6217de274f0aa8e15618924765
CPU threads: 8; OS:Mac OS X 10.12.6; UI render: default; 
Locale: ja-JP (ja_JP.UTF-8); Calc: group
Comment 8 dorian 2021-04-16 15:47:19 UTC
Created attachment 171242 [details]
the offending font file

Install this font to reproduce #91400
Comment 9 dorian 2021-04-16 15:51:28 UTC
This bug still persists on macOS since it was reported (arguably before, if forum posts are accurate), and I can confirm at least through 10.14. Present in multiple LO versions since this issue was first reported, all the way up to 7.1.2.2. The general response in fora etc has been #WORKSFORME.

The reason why this bug is only visible to some people and persists across LO versions and OS installs is that it turns out to be a particular implementation of the actual Gill Sans Ultra Bold font itself. (macOS ships with Gill Sans; the one attached was a different copy I found in ~/Library for some reason; I don't know where it came from.) If you disable it, the problem goes away. Why this is the case is probably worth investigating.
Comment 10 خالد حسني 2022-08-23 07:33:17 UTC
I gave this a try again and I couldn’t find a clean way to handle this.

Here is my attempt:

diff --git a/vcl/quartz/ctfonts.cxx b/vcl/quartz/ctfonts.cxx
index 7985905cc404..55a756c1d179 100644
--- a/vcl/quartz/ctfonts.cxx
+++ b/vcl/quartz/ctfonts.cxx
@@ -541,6 +541,25 @@ bool SystemFontList::Init()
     const CFRange aFullRange = CFRangeMake( 0, nFontCount );
     CFArrayApplyFunction( mpCTFontArray, aFullRange, fontEnumCallBack, this );

+    {
+        CTFontRef pFont = CTFontCreateUIFontForLanguage(kCTFontUIFontSystem, 0, nullptr);
+        CTFontDescriptorRef pDesc = CTFontCopyFontDescriptor(pFont);
+        FontAttributes rAttr = DevFontFromCTFontDescriptor(pDesc, nullptr);
+        rAttr.SetFamilyName(".AppleSystemUIFont");
+        rtl::Reference<CoreTextFontFace> pFontData = new CoreTextFontFace(rAttr, reinterpret_cast<sal_IntPtr>(pDesc));
+        AddFont(pFontData.get());
+        CFRelease(pDesc);
+    }
+    {
+        CTFontRef pFont = CTFontCreateUIFontForLanguage(kCTFontUIFontEmphasizedSystem, 0, nullptr);
+        CTFontDescriptorRef pDesc = CTFontCopyFontDescriptor(pFont);
+        FontAttributes rAttr = DevFontFromCTFontDescriptor(pDesc, nullptr);
+        rAttr.SetFamilyName(".AppleSystemUIFont");
+        rtl::Reference<CoreTextFontFace> pFontData = new CoreTextFontFace(rAttr, reinterpret_cast<sal_IntPtr>(pDesc));
+        AddFont(pFontData.get());
+        CFRelease(pDesc);
+    }
+
     return true;
 }

This allow loading a .AppleSystemUIFont (which is the name returned by [NSFont systemFontOfSize: 0]), but it will be also available in the font menu which we don’t. The spacing is also worse than the existing font (it seems to suffer more from VCL lack of subpixel positioning than the current font).