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.
Created attachment 86720 [details] repro pdf
Created attachment 86721 [details] screenshot of rendering issue
We don't do rendering of pdf, poppler does, pelase report this upstream at https://bugs.freedesktop.org/
Opened https://bugs.freedesktop.org/show_bug.cgi?id=78990
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.