Created attachment 117947 [details] Text hinting fails for integral signs I am currently facing the issue that an Elsevier-provided pdf of a publication of mine is not correctly rendered in Okular if text hinting is enabled (cf attachment). The corresponding pdf can be retrieved from http://authors.elsevier.com/a/1RQJJ1LkSZq5VP until September, 12 (afterwards, it will unfortunately be hidden behind a paywall). Further testing with qpdfview and poppler_qt5viewer unveil that it seems to be related to the text hinting done in the Splash backend, since rendering without text hinting, as well as the Arthur backend, give reasonably scaled integral signs and parentheses. Evince and the used cairo backend do not seem to have this issue. All tests have been performed with latest release 0.35.
That's the rendering you get on page 2 (aka 210)? Seems to work fine for me http://i.imgur.com/ZBGGxfT.png
Hi Albert, thx for the quick reply. > That's the rendering you get on page 2 (aka 210)? Yes that's right. > Seems to work fine for me http://i.imgur.com/ZBGGxfT.png Sry, I should have clarified this point a bit more. For poppler_qt5viewer I added m_doc->setRenderHint(Poppler::Document::TextHinting, true); to PdfViewer::loadDocument in order to turn on text hinting. In Okular and qpdfview there are runtime options available to do that.
Ah, i see what you mean, may be a freetype bug, but honestly since hinting is kind of disabled by default i don't have too much time to investigate it.
Created attachment 118002 [details] Comparison of freetype's autohinting vs the Adobe CFF hinting engine After using mupdf's "mutool extract" to extract the used fonts and looking at them with freetype's ftview tool, the problem can indeed be boiled down to an issue in freetype's autohinter (cf. the attached screenshot). The integral signs, which corresponds to the unicode character 'Z' in the font AdvP4C4E46, and many other characters are not scaled correctly in the hinting process, if autohinting is turned on. In fact, this is a known issue according to the freetype documentation [1]: > Note that the auto-hinter needs a valid Unicode cmap (either a native one or > synthesized by FreeType) for producing correct results. If a font provides an > incorrect mapping (for example, assigning the character code U+005A, LATIN > CAPITAL LETTER Z, to a glyph depicting a mathematical integral sign), the > auto-hinter might produce useless results. I guess the conclusion from this analysis is twofold: Firstly, one could consider to include the font in a list of 'tricky' fonts for which the autohinter is just not applied. The latter seems to already exist in freetype for TrueType fonts, but not for Type 1C or CFF fonts. Secondly, the logic in SplashFTFont.cc:getFTLoadFlags probably needs to be overhauled. E.g., for Type 1 fonts hinting always results in the inclusion of the FT_LOAD_TARGET_LIGHT flag. Unfortunately, this flag seems to be a misnomer, since according to the documentation it always implies autohinting. If I'm reading the logic in getFTLoadFlags correctly, this means that one either gets autohinting or no hinting at all, but never the shiny, new and highly advertised CFF hinting engine in freetype provided by Adobe. I haven't had the time yet to look into a possible patch, but maybe somebody else sees a clever way to solve this :) [1] http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_LOAD_XXX
Created attachment 118132 [details] [review] patch This is a possible fix. It basically now lets freetype decide which hinting engine to choose. Slight hinting now means that autohinting is explicitly turned off. Thx for consideration.
-- 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/403.
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.