On 12/29/2014 03:11 AM, Sergey Bylokhov wrote:
Hi, Phil.
The fix looks fine. Note that necessary tags are absent in the test
(@test etc).
oops. I'll fix that before I push.
This thread got lost over the long break and
Andrew had a question (which) I just answered so I'll push
awhen he comes back as OK with the answer.
-phil.
On 24.12.2014 0:30, Phil Race wrote:
On 12/23/2014 11:10 AM, Sergey Bylokhov wrote:
Hi, Phil.
Probably it is possible to move the new code in
CFontManager.loadFonts() to the SunFontManager.loadFonts()?
No .. its completely mac-specific.
Note that in the test the text "Big italic red text" should be
..."black text",
that was taken from the original bug.
and the window should be disposed at the end of the test.
I can update the test before I push.
> Why this test is mac specific?
Because the whole problem is mac-specific and you can't find the
situation
with the fonts that cause this problem elsewhere. Its really iffy to
test at all ..
Note that I am using glyphcodes, which means you have to know exactly
what font you have.
-phil.
On 15.12.2014 23:20, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK-8064833
http://cr.openjdk.java.net/~prr/8064833/
OS X font look up is using family name + style - even when using
deriveFont
from a specific font. Since the family name like "Helvetica" is
insufficient to
convey that you are using the "Helvetica Light" subfamily and we
get the
wronf font.
The provided test shows that the results can be completely garbage
rendering.
Some clean up included here is remove the unconditional define of
DEBUG and
the native 'isFakeItalic' variable which was not used anywhere.
-phil.
