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

Phil Race prr at openjdk.java.net
Fri Dec 17 19:05:28 UTC 2021


On Thu, 16 Dec 2021 05:35:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> 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.

I have a plan to re-do a lot of this code. Things like lazily loading the fonts would be good since right now we take a big hit especially right after reboot . But we shouldn't be enumerating (to the API) fonts that are not enumerated in FontBook.
A tricky aspect is that we have had a couple of bugs like this where we are doing fall back essentially using the standard way of doing it that doesn't get as many glyphs as what you get from the JRS code.
Getting away from the JRS code is part of the idea but it needs to be done carefully.

I don't mind you looking into it (obviously not today) but equally I don't promise not to obsolete whatever you do with whatever I do ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/6633



More information about the client-libs-dev mailing list