I expect the exclusion range is there for a reason.
I think (guess) that the intent was that where there is a sequence like
this :
sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb
then those code points should come from the chinese font.
Perhaps your adjusted exclusion range should apply only to the
monospaced fonts
which are already putting the locale font first.
Unfortunately it doesn't appear that this is possible with the supported
syntax
https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows
i.e it supports selection only by charactersubsetname, not also by
logicalfontname.
But you should check the code to see if this is in fact the case.
There may need to be a non-ideal decision or a revision to that spec.
and its
supporting code.
And why be so narrow ? It seems you have made an even odder situation
in having just those two code points 'un'-excluded.
The argument that those were the two a customer complained about does not
hold up very well.
I think you should also run this whole change+discussion by i18n-dev ..
-phil.
On 01/14/2016 02:32 AM, dmitry markov wrote:
Hello,
Could you review the fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8073400
webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/
Problem description:
On Windows some characters (in particular, left and right double
quotation marks) have width differing from other characters' widths,
when Monospaced logical font is used.
The default monospaced font for windows platform is Courier New. It
contains the desired characters, (i.e. '\u201c' and '\u201d'). However
the characters are in 'exclusion ranges' for this font due to settings
in windows.fontconfig.properties. So when we try to obtain glyphs for
these characters and calculate their bounds, we fallback to another
font (Lucida) and use its glyphs.
Fix:
Remove the following set of characters u2018 - u201F from the
exclusion ranges.
Thanks,
Dmitry