[OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup uses family+style, not full name/postscript name

[Andrew Brygin]

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.
>>
>