e provided font "Lucida Sans Regular"
>> to the cascaded list so that we get the "alef" glyph.
>> The reason for choosing "Lucida Sans Regular" over "Lucida Bright
>> Regular" is, because it is the largest font file in jre and
I faced the same issue while investigating and trying for solution for
8147002.
Looks good to me.
Regards
Prasanta
On 2/10/2017 1:00 AM, Philip Race wrote:
http://cr.openjdk.java.net/~prr/8172967/
https://bugs.openjdk.java.net/browse/JDK-8172967
Full evaluation in the bug report.
Short summa
So +1 .. and please update the CCC
-phil.
On 2/9/17, 8:51 PM, Jayathirth D V wrote:
Hi,
Phil & Jim thanks for your review.
I have modified the code to remove the unneeded import of import
java.util.Objects.
Please find the updated webrev :
http://cr.openjdk.java.net/~jdv/7107905/webrev.1
147002/webrev.00/>
Regards
Prasanta
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170209/37baa90a/attachment-0001.html>
--
Message: 2
Date: Thu, 9 Feb 2017 19:
Hi,
Phil & Jim thanks for your review.
I have modified the code to remove the unneeded import of import
java.util.Objects.
Please find the updated webrev :
http://cr.openjdk.java.net/~jdv/7107905/webrev.19/
Thanks,
Jay
From: Phil Race
Sent: Friday, February 10, 2017 3:35 AM
To
Hi Prahalad,
Changes are fine.
Thanks,
Jay
-Original Message-
From: Philip Race
Sent: Wednesday, February 08, 2017 4:50 AM
To: Prahalad Kumar Narayanan
Cc: 2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [9] RFR: [JDK-6852563] ArrayOutOfBoundException
when reading RLE8 compressed
a.net/~psadhukhan/8147002/webrev.00/
> <http://cr.openjdk.java.net/%7Epsadhukhan/8147002/webrev.00/>
>
> Regards
> Prasanta
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170209/37baa90a/at
is the largest font file in jre and has all the glyph codepoints
that no other font in the jre has, so we will not lose out on any codepoints
and will help us in not getting missing glyph.
webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/
Regards
Prasanta
-- next p
I am OK with this if you can confirm that removing Lucida Sans Regular
from the JDK does not cause any nasty exceptions.
Apple use the PostScript name but our lookup code should work for the
TrueType name.
So overall I think this should be fine - from visual inspection - and
assuming it has
Oh .. my reply was to an off-list email. I did not notice that.
So I should repeat that here :
On 2/9/17 12:38 PM, Phil Race wrote:
32 import java.util.Objects;
This is now un-used, isn't it ? Yet all 3 subclasses still have this
import.
I don't need to "approve" a new webrev containing that
From my end this looks good. +1 except for 2 outstanding review issues:
- Would like to hear back final comments from Joe Darcy on the new doc
changes/CCC request
- Phil pointed out that there is an unneeded import in some of the files. I agree that we should make a final webrev to
delete the
http://cr.openjdk.java.net/~prr/8172967/
https://bugs.openjdk.java.net/browse/JDK-8172967
Full evaluation in the bug report.
Short summary: avoid AIOB and NPE when Mac glyph mapper returns
a negated unicode which is misinterpreted as having composite font slot 255
-phil.
Hi All,
Please review a fix for an issue which causes arabic character "alef" to
be not rendered in osx for menlo font in italic style.
Bug: https://bugs.openjdk.java.net/browse/JDK-8147002
The issue was actually a regression caused by the fix to JDK-7162125:
[macosx] A font has different be
13 matches
Mail list logo