<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Martin,<br>
      <br>
      Although I have yet to test it, the fix looks reasonable to me.<br>
      Probably this decompose outline function supporting<br>
      the callbacks was overlooked when this code was written.<br>
      A jtreg test is tricky as you need to have font data available
      that exercises<br>
      the buggy case and then use the resulting Path2D. But there is no
      way<br>
      to rely on a particular font with a known property being available<br>
      without creating one and checking it in .. that might be overkill.<br>
      <br>
      Plus how do you test this in an automated way ?<br>
      You can't compare the freetype glyph rasterisation with the pisces
      rasterisation (that done using fill(..))<br>
      as they are highly likely to differ in some tiny ways and knowing
      how much difference to<br>
      allow is fraught too, leading to a fragile test.<br>
      <br>
      So noreg-hard and some alternative testing which likely involves a
      manual<br>
      run through Font2DTest to make sure everything seems good.<br>
      I think SQE have some image comparison testing but even if they
      cover much<br>
      outline font rendering which I doubt, I don't think they run it on
      the open builds very often<br>
      <br>
      FWIW the test code could have been simpler as in :-<br>
      <br>
         public static void writeImage(File fontFile, File outputFile,
      String value) throws Exception {<br>
              BufferedImage image = new BufferedImage(200, 200,
      BufferedImage.TYPE_INT_RGB);<br>
              Graphics2D g = image.createGraphics();<br>
              g.setColor(Color.WHITE);<br>
              g.fillRect(0, 0, image.getWidth(), image.getHeight());<br>
              g.setColor(Color.BLACK);<br>
      <br>
              Font font = Font.createFont(Font.TRUETYPE_FONT, fontFile);<br>
              font = font.deriveFont(Font.PLAIN, 72f);<br>
              FontRenderContext frc = new FontRenderContext(null, false,
      false);<br>
              GlyphVector gv = font.createGlyphVector(frc, value);<br>
              g.drawGlyphVector(gv, 10, 80);<br>
              g.fill(gv.getOutline(10, 180));<br>
              ImageIO.write(image, "png", outputFile);<br>
          }<br>
      <br>
      and then you don't need that G2D subclass.<br>
      <br>
      There should of course be a client-libs/2d bug on this. <br>
      I submitted <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8057986">https://bugs.openjdk.java.net/browse/JDK-8057986</a><br>
      <br>
      Next thing to do is test the fix on an openjdk build using
      Font2DTest.<br>
      <br>
      <br>
      -phil.<br>
      <br>
      <br>
      On 9/5/2014 6:57 PM, Martin Buchholz wrote:<br>
    </div>
    <blockquote
cite="mid:CA+kOe0_XWtdLOqv10454TJFmh_2VzpJr=zrqbEaK6pc1HngS5A@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi font friends!
        <div><br>
        </div>
        <div>I'm trying to share a font rendering bug fix contributed by
          my colleagues Behdad and Igor.</div>
        <div><br>
        </div>
        <div><a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/freetypeScaler-outline/">http://cr.openjdk.java.net/~martin/webrevs/openjdk9/freetypeScaler-outline/</a><br>
        </div>
        <div><br>
        </div>
        <div>Repro recipe:</div>
        <div><br>
        </div>
        <div>(cd test/java/awt/font/GlyphVector/ && javac
          GlyphVectorOutline.java && wget -q -O/tmp/msgothic.ttc
          <a moz-do-not-send="true"
            href="https://browserlinux-jp.googlecode.com/files/msgothic.ttc">https://browserlinux-jp.googlecode.com/files/msgothic.ttc</a>
          && java GlyphVectorOutline /tmp/msgothic.ttc
          /tmp/katakana.png)<br>
        </div>
        <div><br>
        </div>
        <div>After successfully running that, examine the two rendered
          Japanese characters. </div>
        <div><br>
        </div>
        <div>Without our fix, the lower one is misrendered.</div>
        <div><br>
        </div>
        <div>I don't know how the fix works, and whether/how the manual
          test case can be turned into a real jtreg test.</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>