javasvgfontstruetypebatik

Why does Apache Batik Rasterizer render TrueType font incorrectly?

I'm using Apache Batik rasterizer (Java, Oracle JRE 7 on Ubuntu) to convert a SVG into a PDF. The SVG contains text and references ttf fonts, which works well, but the font Diehl Deco does not render as expected:

Expected:

enter image description here

Incorrect:

enter image description here

As you can see the "R" flows into the "A", so the kerning is not interpreted correctly as the font itself contains this information (thx to the comment from @Jongware): R A -> -660, T E -> -61

Possible solutions:

1) I think if we could exchange the font rendering engine of batik to use freetype it could work as it renders correctly in my Libre Office Writer, which uses freetype.

2) I could convert the ttf font into a SVG font, which could work better in this case of SVG to PDF rasterization. But so far I wasn't successful.

3) I could convert the fonts inside the SVG to paths, if any tools supports that propperly.

Any comments or other solutions are highly welcome! Thanks!

Solution

  • Found a solution worth sharing:

    Batik rasterizer uses AWT GlyphVector (Java) for font rendering, which seems not capable of rendering kerning correctly - at least for this font.

    I got it working as expected by converting the ttf font into a svg font via batik ttf2svg. Other tools did not work - at least in combination with batik rasterizer.

    I used following command to convert the font:

    java -jar /path/to/batik/batik-1.8/batik-ttf2svg-1.8.jar diehl_deco.ttf -o diehl_deco.svg -id DiehlDeco -l 32 -h 20000`

    In my input svg for conversion to pdf I referenced the font via @font-faces. The id in the above command is the same as the one at the end of the font url: #DiehlDeco

    <defs><style type="text/css"><![CDATA[
    @font-face { 
        font-family: 'diehl_deco';
        src: url('https://path/to/diehl_deco.svg#DiehlDeco') format('svg');
        font-weight: normal;
        font-style: normal;
    }
]]></style></defs>

    The option -l 32 is essential - at least for this font - as the first 32 unicode characters are not compatible with batik rasterizer. If your font does not render at all a single character in the svg font can be the problem.