Skip to content

Broken characters with FreeSerif and no hinting #18252

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
QuLogic opened this issue Aug 14, 2020 · 4 comments
Closed

Broken characters with FreeSerif and no hinting #18252

QuLogic opened this issue Aug 14, 2020 · 4 comments
Labels
status: upstream fix required topic: text/fonts

Comments

@QuLogic
Copy link
Member

QuLogic commented Aug 14, 2020

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')

ttconv_transforms

Originally posted by @jkseppan in #18081 (comment)
@QuLogic
Copy link
Member Author

QuLogic commented Aug 14, 2020 •
edited
Loading

Here is the correct output from a followup comment in that PR, produced by a PDF:

png

@jkseppan
Copy link
Member

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.)

    <TTGlyph name="arrowdbldown" xMin="21" yMin="-195" xMax="527" yMax="646">
      <component glyphName="arrowdblleft" x="532" y="-224" scalex="0.0" scale01="1.0" scale10="-1.0" scaley="0.0" flags="0x1004"/>
    </TTGlyph>

    <TTGlyph name="arrowdblleft" xMin="30" yMin="5" xMax="870" yMax="510">
      <contour>
        <pt x="870" y="127" on="1"/>
        <pt x="223" y="127" on="1"/>
        <pt x="299" y="34" on="1"/>
        <pt x="271" y="5" on="1"/>
        <pt x="30" y="257" on="1"/>
        <pt x="271" y="510" on="1"/>
        <pt x="299" y="479" on="1"/>
        <pt x="223" y="386" on="1"/>
        <pt x="870" y="386" on="1"/>
        <pt x="870" y="330" on="1"/>
        <pt x="176" y="330" on="1"/>
        <pt x="115" y="256" on="1"/>
        <pt x="175" y="183" on="1"/>
        <pt x="870" y="183" on="1"/>
      </contour>
      <instructions/>
    </TTGlyph>

    <TTGlyph name="arrowdblright" xMin="30" yMin="3" xMax="870" yMax="508">
      <component glyphName="arrowdblleft" x="900" y="513" scale="-1.0" flags="0x1004"/>
    </TTGlyph>

    <TTGlyph name="arrowdblup" xMin="23" yMin="-131" xMax="529" yMax="710">
      <component glyphName="arrowdblleft" x="18" y="740" scalex="0.0" scale01="-1.0" scale10="1.0" scaley="0.0" flags="0x1004"/>
    </TTGlyph>

@anntzer
Copy link
Contributor

anntzer commented Aug 14, 2020 •
edited
Loading

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 force rcParams["text.hinting_factor"] = 1 when 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
Copy link
Contributor

anntzer commented 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.

@anntzer anntzer closed this as completed Aug 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: upstream fix required topic: text/fonts
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jkseppan @QuLogic @anntzer