[OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font always displays as regular - no bold or oblique.

[Sergey Bylokhov]

On 12.10.16 20:32, Phil Race wrote:
> Any way here is my latest proposal which goes the more succinct route but
> tries to make it clear that logical fonts are affected.
> Can I get a "+1" from someone ?
>
>  * Glyphs may not always be rendered with the requested properties (e.g,
> font
>  * and style) due to platform limitations such as the absence of suitable
>  * platform fonts to implement a logical font.
>  * <p>

+1

>
>
> BTW an update on the OSX issue that started this.
> It is looking very much like a platform renderer behaviour in that
> for Times Bold non-AA size 12 looks like Regular but size 13 (where we do
> all the same things) looks Bold. So an OS X oddity (or bug).
> At first it looked like its always the even sizes since 14 is also
> regular ..
> but then it turns out 16 looks bold (and different than 16 plain).
> So no obvious pattern.
>
> -phil.
>
> On 10/06/2016 09:52 AM, Phil Race wrote:
>> I've also had a suggestion to be more succinct and just add one line :
>> "Glyphs may not always be rendered with the requested properties (e.g,
>> font and style)
>> due to platform limitations such as absence of certain fonts".
>>
>> I'd be OK with either my wording or the above ..
>>
>> -phil.
>>
>> On 10/05/2016 04:05 PM, Philip Race wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8166034
>>>
>>> Non-AA fonts aren't always being bolded on OS X.
>>> FWIW I believe this is in part a platform (OS) bug since it is
>>> terribly inconsistent
>>> across fonts and in some cases even sizes.
>>>
>>> So we need to look into why but it definitely isn't something that
>>> calls for changing the font used by the Motif L&F as proposed here
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006732.html
>>>
>>>
>>> And it calls out something I've seen a few times recently and I've
>>> documented some examples in the bug report.
>>> So we need to explain in the java.awt.Font spec. that sometimes
>>> we are beholden to the limits of the platform.
>>>
>>> Investigating specific issues then become quality bugs .. but not
>>> conformance ones.
>>>
>>> Added class description text below :-
>>>
>>> -phil.
>>>
>>> diff --git a/src/java.desktop/share/classes/java/awt/Font.java
>>> b/src/java.desktop/share/classes/java/awt/Font.java
>>> --- a/src/java.desktop/share/classes/java/awt/Font.java
>>> +++ b/src/java.desktop/share/classes/java/awt/Font.java
>>> @@ -154,6 +154,13 @@
>>>   * associated with a font face, each differing in size, style,
>>> transform
>>>   * and font features.
>>>   * <p>
>>> + * The visual rendering of all, or part of, one logical font
>>> vis-a-vis another
>>> + * may not always be different where there are limited suitable
>>> fonts available.
>>> + * The same is true for one style vis-a-vis another. This is generally
>>> + * due to one form or another of platform limitation or behavior.
>>> + * In the absence of such limitations a compliant implementation
>>> + * will render glyphs which exhibit the requested properties.
>>> + * <p>
>>>   * The {@link GraphicsEnvironment#getAllFonts() getAllFonts} method
>>>   * of the {@code GraphicsEnvironment} class returns an
>>>   * array of all font faces available in the system. These font faces
>>> are
>>
>


-- 
Best regards, Sergey.