Created attachment 99453 [details] repro pdf Moved here from the okular/KDE bugtracker: https://bugs.kde.org/show_bug.cgi?id=335058 Description === The attached pdf was created using XeLatex and includes two versions of the same font, one taken from the original otf and the second from a ttf file converted from the original using fontforge. Viewing this pdf in okular/evince on my system reuslts in the otf embedded font CID type 0c) not being hinted regardless of settings, while the ttf font is hinted by default (and responds to hinting toggled in okular). I've seen the same with at least one other font, the problem does not occur with adobe acorbat reader and the okular guys pointed out that all rendering is handled by poppler. I'm attaching a screenshot and the pdf. Environment === This manifests on an updated fedora 20 x86-64 system, which contains the 0.18.5 version of okular and poppler 0.24.3. The same problem occurs in evince.
Created attachment 99454 [details] screenshot
Created attachment 99456 [details] Corrected pdf example The previous pdf embedded the wrong font, ignore.
I've uploaded a corrected PDF as there was a mixup with the fonts I used for the example. In brief, the two fonts should render identically, and do when zoomed in close enough. However when viewed so the type is small one renders much darker then the other, and the differece seems only to be that one is embedded as truetype and the other as CID.
> I've uploaded a corrected PDF as there was a mixup with the fonts I used > for the example. I’m interacting with bz via email, and missed the additional comments, including that update, when I first replied. Appologies. b> In brief, the two fonts should render identically, and do when zoomed b> in close enough. There is no such thing as identical hinting between CFF and glyf fonts. How did you generate the instructions for the glyf (aka ttf)? Fontforge? Ttfautohint? By hand? I see that the metrics are different. Did you lose kerning? I expect a pdf viewer to disable all hinting for the rendered page. AFAIK evince follows that philosophy. But if not, freetype added a new hinting engine in that last year, contributed by Adobe, which darkens glyphs at low resolutions. Perhaps that explains what you see? Or, the difference between how cubic and quadratic splines render might be noticible at those p/ex sizes.
> There is no such thing as identical hinting between CFF and glyf fonts. Point taken. I'll rephrase to: They should render similarly enough so it doesn't appear as if one is black and the other regular at low zoom if they render identically when zommed in. > How did you generate the instructions for the glyf (aka ttf)? Fontforge? > Ttfautohint? By hand? I've tried: - straight otf->ttf via fontforge - running ttfauthint on the ttf - converting the results of ttfauthint back into otf via fontforge - running authint from the adobe FDK on the otf. and comapring against each other. It gets a little tricky (XeLatex and fontconfig have a will of their own) but so far the rendering is consistently different between otf and ttf, and so far it's by far the dominating factor in the appearence of the rendered page. > I see that the metrics are different. Did you lose kerning? You probably meant the faulty pdf. The answer is still: possibly, I didn't check (I'm a fontforge novice). Though kerning can affect color the difference in visual appearence looks to me as being on the level of individual glyphs. Since the difference disappears when zooming in, I took that as a hint (pardon) that the issue has to do with hinting, but perhaps it's something else I'm unaware of. The "mistaken" screenshot is actually quite close to the weight difference I'm seeing, even with the wrong fonts (still otf vs. ttf rendering). >I expect a pdf viewer to disable all hinting for the rendered page. >AFAIK evince follows that philosophy. But if not, freetype added a new >hinting engine in that last year, contributed by Adobe, which darkens >glyphs at low resolutions. Perhaps that explains what you see? Using okular, I've disabled hinting (which does make a slight visual difference) but the prononounced effect I described remains. otf is black ttf is regular. Wouldn't you expect it to act similarly on both fonts? it's really not a subtle visual difference I'm seeing. > Or, the difference between how cubic and quadratic splines render might > be noticible at those p/ex sizes. You got me there. You're refering to a difference in how the glyph curves are represented in each font format? Doesn't the fact that acrobat reader doesn't have this issue suggest otherwise? Is there a way to tell if it's patented magic on behalf of adobe or a bug in poppler's rendering (or somewhere else in the stack)? I'm attached a new screenshot of the appearence of the pdf zoomed out and close up taken from okular. evince looks much the same.
Created attachment 99467 [details] Screenshots from okular with differing zoom factors
[This went to the list instead of to bz -JimC] That new screenshot confirms that the metrics changed. pdftocairo and pdftoppm also exibit the anomaly. mudraw does not seem to. All use freetype to render the fonts. But using ftview on the two fonts also shows the cff font darker than that glyf version. Unless both are rendered with forced auto hinting. That strongly suggests that it is a freetype issue. Try the full fonts side by side in ftview, comparing the hinting modes and gama. Either both in the same instance, using n and p to switch between them, or each in its own ftview.
Created attachment 99600 [details] Comparing ttf and otf using ftview - note engine difference
I have and I can confirm the freetype renders the ttf and otf files differently. You previously mentioned that Adobe contributed a rendering engine to freetype and indeed ftview shows that different engines are used to render different fonts by type, I attached a screenshot. Many thanks for helping to narrow down the issue. I'll open a ticket on the freetype tracker.
Freetype ticket: https://savannah.nongnu.org/bugs/index.php?42406
Retitled issue. Was: "PDF Text hinting does not work for embedded otf fonts (CID Type 0C), does work for truetype."
Created attachment 100597 [details] Rendering of cff vs. ttf with FT2 No_Stem_Darkening = True
The freetype devs confirme that the stem darkening used by the adobe engine is the cause of the overly dark rendering of cff fonts I reported. See issue: https://savannah.nongnu.org/bugs/index.php?42406 Stem darkening is turned on by default, and assumes (As I understand it) that poppler properly handles "gamma", whatever that means in this context, which if not done has the effect of displaying very dark glyphs at small type size. The freetype library has an option for disabling stem darkening, as well as several numerical parameters for controlling it, whose defaults the FT devs plan to change in the future when stem darkening will be added to the other (ttf) engine as well. See: http://www.freetype.org/freetype2/docs/reference/ft2-cff_driver.html#FT_CFF_HINTING_XXX By turning off stem darkening in the constructor for CairoOutputDev (And also in splash hinting control, I do not know which had the effect): ``` CairoOutputDev::CairoOutputDev() { ... FT_Bool no_stem_darkening = true; FT_Property_Set( ft_lib, "cff", "no-stem-darkening", &no_stem_darkening ); ``` the issue has largely been resolved for me, there's still a slight difference perhaps, but only when comparing side to side. I've attached a screenshot which you can compare to the original I attached to the issue. I'd like to suggest that poppler turn stem darkening off by default, since it would: 1) Eliminate the problem of the dark glyphs. 2) Make ttf and ctf render in the same way (if they are mixed in a document for example). 3) Restore (roughly) the rendering behavior to what it was been before the relatively recent introduction of the adobe engine. If not, at least exposing an API for setting it by clients (Evince, okular) would enable downstream to scratch their own itch. Noting that since freetype releases are not often and this part of the library seems to be in an interim state since one kind of font supports darkening it, the other does not, it might be a while before this is resolved over there (though they were very helpful).
I also came across this issue, when mixing LaTeX Math fonts (type1) with OTF text fonts. I think the correct way to disable stem darkening is in the splash FT engine. I attached a small patch for poppler git head to this bug.
Created attachment 117464 [details] [review] disable stem darkening
using freetype 2.5.2 as shipped in ubuntu i don't ever see any difference in the rendering of the two lines of https://bugs.freedesktop.org/attachment.cgi?id=99456 and using ./qt4/demos/poppler_qt4viewer at any zoom. Do i need a newer freetype to see the difference?
Interesting little note: MuPDF does render the pdf example as expected here, using the system freetype library as poppler does. I also did not find any special handling of stem darkening in the mupdf sources. So does poppler try to improve contrast by playing with gamma values? The freetype people seem to call this "misusing" the library.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/402.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.