RFR: 8269806: Emoji rendering on Linux [v18]

[Phil Race]

On Wed, 1 Feb 2023 17:37:47 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> 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.
>
> Oh if only I remembered the details. Overall, such complex changes were made to support variation selectors. See: we have Segoe UI Emoji for colored emoji and Segoe UI Symbol for monochrome ones, each emoji by default must be rendered either colored or monochrome according to CLDR, so I add Segoe UI Symbol into fallback sequence, but exclude those ranges which shouldn't be rendered monochrome by default (that is, most of the characters). Then to make variation selector work, we ignore these exclusion ranges if monochrome selector is used or something like that. So this is some kind of hack to make variation selectors work without "branching" the fallback sequence and fit into existing architecture. I will look through the code to refresh the details and will let you know more.

Please do provide details .. but I don't think we need to .. or should .. be making variation selectors work where the variations aren't supported by a single physical font.

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

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