Fri 23 May 2014 01:10:22 AM UTC, original submission:
Originally at https://bugs.kde.org/show_bug.cgi?id=335058 And then at
https://bugs.freedesktop.org/show_bug.cgi?id=78990
Okular and evince (and other) linux(-ish) pdf viewers rely on poppler
which in turn relies on freetype.
Included is a pdf demonstrating the issue. It contains two version of
the same font, the ttf version being generated from the otf original
using fontforge. also included is a screenshot showing the difference.
This is on fedora 20 x86-64 which packages freetype 2.5.0. The visual
difference disappears when one zooms in to the document.
My first guess that this is a hinting issue turned out false,I've
played around with ttfautohint and the FDK autohint and that doesn't
seem to be it.
James Cloos from the poppler tracker kindly informed me that recent
freetype uses a newer engine by adobe to render otf (CID 0C) fonts,
and indeed using ftview (at 12pt) as he suggested shows that different
engines are used to render ttf vs. otf and that individual glyphs are
rendered differently, the Adobe engine rendering them much
darker. Screenshot included.
Adobe acrobat reader displays both pdf lines (fonts) very similarly
and, strangely, seems to display both unlike the "Adobe" engine used
by freetype! That is, both fonts glyphs render much lighter then
freetype does using the "Adobe" engine. Perhaps that's a matter of
settings but significantly both fonts render similarly, which seems
like much saner behaviour.
I encountered this beehavior while trying to recreate a latex page
design as closely as possible, and I was very surprised to discover
that the format of the font has such an impact on how it's displayed
by the most popular document viewers out there.
Is this in fact a bug, by design, or an unfortunate outcome of having
two engines? if so, is there a workaround users and/or application
developers can use to ensure uniform rendering?
|