Hello Phil,
the fix looks fine to me.
Thanks,
Andrew
On 1/24/2015 12:18 AM, Phil Race wrote:
Updated webrev : http://cr.openjdk.java.net/~prr/8064833.1/
-phil
On 1/23/15 12:42 PM, Phil Race wrote:
Ah you're right I don't need to do that :)
It was a while ago now but it looks like I was using the assigned
variable
to do some debugging. I'll update the webrev - including the test.
-phil.
On 1/23/15 12:29 PM, Andrew Brygin wrote:
Hi Phil,
please see my comments inline.
On 1/23/2015 9:51 PM, Phil Race wrote:
280-282 is creating an italic version of the plain font
285-287 is creating an italic version of the bold font :
285 registerGenericFont(bold.createItalicVariant(), true);
If my understanding is correct, here we have registered the bold
italic first time
286 CFont f = bold.createItalicVariant();
287 registerGenericFont(f, true);
Here we have registered the same bold italic second time.
My question was why do we have to register italic variant two times
in row.
Could you please clarify this?
Thanks,
Andrew
so its not the same variant.
-phil.
On 12/31/2014 12:41 AM, Andrew Brygin wrote:
Hello Phil,
could you please clarify why do we need to register italic
variant twice:
CFontManager.java:
280 registerGenericFont(plain.createItalicVariant(), true);
281 CFont f = plain.createItalicVariant();
282 registerGenericFont(f, true);
the same thing is done for bold font on lines 285 - 287.
Thanks,
Andrew
On 12/15/2014 11:20 PM, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK-8064833
http://cr.openjdk.java.net/~prr/8064833/
OS X font look up is using family name + style - even when using
deriveFont
from a specific font. Since the family name like "Helvetica" is
insufficient to
convey that you are using the "Helvetica Light" subfamily and we
get the
wronf font.
The provided test shows that the results can be completely
garbage rendering.
Some clean up included here is remove the unconditional define of
DEBUG and
the native 'isFakeItalic' variable which was not used anywhere.
-phil.
