On Wed, 15 Dec 2021 08:49:04 GMT, Dmitry Batrak <dbat...@openjdk.org> wrote:
>> src/java.desktop/macosx/classes/sun/font/CFontManager.java line 337: >> >>> 335: // These fonts are present in [NSFontManager >>> availableFonts] output though, >>> 336: // and can be accessed in the same way as other system >>> fonts. >>> 337: return fallbackFonts.computeIfAbsent(fontName, name -> new >>> CFont(name, null)); >> >> I would like to clarify why we cannot merge the results of the >> availableFontFamilies and availableFonts? > >> I would like to clarify why we cannot merge the results of the >> availableFontFamilies and availableFonts? > > We can do it, if everyone is OK with increasing the scope of the change, due > to the following factors: > * The number of fonts advertised via `GraphicsEnvironment.getAllFonts` and > `GraphicsEnvironment.getAvailableFontFamilyNames` will increase, so a > potential Java application showing a font chooser combo-box will display more > fonts there, than a native macOS application. Not sure whether that's a good > or a bad thing, but that's a change in behaviour that will occur. > * As the number of loaded fonts will increase, the execution time of > `CFontManager.loadNativeFonts` will also increase, introducing a certain > regression in Java UI application startup time. Ideally, this should be fixed > simultaneously, e.g. by adjusting `sun.font.FontFamily` logic to perform > style resolution lazily (when the particular family is accessed), not at the > time `loadNativeFonts` is executed. > * `[NSFontManager availableFonts]` returns the fonts in alphabetical order, > while `NSFontManager availableMembersOfFontFamily:]` (used currently) uses > font weight to sort the results. The order in which fonts are processed > during `loadNativeFonts` impacts the resulting resolution of fonts into > styles in `FontFamily`. So, to keep the currently used approach, an > additional fonts sorting would need to be introduced - that can be done, e.g. > as part of lazy resolution in `FontFamily` mentioned above. > > Even though it can make sense to implement all of the above (which JetBrains > Runtime already does), I'd rather not do everything in one go. For now, what > I'd like to achieve is to switch to > `CTFontCopyDefaultCascadeListForLanguages`-based font fallback, as mentioned > above. And current change, while having a value of its own, is a necessary > step towards that. > If OpenJDK will ever switch to using `[NSFontManager availableFonts]`, as a > sole source of system fonts or in addition to `[NSFontManager > availableFontFamilies]`, this change can just be reverted. Ok, let's investigate that possibility separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/6633
