RFR: 8269806: Emoji rendering on Linux [v18]

[Phil Race]

On Wed, 1 Feb 2023 16:10:51 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Dynamic loading of ftcolor.h symbols on Linux.
>  - Replace unicodeToUnits with Character.toChars in CCharToGlyphMapper
>  - Add braces to ifs.
>  - Make tests headful.
>  - Merge branch 'master' into JDK-8269806
>  - Remove ftcolor.c
>  - Skip tests if required font is absent
>  - Fix pointer to jlong conversion on x86
>  - Merge branch 'master' into JDK-8269806
>  - Merge branch 'master' into JDK-8269806
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/60c535de...57c0b57d

src/java.desktop/windows/data/fontconfig/fontconfig.properties line 249:

> 247: sequence.monospaced.x-windows-949=korean,alphabetic,dingbats,symbol
> 248: sequence.dialog.x-windows-949=alphabetic,korean,dingbats,symbol
> 249: sequence.dialoginput.x-windows-949=alphabetic,korean,dingbats,symbol

I'd like to understand the reasoning behind the changes I see in the windows fontconfig.properties

The effect of what I see is (if I have it right)
1) Make Segoe UI Symbol a "core" part of every font - with the consequence that you potentially change
the metrics of every logical font- something which is often a compatibility issue
2) You then go ahead and exclude virtually every code point in that font, which kind of
defeats the point of having it at all .. and is  I guess you want it to take precedence for
all those code points over the emoji font .. but not some others ??
It seems like additions in later versions of either font would mean there'd be updates
needed here.
And FWIW if the Emoji font isn't available they will now get missing glyphs

also you are making a policy decision here that apps which currently get ordinary
symbol chars will now get emojis for those codepoints, whether they want them or not.

I think need to look at what code points these fonts support ..  IMO the Emoji font
as a fall back should be for unicode specified Emoji code points which I expect
not to see in the normal symbol font ..

In other words, what I would *expect* is that you just added the emoji as another
fallback (somewhere after symbols) and changed NOTHING else in this file.

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

PR: https://git.openjdk.org/jdk/pull/4798