Bug ID: JDK-8144012 [PIT][macosx] Failure of closed/java/awt/FontClass/FontStringBounds.java

Versions (Unresolved/Resolved/Fixed)

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 17	JDK 18
17 b31Fixed	18Fixed

RULE  "closed/java/awt/FontClass/FontStringBounds.java" Exception java.lang.Exception: bounds are UNEQUAL

This test fails in the current client PIT which may be a regression after JDK-8143177 (HarfBuzz) or JDK-7162125 (unlikely).

Here's the output:
r1: java.awt.geom.Rectangle2D$Float[x=0.0,y=-11.6015625,w=29.0,h=14.1328125]
r2: java.awt.geom.Rectangle2D$Float[x=0.0,y=-11.6015625,w=29.78125,h=14.1328125]

The test fails on Mac only.

This fails with JDK 17 b23 and passes with JDK 17 b24. Fixed by JDK-8256372. We can use this bug ID to de-problem lust the test.
07-07-2021
This can't be fixed without new support in harfbuzz
26-05-2018
Targeted to 10 as an issue introduced in 8u or 9
17-02-2017
Approved by component triage team to defer
29-08-2016
SQE: JDK 9: Ok to defer
29-08-2016
Based on the above we need to defer this bug. Any fix would need to use Apple private API (which we already do elsewhere but still ..) and make changes to harfbuzz itself. Also the impact is limited to AAT fonts on OS X in cases where we need to use TextLayout and further limited to just a small difference in the measurement of the text.
26-08-2016
It appears that coretext always (and only) uses fractional metrics. Thus the advance of even a single character is reported as (eg) 8.818 instead of 9 for "H". It is possible that there is private Apple API which forces integer metrics - see "@CTIntegerMetrics" in CTextPipe.m and might work but I don't see how to apply it. Harfbuzz itself creates the CT font, and also it uses "36 pt" as the text size when talking to CT and scales it later. So we'll never get the correct integer metrics anyway. i.e if it reports "26" and then this is divided by 3.0 to get back to 12 pt we'll have a float again .. and a second rounding will just introduce additional error. As an aside, I noticed that fractional metrics is not being applied if we use bi-level (B&W) text. Only if AA is on. This is nothing to do with TextLayout - it is the case for a simple call to Font.getStringBounds(..) and worked properly in Apple JDK 6
26-08-2016
The test uses Dialog which maps to Lucida Grande on MacOSX. The ICU code had support for AAT (mort and morx) tables which is what I believe is present in Lucida Grande and controlled what features were applied by default. In the case of harfbuzz it does not yet have native support for this so we invoke a coretext path. A sampling with a couple of other fonts : Helvetica and Geneva also fail. Other fonts that are OpenType (Tahoma, Times New Roman) pass. So not definitive but at least suggestive of where the problem lies.
12-08-2016

Duplicate :	JDK-8258984 - [macos] Graphics attributed string and "FontMetrics.stringWidth" inconsistency
Duplicate :	JDK-8172960 - [macosx] Text layout for AAT fonts ignores fractional metrics setting on macOS
Relates :	JDK-8256372 - [macos] Unexpected symbol was displayed on JTextField with Monospaced font
Relates :	JDK-8144015 - [PIT] failures of text layout font tests