<div dir="ltr">I have tried to cross all the t's left here.  I took your suggestion and minimized the test greatly.  I've taken ownership of the bug and it's now marked noreg-hard.<div><br></div><div>I'm inclined to check in the test case as is, even though it's manual.  But I leave that to you, the 2d maintainers.</div><div><br></div><div>The only testing I've done is to run the one manual test.  Hope that's OK.</div><div><br></div><div>OK to commit this fix?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 2:47 PM, Phil Race <span dir="ltr"><<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>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 href="https://bugs.openjdk.java.net/browse/JDK-8057986" target="_blank">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.<span class="HOEnZb"><font color="#888888"><br>
      <br>
      <br>
      -phil.</font></span><div><div class="h5"><br>
      <br>
      <br>
      On 9/5/2014 6:57 PM, Martin Buchholz wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote 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 href="http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/freetypeScaler-outline/" target="_blank">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 href="https://browserlinux-jp.googlecode.com/files/msgothic.ttc" target="_blank">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>
  </div></div></div>

</blockquote></div><br></div>