Bug 335058 - PDF Text hinting does not work for embedded otf fonts (CID Type 0C), does work for truetype.
Summary: PDF Text hinting does not work for embedded otf fonts (CID Type 0C), does wor...
Status: RESOLVED UPSTREAM
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: 0.18.5
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-20 01:42 UTC by Jerome
Modified: 2017-04-24 17:34 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
repro pdf (10.21 KB, application/octet-stream)
2014-05-20 01:42 UTC, Jerome
Details
screenshot of rendering issue (9.10 KB, image/png)
2014-05-20 01:43 UTC, Jerome
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jerome 2014-05-20 01:42:01 UTC
I've created a pdf file with XeLatex that includes two versions of the libre TeX Gyre Pagella font,
one version is taken from an original otf file and the other is a ttf file generated from that otf file 
using fontforge, each version of the font is used to render one line of text. 
The line corresponding to the otf font is not hinted - easily seen visually when zooming out. Toggling hinting in the preferences has no effect either. The line rendered using the truetype version 
renders fine, and toggling the hinting in the preferences has a noticable effect.

As I mention in additional info, this also happens with evince and other viewers, but
not acrobat reader. If it's not an okular issue, please point out the right project
to contact about this if possible.

If I can figure out how to attach files to this issue, I've got a screenshot and a pdf for repro.


Reproducible: Always

Steps to Reproduce:
1. open the enclosed pdf in okular
2. zoom out sufficiently so the type is small (fit to page on a 20" monitor works)

Actual Results:  
Notice the first line (otf) is quite dark while the lower line is crisp
toggle text hinting in the preferences and note how the upper row is unaffected
while the lower row goes back and forth between nice and not that nice.

Expected Results:  
I expected the two lines to exchibit marginal diffeence visually.

I've looked at the following:
- It's not an issue with TeX Gyre Pagella, I originally saw this with another unrelated font.
- I don't think the fontforge conversion process plays a part, since the output renders *better*
then the original and In any case i've also tried hinting the otf file directly with Adobe's FDK,
with no changes. The fact that toggling hinting in the preferences has no effect also suggests
the conversion didn't "fix" the font.
- I've looked through my fontconfig files (/etc/fonts, ~/.fonts.conf,~/.config/fontconfig/fonts.conf)
and while there's some hinting toggles there, there's nothing I've seen which could account
for the difference specifically between otf and ttf files, and I'd expect okular's preferences to
override these anyway if fontconfig plays a part at all.
- Adobe acrobat reader doesn't have this issue. *But* evince has the same issue
and so does an embedded viewer in another linux program.

Environment
===
This manifests on an updated fedora 20 x86-64 system, which contains the 0.18.5 version
of okular. I've also compiled and tested this on current git master (268aa60) with the same
problem manifesting.
Comment 1 Jerome 2014-05-20 01:42:59 UTC
Created attachment 86720 [details]
repro pdf
Comment 2 Jerome 2014-05-20 01:43:38 UTC
Created attachment 86721 [details]
screenshot of rendering issue
Comment 3 Albert Astals Cid 2014-05-20 21:17:26 UTC
We don't do rendering of pdf, poppler does, pelase report this upstream at https://bugs.freedesktop.org/
Comment 4 Jerome 2014-05-20 22:07:09 UTC
Opened https://bugs.freedesktop.org/show_bug.cgi?id=78990
Comment 5 Jerome 2014-06-07 10:20:27 UTC
Just updating the developers, that the poppler developers pointed out an issue 
in freetype's use of a new font hinting engine contributed by Adobe 
which has a  feature called "stem darkening". It appears it's on by default
and that the default values interact badly with how poppler does rendering (In a way
I do no understand).

The freetype developers have confirmed the issue.

There is a runtime option for freetype that allows you to turn off stem darkening,
and by using it in poppler I was able to eliminate (practically) the problem.

I'd like to suggest that the okular developers track this, and would be glad to see 
it handled in a coming release by whatever form the solution takes.