[OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point

[Martin Buchholz]

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?

On Tue, Sep 9, 2014 at 2:47 PM, Phil Race <philip.race at oracle.com> 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/
>
>  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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140910/8000bb6a/attachment.html>