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

2016-10-17 Thread Philip Race



On 10/17/16, 5:32 AM, Sergey Bylokhov wrote:

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


Our code - and API - tends to use "name" or "full name"

-phil.


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.







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

2016-10-17 Thread Philip Race

Harmless either way but I have committed as you suggest.

-phil.

On 10/16/16, 12:02 PM, 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.




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

2016-10-17 Thread Sergey Bylokhov

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


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.


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

2016-10-16 Thread Vadim Pakhnushev
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.




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

2016-10-16 Thread Philip Race

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.


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

2016-10-12 Thread Philip Race

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.