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:
I can confirm this. LibreOffice on 10.10.3 (at least on my machine) uses Arial instead Helvetica Neue (see: Bug 91607).
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]
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.
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
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
Created attachment 171242 [details] the offending font file Install this font to reproduce #91400
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.
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).