[OpenJDK 2D-Dev] RFR: 8089573: [macosx] Incorrect char to glyph mapping printing on OSX 10.10

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Mon Oct 17 12:32:03 UTC 2016

Looks fine.
I am not only sure about the difference in the variable names: "name" VS 

On 16.10.16 22:02, Vadim Pakhnushev wrote:
> I guess you could reorder the calls for CFRelease(font); and
> CFRelease(desc); so the desc gets released first in two locations under
> family == NULL and name == NULL.
> Just for the sake of consistency.
> Other than that, +1.
> Vadim
> On 16.10.2016 19:09, Philip Race wrote:
>> Anyone ? I'd like to get this backported to 8u this week so it
>> can the 8u122 release which will enter RDP2 soon
>> http://openjdk.java.net/projects/jdk8u/releases/8u122.html
>> Although I have failed to find any email documenting the exact date
>> the freeze is usually a week earlier than the RDP date so it could
>> be as early as a week from now ..
>> -phil.
>> On 10/12/16, 1:06 PM, Philip Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8089573
>>> Webrev : http://cr.openjdk.java.net/~prr/8089573/
>>> See the bug for some images showing the problem of scrambled text
>>> when printing.
>>> Although only
>>> JavaFX is affected the solution is entirely on the JDK side.
>>> JavaFX looks up some UI "system" fonts via special API calls and
>>> these are fonts
>>> that are not otherwise enumerated by CoreText.
>>> JavaFX expects JDK to be able to access these fonts but it cannot.
>>> We need to make the same API calls on JDK.
>>> The exact fonts returned vary by MacOS release so it seems hard to
>>> create a JDK regression
>>> test but on the FX side it is seen instantly if you print a UI
>>> control as the text is messed up
>>> due to incorrect glyph ids.
>>> I intend to backport this to 8u and I've verified this does fix it on
>>> 8u too ..
>>> Also both 8 & 9 build successfully with JPRT.
>>> -phil.

Best regards, Sergey.

More information about the 2d-dev mailing list