<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Issue with text hinting of integral signs and parentheses" href="https://bugs.freedesktop.org/show_bug.cgi?id=91772#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Issue with text hinting of integral signs and parentheses" href="https://bugs.freedesktop.org/show_bug.cgi?id=91772">bug 91772</a> from <a class="email" href="mailto:philipp-dev@knechtges.com" title="Philipp Knechtges <philipp-dev@knechtges.com>"> Philipp Knechtges</a> <pre>Created <a href="attachment.cgi?id=118002" name="attach_118002" title="Comparison of freetype's autohinting vs the Adobe CFF hinting engine">attachment 118002</a> <a href="attachment.cgi?id=118002&action=edit" title="Comparison of freetype's autohinting vs the Adobe CFF hinting engine">[details]</a> 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] <a href="http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_LOAD_XXX">http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_LOAD_XXX</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>