Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8164818

Reg. test java/awt/font/TextLayout/VisibleAdvance.java fails



    • Bug
    • Resolution: Fixed
    • P3
    • 9
    • 9
    • client-libs
    • 2d
    • b137


      This is split off from https://bugs.openjdk.java.net/browse/JDK-8144015 as the issue is sufficiently distinct from
      all the others there

      Pasting info from that original report :
      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

      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.




            prr Philip Race
            prr Philip Race
            0 Vote for this issue
            2 Start watching this issue