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 exclusion range. 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 CompositeFont which
is where this support exists.
You can prove that just by using one of these phonetic chars in Font2DTest without 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 you'd actually
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 code points. However the test is fragile in the sense that it assumes that logical fonts on
Windows are capable of supporting them.


On 06/04/2018 11:32 PM, Dipak Kumar wrote:

Please review below fix :

Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/

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.


Reply via email to