I think can support this internally by including a unicode,selector pair as (selector<<21)|unicode value in the charset, but provide new API to the charset for querying. Or maybe expose that convention all the way to the API. Here's some code to that extent: unsigned int var_num = 0; if (variation_selector - 0xFE00u < 16) var_num = variation_selector - 0xFE00 + 1; else if (variation_selector - 0xE0100u < (256 - 16)) var_num = variation_selector - 0xE0100 + 17; unicode = (var_num << 21) | unicode; Note that currently FcCharSetPutLeaf has: ucs4 >>= 8; if (ucs4 >= 0x10000) return FcFalse; so the top byte of the ucs4 has been unused. Unfortunately the top byte is not enough as there are 256 values to fit, not 255 :(.
FWIW, I wrote to the Unicode Technical Committee, asking them to agree not to use U+E01EF VARIATION SELECTOR-256. Will post here when I hear back.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/97.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.