> We're using FreeType in our PDF rendering framework to render text
> content. Recently, a customer of ours sent us a PDF with a strange
> text rendering problem. We investigated and noticed that FreeType
> does render the glyphs wrong with this font.
>
> Admittedly, the font looks a little broken (doesn't have a charmap,
> etc) but all other PDF viewers can correctly render the text in this
> PDF with the given font. We also noticed that if we only get the
> outline of the glyph and render it ourselves it looks correct.
The font is severely broken. I tried to analyze it with Microsoft's
Visual TrueType, but this font makes VTT crash (at least under the
Wine emulator). To be more precise, the hinting bytecode is flawed,
causing the strange visual effects you are experiencing. I suspect
that the PDF generator that created this subsetted font doesn't
correctly handle TrueType bytecode.
> Attached you can find a little C program I wrote to demonstrate the
> problem. Simply compile and run and it produces a `render.png` of a
> glyph that should be an `O`. I also attached the output
> (`render.png`).
Thanks. This `stb_image_write.h' stuff is very nice!
> Is there anything else I can do to try to get FreeType to correctly
> render this font? Is there something I am overlooking or is this a
> bug?
My general advice is that PDF rendering applications must not use
bytecode hinting, especially if the font is subsetted. For example,
the hinting instructions for glyph 82 are not syntactically incorrect
(this is, FreeType doesn't abort hinting due to bad opcodes or the
like). However, they simply produce garbage.
Either switch off hinting or use light auto-hinting.
Werner
_______________________________________________
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
