[OpenJDK 2D-Dev] RFR: 8230672: Spec. for FontMetrics.getMaxAdvance is too prescriptive.

[Sergey Bylokhov]

On 4/23/20 10:00 am, Philip Race wrote:
> I am not 100% sure what you are getting at, but maybe
> "render each such character" could be rephrased as
> "query the advance of each such character".
> 
> But I would not point to charWidth() for this because
> it is not adequate for all code points.
> 
> Does that clear it up ?

Yes it looks better.

> 
> -phil.
> 
> On 4/23/20, 9:49 AM, Sergey Bylokhov wrote:
>> On 4/23/20 9:34 am, Philip Race wrote:
>>> No, I don't see the relationship.
>>>
>>> charWidth() is accurate if you use the FontMetrics from the render context.
>>
>> If it is always accurate why it is not recommended in the new documentation? Why we suggest to "render each such character".
>>
>>  299      * None of these are exposed and they are all implementation details,
>>  300      * and there is no practical way to determine this. An application
>>  301      * which needs a better estimate of the maximum advance, and knows
>>  302      * the subset of characters it expects to display could render
>>  303      * each such character to find the widest, but as discussed above,
>>  304      * since the displayed width of a {@code String} is not necessarily
>>  305      * the sum of the advances the value needs to be used with caution.
>>
>>>
>>> -phil.
>>>
>>> On 4/23/20, 9:19 AM, Sergey Bylokhov wrote:
>>>> Hi, Phil.
>>>>
>>>> Isn't all/some of the new text in getMaxAdvance() is also applicable to charWidth()?
>>>> If I read the current doc properly then it looks like the charWidth() should return "advance"
>>>> of some specific "advance", and getMaxAdvance() is "just" maximum value of any possible
>>>> results from the charWidth().
>>>>
>>>> On 4/22/20 12:49 pm, Philip Race wrote:
>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8230672
>>>>> webrev : http://cr.openjdk.java.net/~prr/8230672/
>>>>>
>>>>> Loosen up the spec. a lot to reflect reality.
>>>>>
>>>>> I considered deprecating the method but there isn't any easy replacement,
>>>>> so it would just be annoying to old code.
>>>>>
>>>>> This will clearly need a CSR which I will draft once we agree on the text here.
>>>>>
>>>>> -phil.
>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.