<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>