On 9/10/2014 2:31 PM, Martin Buchholz wrote:
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.
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.
The only testing I've done is to run the one manual test. Hope that's OK.
OK to commit this fix?
Do we yet have a 2nd reviewer on the change ?
Other than that its fine by me.
-phil.
On Tue, Sep 9, 2014 at 2:47 PM, Phil Race <[email protected]
<mailto:[email protected]>> wrote:
Martin,
Although I have yet to test it, the fix looks reasonable to me.
Probably this decompose outline function supporting
the callbacks was overlooked when this code was written.
A jtreg test is tricky as you need to have font data available
that exercises
the buggy case and then use the resulting Path2D. But there is no way
to rely on a particular font with a known property being available
without creating one and checking it in .. that might be overkill.
Plus how do you test this in an automated way ?
You can't compare the freetype glyph rasterisation with the pisces
rasterisation (that done using fill(..))
as they are highly likely to differ in some tiny ways and knowing
how much difference to
allow is fraught too, leading to a fragile test.
So noreg-hard and some alternative testing which likely involves a
manual
run through Font2DTest to make sure everything seems good.
I think SQE have some image comparison testing but even if they
cover much
outline font rendering which I doubt, I don't think they run it on
the open builds very often
FWIW the test code could have been simpler as in :-
public static void writeImage(File fontFile, File outputFile,
String value) throws Exception {
BufferedImage image = new BufferedImage(200, 200,
BufferedImage.TYPE_INT_RGB);
Graphics2D g = image.createGraphics();
g.setColor(Color.WHITE);
g.fillRect(0, 0, image.getWidth(), image.getHeight());
g.setColor(Color.BLACK);
Font font = Font.createFont(Font.TRUETYPE_FONT, fontFile);
font = font.deriveFont(Font.PLAIN, 72f);
FontRenderContext frc = new FontRenderContext(null, false,
false);
GlyphVector gv = font.createGlyphVector(frc, value);
g.drawGlyphVector(gv, 10, 80);
g.fill(gv.getOutline(10, 180));
ImageIO.write(image, "png", outputFile);
}
and then you don't need that G2D subclass.
There should of course be a client-libs/2d bug on this.
I submitted https://bugs.openjdk.java.net/browse/JDK-8057986
Next thing to do is test the fix on an openjdk build using Font2DTest.
-phil.
On 9/5/2014 6:57 PM, Martin Buchholz wrote:
Hi font friends!
I'm trying to share a font rendering bug fix contributed by my
colleagues Behdad and Igor.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/freetypeScaler-outline/
<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/freetypeScaler-outline/>
Repro recipe:
(cd test/java/awt/font/GlyphVector/ && javac
GlyphVectorOutline.java && wget -q -O/tmp/msgothic.ttc
https://browserlinux-jp.googlecode.com/files/msgothic.ttc && java
GlyphVectorOutline /tmp/msgothic.ttc /tmp/katakana.png)
After successfully running that, examine the two rendered
Japanese characters.
Without our fix, the lower one is misrendered.
I don't know how the fix works, and whether/how the manual test
case can be turned into a real jtreg test.
