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

Dmitry Batrak dmitry.batrak at jetbrains.com
Mon Feb 13 07:47:26 UTC 2017

Could anyone else review this please?

Best regards,
Dmitry Batrak

On Wed, Feb 8, 2017 at 3:34 AM, Philip Race <philip.race at oracle.com> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170213/3009f1e2/attachment.html>

More information about the 2d-dev mailing list