RFR: 8278050: Armenian text isn't rendered on macOS if text layout is performed

[Sergey Bylokhov]

On Wed, 15 Dec 2021 08:49:04 GMT, Dmitry Batrak <dbatrak at 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