JDK-8234916 : [macos 10.15] Garbled text running with native-image
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8,openjfx11,openjfx13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x_10.15
  • CPU: x86_64
  • Submitted: 2019-11-27
  • Updated: 2020-05-14
  • Resolved: 2019-12-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8u261Fixed openjfx11.0.8Fixed
Related Reports
Relates :  
JDK-8244621 - [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11
Relates :  
JDK-8236049 - [macos] Wrong font chosen after fix for JDK-8234916
Description
Running on MacOS Catalina, when doing static builds of libjavafx_font.a and linking against this in a JavaFX app compiled with GraalVM native-image, if default fonts are used, the rendered text is garbled, and a warning message is printed:

CoreText note: Client requested name ".SFUI-Regular", it will get TimesNewRomanPSMT rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[UIFont systemFontOfSize:].
CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.

According to Apple's WWDC sessions (see for instance : https://asciiwwdc.com/2013/sessions/223?q=periods) or the comment at https://github.com/Cocoanetics/DTCoreText/issues/1168#issuecomment-526411915, font names that start with a period are not to be directly used.
Comments
Changeset: 4ddf554 Author: Jose Pereda Committer: Phil Race Date: 2019-12-05 20:13:53 +0000 URL: https://git.openjdk.java.net/jfx/commit/4ddf5542 8234916: [macos 10.15] Garbled text running with native-image Reviewed-by: prr
05-12-2019
> This issue started with the latest MacOS SDK (with 10.14.6 it doesn't happen). That makes more sense to me than the other conditions.
27-11-2019
I've attached a picture of a simple HelloFX application (running on Mac OS 10.15.1, with GraalVM 19.3 and native-image), to show what the text looks like. This issue started with the latest MacOS SDK (with 10.14.6 it doesn't happen). I did a test with Xcode (11.2.1). In a simple project, adding: CFStringRef ref = CFSTR(".SFUI-Regular"); CTFontRef fr = CTFontCreateWithName(ref, 0, nil); produces the described warning. Precisely, the PR proposes to use in coretext.c the exact same API as MacFontFinder (CTFontCreateUIFontForLanguage), which is in line with what Apple suggests (CTFontCreateUIFontForLanguage), for the system fonts. Since we only add these two system fonts (regular and bold), we would only need to check for either of them, but I agree with you that "bold" is weak and can change for future system font names or different locale cases.
27-11-2019
I suppose the proposed fix https://git.openjdk.java.net/jfx/pull/55 looks reasonable but I have some questions. Does this actually require the combination of catalina, static linking and graal-native image to reproduce ? I actually don't see what the latter two have to do with it but despite the many problems on catalina I haven't heard of this problem, nor is it clear why it would be catalina specific. Can you explain what "garbled" means ? My guess is that the font is not the one expected so glyph codes don't match - ie the code point -> glyph mapping is for the font that was requested not the one returned. In which case how are you sure that the API to return "a system font" is the one that is expected ? One way to be reasonably sure is that the API you are calling here is what was used in MacFontFinder to get the ".SF" font in the first place. Parsing for "bold" may not be not robust. At least if macOS is returning the postscript name we aren't likely to have the localisation problem of truetype where it could have been Negro or Negrito or whatever exactly is used by the font to mean bold in Spanish. But it'll do for now until we find it is a problem.
27-11-2019