[OpenJDK 2D-Dev]  request for review: 8078382: Wrong glyph is displayed for a derived font
philip.race at oracle.com
Thu Jul 16 18:38:24 UTC 2015
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:
> 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
else we can quickly and reliably parse) is exactly that we expect ..
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.
> 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.
>> On 7/15/15 4:12 AM, Andrew Brygin wrote:
>>> 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:
>>> Please take a look.
More information about the 2d-dev