Could anyone else review this please? Best regards, Dmitry Batrak
On Wed, Feb 8, 2017 at 3:34 AM, Philip Race <philip.r...@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 >>> >> >>
