[OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font

Prahalad Kumar Narayanan prahalad.kumar.narayanan at oracle.com
Thu Oct 13 06:20:14 UTC 2016


The wordings that mention: 
" ... absence of suitable platform fonts to implement a logical font ", is more appropriate.

Have a good day

Prahalad N.


Message: 4
Date: Wed, 12 Oct 2016 10:32:59 -0700
From: Phil Race <philip.race at oracle.com>
To: 2d-dev <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font
	always displays as regular - no bold or oblique.
Message-ID: <64a24f7d-8fa3-a5c3-611f-8f4123e23e67 at oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

I haven't had any feed back on this.

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>

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.


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

More information about the 2d-dev mailing list