On Wed, 1 Feb 2023 17:18:27 GMT, Phil Race <[email protected]> wrote: >> 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.
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. ------------- PR: https://git.openjdk.org/jdk/pull/4798
