JDK-8230672 : Specification for java.awt.FontMetrics.getMaxAdvance() is too prescriptive.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 11,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-09-05
  • Updated: 2021-10-11
  • Resolved: 2020-04-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15 b22Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Description
The specification says 
====
public int getMaxAdvance()

Gets the maximum advance width of any character in this Font.
The advance is the distance from the leftmost point to the rightmost point on the string's baseline.
The advance of a String is not necessarily the sum of the advances of its characters.

Returns:
    the maximum advance width of any character in the Font,
    or -1 if the maximum advance width is not known.

==


The problem here is mainly with the first line "Gets the maximum advance width of any character in this Font."

The only practical way to obtain this information is to read it from a field in the font.

If the font is incorrect, this value may be incorrect.

That being due to a bug in the font is one of the least likely reasons it may be incorrect.

More likely ones are

- Errors due to rendering at small sizes

- Variation due to rendering behaviour, which may be determined by the platform, and opaque to the caller

- Variation due to a necessity to use an algorithm to synthesise a requested style such as bold which is not otherwise possible.

What are the uses of this API ? Presumably to determine an amount of space to allocate to be sure

some given number of characters in a font will fit.

But as noted "The advance of a String is not necessarily the sum of the advances of its characters"

It could be slightly more, or notably with Arabic, much less.

And anyway advance width is not the same thing as width in pixels of the glyph image

So anyone using this to calculate size needs to be ready for it to be less than perfect.

Perhaps this API should be deprecated, but there is not an easy replacement.

At a minimum, we should add caveats to the documentation along the lines above.


The following cautionary text is proposed

"The accuracy of this API is dependent on the font itself, and the extent to which requested rendering

behaviour may affect the advance width of characters. Notably, at small sizes, and when synthetic bolding is in effect.

Exceeding the maximum advance by at least one user space pixel is then possible."


Also after the text "not necessarily the sum of the advances of its characters", add

"Nor is advance width the same as character image width, so if this value is used to determine

the space need to render, then in extreme cases, this may result in slightly less space than required,

or much more space than required, depending on the specific text being drawn".
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/11d2c910d6c2 User: psadhukhan Date: 2020-05-02 04:34:47 +0000
02-05-2020

URL: https://hg.openjdk.java.net/jdk/client/rev/11d2c910d6c2 User: prr Date: 2020-04-28 19:28:49 +0000
28-04-2020

I am proposing even broader loosening of what the spec allows : http://cr.openjdk.java.net/~prr/8230672/
22-04-2020