JDK-8221305 : java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 11,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-22
  • Updated: 2021-10-12
  • Resolved: 2020-05-04
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 11 JDK 15
11.0.13-oracleFixed 15 b23Fixed
Related Reports
Duplicate :  
JDK-8231495 - Test java/awt/FontMetrics/MaxAdvanceIsMax.java failing on many Linux systems
Relates :  
JDK-8230672 - Specification for java.awt.FontMetrics.getMaxAdvance() is too prescriptive.
Relates :  
JDK-8223869 - Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java on more platforms
Description
As discussed in https://bugs.openjdk.java.net/browse/JDK-8221304,
I think this may be more than a test issue.
Comments
Fix request (11u): Removal of a test that was problem listed a long time ago. It tested a functionality that was not working in all scenarios/circumstances. To account for it, spec has been amended in later releases and test was removed. No risk.
12-10-2021
URL: https://hg.openjdk.java.net/jdk/jdk/rev/0dcbc6ed7c65 User: psadhukhan Date: 2020-05-09 04:20:48 +0000
09-05-2020
URL: https://hg.openjdk.java.net/jdk/client/rev/0dcbc6ed7c65 User: prr Date: 2020-05-04 18:32:24 +0000
04-05-2020
I think we should update the spec per https://bugs.openjdk.java.net/browse/JDK-8230672 and subsequently retire this test. Separating them allows a backport of the test retirement.
22-04-2020
Also note that the test case introduced to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8218854 That pointed the finger at another bug : https://bugs.openjdk.java.net/browse/JDK-8214002 which when it was fixed happened to trigger 8218854. However a) that was a fluke, b) None of the code in use in those bugs is used in the failure on macOS. So I don't think it is viable to try to make this test "work". The spec of getMaxAdvance() even allows the return of -1 if the advance isn't available and the test would pass if we did that but I am sure that would break lots and lots of code.
22-04-2020
I've looked at the failure I see on macOS and the failure is code points 130-159 for Menlo (used for Dialog). Since that font doesn't support those code points the implementation falls back to Songti SC Black, or in a few cases NanumMyeongjo. Once you fall back to some wider by design Asian font it is not surprising to see a wider advance for glyphs from that font compared to the Latin centric Menlo font. The code point range that fails is interesting because it is mostly not printable characters but it doesn't change the fundamental issue. Fall backs are good for coverage, but cause problems for APIs like canDIsplay() - although that one can be argued about since we can display from the fall back, getMaxAdvance() and for supposedly monospaced fonts.
22-04-2020
This version of the test is failing on MacOS and also on Solaris again. We could look into the specifics of what is happening but I am not sure this API is absolutely supportable in a strict sense. Doing so would have severe practical consequences to the extent of breaking many perfectly functional applications. In many cases a font reports the linear advances but if hinting is applied these may differ. Fonts then have a hdmx table which is supposed to report the hinted advances but these are generally provided for just a limited number of sizes and then are still subject to the whims of the hinting engine implementation as to whether they match even at provided sizes - plus there is no field for a font to provide the maximum hinted advance so I suspect the linear advance is always what you get. Next we have composite fonts where the number of fonts in use is almost arbitrary - component fonts may not be "static" so that there is a list to be consulted. Asking for a code point may cause the implementation to go locate additional fonts to support that. So it is impractical to ask for millions of code points to find the absolute maximum. Then we have synthetic fonts where it may be tricky to accurately extend the max advance of the base roman font to that of an oblique or bold font. And we have different rendering modes - the table value may be designed for mono (bilevel) rendering. There is also a stricture that length of a string may not correspond to the sum of the advances and with ligatures it is theoretically possible to have ligature substitution make a string of length N be greater than N*maxAdvance. Unlikely but possible. Then we have rounding issues that may particularly affect small sizes. Finally the font may just be wrong. So what to do ? The API allows returning "-1" to say unknown but that is utterly useless to an application which is trying to get a sense of roughly what the max is to size a component. I suspect that returning -1 would blow up UIs left, right and centre. I think the only real option is to document that the value is a theoretical one that can be considered as a useful approximation but not an absolute limit.
22-03-2019