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
