Truetype fonts not being rendered correctly with the TEXT method #4177

Activity

1. radarhere

   added

   Linux

   on Oct 29, 2019
2. radarhere

   changed the title [-]Italic true type fonts not being rendered correctly with the TEXT method[/-] [+]Italic truetype fonts not being rendered correctly with the TEXT method[/+] on Oct 29, 2019
3. ADBeasley

   changed the title [-]Italic truetype fonts not being rendered correctly with the TEXT method[/-] [+]Truetype fonts not being rendered correctly with the TEXT method[/+] on Oct 29, 2019
4. ADBeasley commented on Oct 29, 2019

   

   ADBeasley

   on Oct 29, 2019

   Last edited by ADBeasley

   Author

   More actions

   Have now discovered that:

   1. It is not only Italic fonts (can reproduce on various 'light' fonts)
   2. The range of ending positions is not limited to 110 Pixels - I now have one at 129 pixels
5. BeauSlim commented on Nov 5, 2019

   

   BeauSlim

   on Nov 5, 2019

   More actions

   I can replicate this error on macOS with updated libs. I've seen issues similar to this using Pillow to render text for little 1-bit OLED displays.
   It looks like Pillow is using fontmode='1' since you have chosen mode 'P'.
   What happens if you use 'L' or 'RGB' instead of 'P'?
   If you add screen_image.fontmode='L' before rendering text does the problem go away?
   This may be related to #2293 (i.e. it may be a libfreetype problem).
6. ADBeasley commented on Nov 9, 2019

   

   ADBeasley

   on Nov 9, 2019 via email

   Last edited by radarhere

   Author

   More actions

   Apologies for the delay. I had to go live with the quirks (padded the text with spaces) and not had another machine I can test on. I've got a Pi Zero now but no screen (and no money to buy one) but will try in the next week to get it set up as per the live box (I do still have the build document :-)) and test it. I have a hospital appointment on Monday - not sue if they will be keeping me in or not so I may not get back to you for a week or so. Andrew
7. radarhere commented on May 21, 2020

   

   radarhere

   on May 21, 2020

   Member

   More actions

   @BeauSlim I'm not able to replicate this on my macOS machine. Are you still able to?
8. radarhere

   removed

   Linux

   on May 21, 2020
9. BeauSlim commented on May 25, 2020

   

   BeauSlim

   on May 25, 2020

   More actions

   I'm not able to replicate this on my macOS machine. Are you still able to?

   Yes. ADBeasley's posted code produces exactly the same image as above on my macOS Catalina machine with Pillow 7.1.2 under brew's Python 3.7.7.

   I played with it a bit. If you manually set screen_image.fontmode='P' the text isn't clipped, so maybe it comes down to the old fontmode '1' problem? And it appears that #2293 is not related to an outdated FreeType library since ImageFont.core.freetype2_version gives me 2.10.1 and I am still getting problems with vertical alignment with mode '1' TTF text:

   

   I ended up converting the fonts I wanted into .bdf format to solve this, so no big deal, but it definitely points to a bug somewhere.
10. nulano commented on May 25, 2020

    

    nulano

    on May 25, 2020

    Last edited by nulano

    Contributor

    More actions

    I can actually reproduce #2293 with 7.1.1 from PyPI on Windows 10 using verdanab.ttf (not verdana.ttf). I will comment here, as the other issue is closed. I have a pretty good idea of what might be causing this, I will investigate more when I get more time. The issue happens with all four combinations, both layout_engine RAQM and BASIC, as well as fontmode 1 and L. It is hard to see on L due to the thicker symbols, but the digit 0 is actually clipped at the top, indicating that this is clearly a bug. Additionally, all symbols in that font have atrocious kerning (I suspect this part of the problem):

    

    My WIP branch (#4553) doesn't have these issues, although I'm not sure it is perfect either.
    Edit: The poor hinting is fixed in the new PR.

    

    from PIL import Image, ImageDraw, ImageFont
    im = Image.new("RGB", (400, 100), "white")
    d = ImageDraw.Draw(im)
    def line(y, engine, mode):
        f = ImageFont.truetype("verdanab.ttf", 13, layout_engine=engine)
        d.fontmode = mode
        d.text((10, y), "engine: {}, mode: {}".format(engine, mode), "black", f)
        d.text((170, y), "01234567890123456789", "black", f)
    line(10, 0, '1')  # 0 is basic layout
    line(30, 0, 'L')
    line(50, 1, '1')  # 1 is raqm layout
    line(70, 1, 'L')

    Edit: Corrected images.
11. nulano commented on May 25, 2020

    

    nulano

    on May 25, 2020

    Last edited by nulano

    Contributor

    More actions

    I just realized that I forgot to actually test this bug specifically; I can reproduce this issue with both 7.1.1 and my WIP branch, getting practically the same images as OP. Note that it only happens with Basic layout.
12. nulano commented on May 27, 2020

    

    nulano

    on May 27, 2020

    Last edited by nulano

    Contributor

    More actions

    I solved this one. The problems is that getsize is called without the mode parameter, thus performing layout with FT_LOAD_TARGET_NORMAL instead of FT_LOAD_TARGET_MONO hinting. The different hinting algorithms can in some circumstances give different results causing this bug.

    Raqm layout always uses FT_LOAD_TARGET_NORMAL hinting for layout, this error doesn't accumulate and in the worst case only one pixel is clipped. Raqm doesn't do hinting during layout, only rendering. Hinting can nudge glyphs at most one pixel which may be clipped.

    👍React with 👍1Reacted by Hugo van Kemenade
13. hugovk

    closed this as completedin #4664on Jun 21, 2020
14. aclark4life

    added

    PNG

    on Oct 8, 2026