I can only guess why this range was excluded.
My guess is that it was something to do with an attempt at
allowing as many of these glyphs as possible to come from
(for example) a Chinese font in a chinese locale even though we
always put the latin font first ..
The interesting reason why adding a Thai Baht magically makes them
appears is Thai forces TextLayout .. and it (apparently) bypasses the
I suspect this is because layout needs to operate on physical fonts so
gets the list
of physical fonts and operates on these explicitly bypassing
is where this support exists.
You can prove that just by using one of these phonetic chars in
adding Thai or anything else and switching to TextLayout .. lo and
behold .. it appears.
I wonder how long that has been the case ? Perhaps so long as to be
effectively forever ..
That makes a case for getting rid of all these ranges.
The use for the ranges is to control what physical font is used for
glyphs in cases
where some font that may be "earlier" in the list supplies glyphs that
prefer to come from some other font.
That may be useful if the exclusion ranges were able to be applied depending
on your locale, but this alphabetic exclusion is particularly questionable.
So the change is OK, but can't the test be automated .. and headless ?
You just need to do something like ask if the font "canDisplay()" these
However the test is fragile in the sense that it assumes that logical
Windows are capable of supporting them.
On 06/04/2018 11:32 PM, Dipak Kumar wrote:
Please review below fix :
Characters which are not getting displayed actually belong to Phonetic
Extensions (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
These characters are not getting rendered properly because they are in
exclusion range mentioned in the windows.fontconfig.properties file.
In the above fix, font exclusion ranges have been adjusted so that these
characters do not fall within these ranges
Font related Jtreg tests and Mach5 client tests are fine.