[OpenJDK 2D-Dev] RFR: 8170950: Text is displayed in bold when fonts are installed into symlinked folder

[Philip Race]

The point being the fonts end up being registered by the canonical path
and that then is the basis for comparison used when we come back here ?
I think this will be OK. May I assume you tested this thoroughly.
I don't mean a new regression test - which is not easy.
I mean to make sure it didn't break anything else.
This means existing reg. tests, some other verification there is
no change in anything reported for other families not directly affected 
by this bug.

+1 if you can confirm that ..

-phil.

On 1/30/17, 4:36 AM, dmitry markov wrote:
> Hello Dmitry,
>
> The fix looks good to me, but I am not a reviewer.
>
> I will sponsor the integration of the fix once the review is completed.
>
> Thanks,
> Dmitry
> On 30/01/2017 11:53, Dmitry Batrak wrote:
>> Hello,
>>
>> I'd like to propose a fix for JDK-8170950.
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8170950
>>   webrev: http://cr.openjdk.java.net/~dmarkov/8170950/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Edmarkov/8170950/webrev.00/>
>>
>> I have only a Contributor status, so I'll require a sponsor.
>>
>> The issue is a special case of JDK-8012351 (fixed previously) - when 
>> font files
>> are located in symlinked folders. Physical components of logical 
>> fonts are
>> registered 'directly', but other fonts are registered with resolving 
>> of symbolic
>> links (see registerFontsOnPath invocation in 
>> SunFontManager.loadFonts()).
>> So paths comparison in FontFamily.isFromSameSource doesn't always work
>> currently. The proposal is to add symlink resolution to
>> FontFamily.isFromSameSource before path comparison. There are 
>> probably other
>> ways to fix the issue - by changing the way fonts are registered, but 
>> this one
>> seems to be safer in terms of possible regressions.
>>
>> Best regards,
>> Dmitry Batrak
>