[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] [9] request for review: 8078382: Wrong glyph is displayed for a derived font
From:       Alexey Ivanov <alexey.ivanov () oracle ! com>
Date:       2016-04-21 14:37:18
Message-ID: 5718E59E.6060804 () oracle ! com
[Download RAW message or body]

Hi Phil,

I ran a number of tests with different fonts: Windows GDI consistently 
selects Bold rather than Italic to produce the missing Bold Italic.

So I suggest using Andrew's first patch:

http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/

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.


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
>>>>
>>>
>>
>

[prev in list] [next in list] [prev in thread] [next in thread]