https://bugs.documentfoundation.org/show_bug.cgi?id=173342
--- Comment #2 from gio.bertelli <[email protected]> --- This is the same root cause as tdf#91400. The system UI font on macOS (San Francisco, family name `.AppleSystemUIFont`) is a *private* system font. CoreText does not return it from `CTFontCollectionCreateFromAvailableFonts()`, because its family name begins with a period — the convention macOS uses to mark a font as private and not directly selectable by applications. VCL only knows about the fonts CoreText enumerates, so the `UI_SANS` entry in `officecfg` can never resolve to it and falls back to the first entry that does exist, which is the bundled Liberation Sans. That is also why the fallback sometimes picked an arbitrary installed font (Gill Sans Ultra Bold in tdf#91400, URW Franklin Gothic in this report): when the requested family is not found, attribute-based font substitution kicks in and can match an unrelated font. I would suggest making the system UI font available to VCL internally, while keeping it hidden from the font selection lists (this is what was proposed in tdf#91400 comment 10, but with an explicit hiding mechanism). Concretely: 1. `vcl/quartz/SystemFontList.cxx`: after the normal enumeration, explicitly add the regular and emphasized (bold) variants obtained from `CTFontCreateUIFontForLanguage(kCTFontUIFontSystem)` / `kCTFontUIFontEmphasizedSystem`, and register them under the stable family name `.AppleSystemUIFont`. Passing a null `bFontEnabled` keeps `checkFontTypeSupported()` from rejecting the private font. 2. `officecfg/registry/data/org/openoffice/VCL.xcu`: put `.AppleSystemUIFont` at the head of the `en` `UI_SANS` list. The family only exists on macOS, so other platforms simply skip the token. The application UI font is resolved from the `en` node (see `ImplStyleData::SetStandardStyles()`), so this is the only list that needs touching. 3. `svtools/source/control/ctrltool.cxx` (font name boxes) and `svx/source/dialog/cuicharmap.cxx` (character map): on macOS skip families whose name starts with a period, so the private system font — and any other private system font — is not offered in font selection lists, matching what applications that use Apple APIs do. This complements your commit 3d16a6e9d32f ("Skip private system fonts found by fontconfig on macOS"). With this, VCL finds and uses the real system UI font for widgets and dialogs, and no longer performs font substitution for the UI. Two caveats: the spacing remark in tdf#91400 comment 10 was from 2022, and the CoreText backend now enables subpixel positioning (`CGContextSetShouldSubpixelPositionFonts` etc.), so metrics should be considerably better than back then — but this still needs a visual before/after check on real hardware. I have not been able to do a full build of VCL on this machine, so the patch is untested; I am happy to iterate if there is a preferred way to hide the private font (e.g. a flag on `PhysicalFontFace` instead of the name-prefix check). If you think the approach is sound and would like a real patch, I can also try to submit this to Gerrit — just let me know whether that is welcome. -- You are receiving this mail because: You are the assignee for the bug.
