JDK-8144015 : [PIT] failures of text layout font tests
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-11-25
  • Updated: 2017-07-13
  • Resolved: 2016-09-01
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 9
9 b137Fixed
Related Reports
Relates :  
JDK-8144012 - [PIT][macosx] Failure of closed/java/awt/FontClass/FontStringBounds.java
Relates :  
JDK-8169188 - [macos] java/awt/font/TextLayout/TextLayoutBounds.java always fail
Description
RULE "closed/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub.java" Exception java.lang.Error: room for more words on line.

RULE "closed/java/awt/font/TextLayout/LigatureCaretTest.java" Exception java.lang.Error: right hit failed within layout

RULE "closed/java/awt/font/TextLayout/TestGetPixelBounds.java" Exception java.lang.RuntimeException: error, tl.bounds does not contain computed bounds

These three tests have no history of failures.  Of them, TestGetPixelBounds.java fails on Linux only (OEL 7, Gnome 3, ATI).
Two other fail on all three platforms.

These are failures on PIT for b96, Nov 24 2015.
Comments
The issue is that in the Harfbuzz code we take the floating point advance supplied by the font rasteriser and convert it to a fixed point format needed by harfbuzz. The format chosen is 26.6. Ultimately this gets converted *back* to floating point. However the font data internally to the rasteriser (T2K) originally was 16.16 before it was converted to floating point. So the 26.6 format can lose some precision that is available in 16.16. So when code in TexttLayout that wants the advance of SPACE gets that without going via harfbuzz (ie it indirectly calls FontStrike.getGlyphMetrics(),which is *the same (internal) API* that harfbuzz used to obtain the advance, it gets it without that loss of precision. Arguably the test should be more forgiving. Exact comparisons of floats is often not what you want. but in this case I think it may be possible instead to use 16.16 for harfbuzz too and perhaps get the same results as we used to in previous releases as well as consistent results.
25-08-2016
Regarding java/awt/font/TextLayout/VisibleAdvance.java The differences are very small and only in the visible advance. java.version = 9-internal Left-to-right (One style): Advance = 161.67188, Visible advance = 150.23633 Right-to-left (One style): Advance = 161.67188, Visible advance = 150.23438 MISMATCH in advance.. Right-to-left (One style): Advance = 161.67188, Visible advance = 150.23438, previous values were: [161.67188,150.23633] Left-to-right (Multiple styles): Advance = 161.67188, Visible advance = 150.23633 MISMATCH in advance.. Left-to-right (Multiple styles): Advance = 161.67188, Visible advance = 150.23633, previous values were: [161.67188,150.23438] Right-to-left (Multiple styles): Advance = 161.67188, Visible advance = 150.23438 ie for visible advance we have LTR = 150.23633 RTL = 150.23438 Also note the text invokes fractional metrics .. if we turn that off then as should be obvious integer rounding makes it a non-issue. We can observe the difference with the text "A ". The idea of the test was to see how RTL & trailing spaces affect the logical and visual advance. for the above case we get for visible advance : LTR: 8.666016 RTL: 8.65625 Note that " " - text just containing spaces - correctly reports 0.0
24-08-2016
A number (5) of different tests are cited in here so I will list them out and relate them to other bugs where there is one but the issues with these tests are all distinct so far .. not the same cause. closed/java/awt/font/LineBreakMeasurer/TestLineBreakWithFontSub.java is the same as https://bugs.openjdk.java.net/browse/JDK-8158924 closed/java/awt/font/TextLayout/TestGetPixelBounds.java is fixed as https://bugs.openjdk.java.net/browse/JDK-8145584 java/awt/font/TextLayout/TextLayoutBounds.java is due to kerning being applied without an explicit request. The fix will be something like this in HBShaper features = malloc(sizeof(hb_feature_t) * 2); if (features) { hb_feature_from_string("-kern", -1, &features[featureCount++]); hb_feature_from_string("-liga", -1, &features[featureCount++]); } closed/java/awt/font/TextLayout/LigatureCaretTest.java is another victim of the expectation that native layout will produce glyphs clustered in a specific way. Fixing that code should fix this Still need to investigate java/awt/font/TextLayout/VisibleAdvance.java
24-08-2016
The TestGetPixelBounds failure will be addressed as https://bugs.openjdk.java.net/browse/JDK-8145584
16-12-2015
~/client/build/linux-x86_64-normal-server-release/jdk/bin/java TestGetPixelBounds tl bounds: java.awt.geom.Rectangle2D$Float[x=1.578125,y=-12.15625,w=31.0,h=15.484375] tl compute: java.awt.Rectangle[x=1,y=-13,width=32,height=17] tl pixel bounds: java.awt.Rectangle[x=1,y=-13,width=31,height=17] again int off: java.awt.Rectangle[x=3,y=-15,width=31,height=17] again frac off: java.awt.Rectangle[x=1,y=-13,width=32,height=17] again frc: java.awt.Rectangle[x=157,y=-1216,width=3101,height=1549] again int off: java.awt.Rectangle[x=-1,y=-11,width=31,height=17] gv bounds: java.awt.Rectangle[x=1,y=-13,width=32,height=17] gv compute: java.awt.Rectangle[x=1,y=-13,width=32,height=17] Exception in thread "main" java.lang.RuntimeException: error, tl.bounds does not contain computed bounds at TestGetPixelBounds.main(TestGetPixelBounds.java:103) So we expect the 2nd of these to contain the first but it is off-by-one. tl compute: java.awt.Rectangle[x=1,y=-13,width=32,height=17] tl pixel bounds: java.awt.Rectangle[x=1,y=-13,width=31,height=17] ==== RULE "java/awt/font/TextLayout/TextLayoutBounds.java" Exception java.lang.RuntimeException: Bounds differ [gvv != tl] ==== A possible difference here is that TextLayout now implicitly doing kerning ..
25-11-2015
Let me piggyback here a pair of open tests RULE "java/awt/font/TextLayout/TextLayoutBounds.java" Exception java.lang.RuntimeException: Bounds differ [gvv != tl] RULE "java/awt/font/TextLayout/VisibleAdvance.java" Exception java.lang.RuntimeException: MISMATCH in advance.. Right-to-left (One style): Advance = ..., Visible advance = ..., previous values were: [160.75,149.31445]
25-11-2015