On Wed, 1 Feb 2023 17:37:47 GMT, Nikita Gubarkov <[email protected]> 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
