Description

fperonaci

opened on Apr 20, 2020

Issue body actions

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

Reacted by Iury Simoes-Sousa

Activity

1. anntzer commented on Apr 20, 2020

   

   anntzer

   on Apr 20, 2020

   Contributor

   More actions

   fwiw I cannot repro this locally: out.pdf
2. anntzer

   added

   backend: pdf

   status: needs confirmation

   on Apr 20, 2020
3. QuLogic commented on Apr 20, 2020

   

   QuLogic

   on Apr 20, 2020

   Member

   More actions

   I can reproduce on Fedora 30; maybe the font was old?
4. QuLogic commented on Apr 20, 2020

   

   QuLogic

   on Apr 20, 2020

   Member

   More actions

   Or not, because the font hasn't been touched in ages. TTF vs OTF, maybe?
5. QuLogic commented on Apr 20, 2020

   

   QuLogic

   on Apr 20, 2020

   Member

   More actions

   In Inkscape, the closing parenthesis is there, but in evince, it's invisible. In okular, it's even weirder:
   
6. anntzer commented on Apr 20, 2020

   

   anntzer

   on Apr 20, 2020

   Contributor

   More actions

   Arch provides an otf file (and I was using mpl's pdf backend, not mplcairo).
7. fperonaci commented on Apr 20, 2020

   

   fperonaci

   on Apr 20, 2020

   Author

   More actions

   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?
8. anntzer commented on Apr 21, 2020

   

   anntzer

   on Apr 21, 2020

   Contributor

   More actions

   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.
9. fperonaci commented on Apr 21, 2020

   

   fperonaci

   on Apr 21, 2020

   Author

   More actions

   Here is the output of the code below: fig.pdf
   OS and Matplotlib version as in my original message.

   import matplotlib.pyplot as plt
   fig = plt.figure(figsize=(2,2))
   fig.text(s='(Some text)', x=0.5, y=0.5, fontname='freeserif')
   fig.savefig('fig.pdf')
10. anntzer commented on Apr 21, 2020

    

    anntzer

    on Apr 21, 2020

    Contributor

    More actions

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

    Reacted by Iury Simoes-Sousa
11. anntzer

    added

    Difficulty: Hardhttps://matplotlib.org/devdocs/devel/contribute.html#good-first-issueshttps://matplotlib.org/devdocs/devel/contribute.html#good-first-issues

    and removed

    status: needs confirmation

    on Apr 21, 2020
12. jkseppan commented on Jul 27, 2020

    

    jkseppan

    on Jul 27, 2020

    Member

    More actions

    I think you're right. When converting the ttf file to ttx format with fonttools, the parenleft program is

        <TTGlyph name="parenleft" xMin="48" yMin="-177" xMax="304" yMax="676">
          <contour>
            <pt x="292" y="-177" on="1"/>
            <pt x="266" y="-161" on="0"/>
                 ...
            <pt x="304" y="-161" on="1"/>
          </contour>
          <instructions/>
        </TTGlyph>

    and the parenright program is

        <TTGlyph name="parenright" xMin="29" yMin="-177" xMax="285" yMax="676">
          <component glyphName="parenleft" x="333" y="499" scale="-1.0" flags="0x1004"/>
        </TTGlyph>

    The corresponding charprocs in the pdf file are parenleft:

    333 0 48 -176 304 676 d1
    292 -176 m
    274 -165 256 -152 238 -137 c
    ...
    292 -176 l
    f

    and parenright:

    333 0 29 -176 285 676 d1
    q 1 0 0 1 333 499 cm
    292 -176 m
    274 -165 256 -152 238 -137 c
    ...
    292 -176 l
    f
    Q

    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.
13. jkseppan

    added a commit that references this issue on Jul 27, 2020

    Support scale in ttf composite glyphs

    This issue will close once commit 5b2f6fb is merged into the 'main' branch.

    5b2f6fb
14. jkseppan commented on Jul 27, 2020

    

    jkseppan

    on Jul 27, 2020

    Member

    More actions

    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.
15. jkseppan

    added a commit that references this issue on Aug 1, 2020

    Support scale in ttf composite glyphs

    This issue will close once commit 00fe329 is merged into the 'main' branch.

    00fe329
16. jklymak

    closed this as completedin #18181on Aug 13, 2020
17. QuLogic

    added this to the v3.4.0 milestone on Aug 13, 2020

Issue actions