Repository navigation
Broken characters with FreeSerif and no hinting #18252
Description
The FreeSerif font produces strange output when hinting is disabled. This is not a default configuration (which is force_autohint), but is set when building tests.
import matplotlib.pyplot as plt
plt.rcParams['text.hinting'] = 'none' # 'force_autohint'
fig, ax = plt.subplots()
kw = {'font': 'freeserif', 'fontsize': 14}
# characters where Free Serif uses various scales and linear transforms
# e.g. the right paren is a reflected left paren
ax.text(.05, .1, "parens, FAX, u with two diacritics: ()℻ǘ", **kw)
ax.text(.05, .2, "double arrows LURD, single arrows LURD: ⇐⇑⇒⇓←↑→↓", **kw)
ax.text(.05, .3, "corner arrows, wreath product: ↴↵≀", **kw)
ax.set_xticks([])
ax.set_yticks([])
fig.savefig(f'hinting-{plt.rcParams["text.hinting"]}.png')
fig.savefig(f'hinting-{plt.rcParams["text.hinting"]}.pdf')
fig.savefig(f'hinting-{plt.rcParams["text.hinting"]}.svg')
Originally posted by @jkseppan in #18081 (comment)
Activity
QuLogic commentedon Aug 14, 2020
Here is the correct output from a followup comment in that PR, produced by a PDF:
jkseppan commentedon Aug 14, 2020
What the broken glyphs seem to have in common that they are composite glyphs where the original glyph has been rotated but not by 180 degrees. E.g. the double arrow left is the original character, the double arrow up has a scale matrix of [0 1; -1 0] and the double arrow down [0 -1; 1 0]. The double arrow right has just a single scale value of -1 and is rendered correctly. (See https://docs.microsoft.com/en-us/typography/opentype/spec/glyf, search for WE_HAVE_A_SCALE and WE_HAVE_A_TWO_BY_TWO.)
anntzer commentedon Aug 14, 2020
From a very quick look it appears that this is fixed by setting
rcParams["text.hinting_factor"] = 1(which I have argued elsewhere should be the only option anyways, but that'll require the baseline images PR first). In the meantime, however, it may be reasonable to just forcercParams["text.hinting_factor"] = 1when hinting is set to None? (we're not going to hint anyways, so no need to bother with scaling and unscaling)On the other hand it appears that the wide "℻" character also confuses the pdf backend: generating pdf output (with the same example) shows that that character overlaps with the preceding text; playing a bit shows that the overlap seems to depend on how much text there is before that character, with ℻ getting progressively "not enough to the right" compared to the rest of the text stream. At least from a low-level point of view, one can note that that character is indeed emitted "separately" from the rest of the characters, so that may make sense... Edit: actually this specific issue is separate, see #18282.
anntzer commentedon Aug 21, 2020
This turns out to be a bug in FreeType, see https://lists.nongnu.org/archive/html/freetype/2020-08/msg00004.html / https://savannah.nongnu.org/bugs/index.php?58990.
I would say we can close this as cantfix and track the removal of hinting_factor in #9681 and/or wait until FreeType makes a new release fixing that; in either case that'll require regen'ing all baselines and therefore this probably depends on the test baselines project.
Feel free to reopen if you disagree.