Hi Phil, Sergey,
Thank you for reviewing!
I suggest pushing the current version of the fix:
http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/
It's Andrew's fix, and I'll push it under his name, giving him the credit.
As for FontFamily.getClosestStyle(), I'll submit a new bug to
investigate the behavior. We will update getClosestStyle() if necessary.
Thanks,
Alexey
On 01.06.2016 13:21, Alexey Ivanov wrote:
Hi Phil,
On 01.06.2016 0:07, Phil Race wrote:
getClosestStyle() is something of a last resort.
Historically I think it was called only when you
had only a font *with* a style like bold and someone asked for
plain/regular.
ie for the subtractive case rather than the additive case.
So it would not apply to the case in this bug.
However OS X does not natively support synthetic styling so we may
be entering that method for the additive case on OS X.
So will not have this same bug since it just does not happen.
In which case the reamaining question is, when you only have BOLD and
ITALIC
and someone asks for BOLDITALIC and you can't synthesise at all,
which do you give them ?
So it needs additional testing. However, I think GDI still returns
Bold in this case: this way it would look consistent.
I'd still lean towards ITALIC - assuming I have ITALIC, so we do not
need to update that method.
If it can be shown otherwise we can make the change.
Do you think we should push the fix as is, and leave
FontFamily.getClosestStyle() as it is now?
Then test how native systems behave and update this method if necessary.
Thanks,
Alexey
-phil.
On 05/31/2016 09:43 AM, Sergey Bylokhov wrote:
On 31.05.16 19:30, Phil Race wrote:
The patch changes the order of font selection: bold will be used, if
possible, as the base for bold-italic instead of italic which is the
current default. It also fixes the issue where italic is returned
instead of bold.
OK. +1
I am not sure but should FontFamily.getClosestStyle() be updated also?:
case Font.BOLD|Font.ITALIC:
if (italic != null) {
return italic;
} else if (bold != null) {
return bold;
} else {
return plain;
}
}
-phil.
Thank you in advance,
Alexey
On 22.07.2015 19:33, Alexey Ivanov wrote:
Hi Phil,
On 16.07.2015 21:38, Phil Race wrote:
On 07/16/2015 06:08 AM, Andrew Brygin wrote:
Hi Phil,
another option to avoid the problem is to be a bit more specific
regarding the
required font when we obtaining lcd glyph from GDI.
If we specify a particular name of the font which we used to
construct the
glyph vector, then we will get glyphs exactly for desired
characters:
http://cr.openjdk.java.net/~bae/8078382/9/webrev.01/
This change affects only the case of lcd glyphs on windows,
it reduces the scope of required testing.
This is heading in the direction I was thinking of but since GDI is
excepting a face name
(what we call a family name), I am not sure if this will always
work
as is.
There are possible issues with using a localized name and the
length
of the full name exceeding what Windows allows here.
And there may be unintended consequences that are not immediately
obvious.
I would like to try limit this to the case where we can positively
identify that the
font is not the one we expected. And do it cheaply too.
I do not have a quick answer here but roughly the algorithm
might be
- specify family, check (somehow) if GDI selects the same base font
- if not, try the facename approach (if the name fits). Did we
succeed and get the same base font ?
- if not, bail on GDI for this case and do the rasterisation
ourselves.
"cheaply" might depend on caching a success value on the first
attempt, so
that we only do it once, ever, for a font. Then the problem becomes
how to
do the verification. One approach might be to call GetFontData()
which
will give us some chunk of the font file and we can see if the name
(or something
else we can quickly and reliably parse) is exactly that we
expect ..
It looks there's no easy way to detect whether GDI selected the same
base font or not. GetTextFace function doesn't help it: it always
returns the face name passed in LOGFONT except in the cases where
there's no such font.
I haven't found any other API which could tell us what font GDI
selected. So the only alternative is to use GetFontData and parse
the
font file itself. Yet I can't find any example how to use this
function. I'll keep searching in that direction.
Regards,
Alexey
Leaving aside the 'wrong glyph' case, I have to suppose it is
possible that
there are other un-noticed cases where we use a different base font
than
that selected by GDI. The algorithms are not defined anywhere I can
locate.
However, there seems to be a copy&paste error in FontFamily.java:
on lines 340 - 341 we check that bold font fits our needs but use
italic
anyway. Was it done by purpose, or this is really an error?
That is a copy/paste mistake. It should be fixed.
-phil.
Thanks,
Andrew
On 7/15/2015 7:25 PM, Phil Race wrote:
This probably needs more examination and perhaps a more
complex fix.
The observation that GDI bases bold-italic on the bold version
not
the
italic version is an implementation choice just as we had done
the
opposite. It is possible some other time it does the opposite
or some
other platform does the opposite. I have supposed it is harder to
synthesise italic than to do 'over-strike'. And this GDI usage
applies only to LCD glyphs.
Maybe what we need to do is see if we can detect the cases when
GDI and JDK disagree on the actual font and remap the glyph id.
-phil.
On 7/15/15 4:12 AM, Andrew Brygin wrote:
Hello,
could you please review a fix for 8078382?
bug: https://bugs.openjdk.java.net/browse/JDK-8078382
webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/
The problem is caused by following peculiarity of the Code New
Roman font: this font provides plain, italic and bold variants.
In bold and italic variants of the font, different glyphs
correspond to the apostrophe character (0039):
bold: 0039 -> 0x250 (592)
italic: 0039 -> 0x256 (598)
So, we translate character to glyphs using italic variant
of the font, and then request glyph images from GDI.
However, GDI uses the bold variant of the font in order
to compose glyph images for artificial bold-italic variant,
and we have got a glyph image for ® instead of apostrophe.
Suggested fix is to select bold variant (if possible) as a
base for artificial bold-italic.
There is no regression test because it requires a specific font
to be installed on a test system. The font can be found here:
http://www.dafont.com/code-new-roman.font
Please take a look.
Thanks,
Andrew
