Repository navigation
Missing character upon savefig() with Free Serif font #17197
Description
Bug report
Bug summary
Choosing the font "Free Serif".
Right parenthesis character ")" is not printed upon using fig.savefig().
It is correctly printed upon using plt.show().
Code for reproduction
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
ax.text(s='(Some text)', x=0.5, y=0.5, fontname='freeserif')
fig.savefig('fig.pdf')Actual outcome
Right parenthesis is not printed on pdf.
Expected outcome
All characters should be printed on pdf.
Matplotlib version
- Operating system: Fedora 31 Workstation
- Matplotlib version: 3.2.1
- Python version: 3.7.6
Activity
anntzer commented on Apr 20, 2020
fwiw I cannot repro this locally: out.pdf
QuLogic commented on Apr 20, 2020
I can reproduce on Fedora 30; maybe the font was old?
QuLogic commented on Apr 20, 2020
Or not, because the font hasn't been touched in ages. TTF vs OTF, maybe?
QuLogic commented on Apr 20, 2020
In Inkscape, the closing parenthesis is there, but in evince, it's invisible. In okular, it's even weirder:
anntzer commented on Apr 20, 2020
Arch provides an otf file (and I was using mpl's pdf backend, not mplcairo).
fperonaci commented on Apr 20, 2020
Also with LibreOffice Draw it shows correctly.
Besides, even if the right parenthesis is invisible in Evince, I can copy paste it.
Could it be a problem of the pdf viewer and not at all of Matplotlib?
In this case should I close the issue?
anntzer commented on Apr 21, 2020
Can either of you post the failing file? I would suggest using figtext() instead of text to not include axes, so that there's as little text as possible in the pdf to simplify the troubleshooting.
fperonaci commented on Apr 21, 2020
Here is the output of the code below: fig.pdf
OS and Matplotlib version as in my original message.
anntzer commented on Apr 21, 2020
ok, I can repro now.
Looking at Fedora's FreeSerif.ttf (that's the difference, Arch ships an otf), I notice that the closing parenthesis appears(?) to be defined as the reflection of the opening parenthesis along a vertical axis, and a very wild guess would be that this reflection is somehow lost during font subsetting by ttconv -- a part of the codebase which I guess basically no one understands among the current devs...
jkseppan commented on Jul 27, 2020
I think you're right. When converting the ttf file to ttx format with fonttools, the parenleft program is
and the parenright program is
The corresponding charprocs in the pdf file are parenleft:
and parenright:
The only differences in the charproc outputs are in the d1 line (which I think is the bounding box) and the added q..Q stack push/pop sequence and the 1 0 0 1 333 499 cm operation. That operation translates the glyph by (333, 499) but the initial part is just the identity matrix, so the scale="-1.0" specification has been ignored. I suspect that the matrix should be -1 0 0 -1 333 499 instead.
Support scale in ttf composite glyphs
jkseppan commented on Jul 27, 2020
I think the linked #18081 should fix this. If anyone with a good collection of ttf fonts and an eye for detail is interested in testing that, please do.
Support scale in ttf composite glyphs