Offset Text Stroke in Linux

[FormerLurker]

First, thank you for creating such an awesome library! Also, I LOVE the new text stroking function! My workarounds to implement this in previous versions were vastly inferior to the new functionality you added! Bravo!

However, I am seeing a slight issue with the stroking. It appears to be offset when running on linux. I've only tried one version of linux (outlined below). The same code works as expected in windows (as illustrated below).

What did you do?

I tried to add a text overlay with stroking to an image.

What did you expect to happen?

The text stroking would appear, and not be offset.

What actually happened?

The text stroking was offset, making the stroke appear to be a shadow. See this image generated from my stand alone sample:

However, when using windows, I do not see the issue. Here is another overlay done with windows using the same program:

Here the outlines are crisp and not offset.

What are your OS, Python and Pillow versions?

• OS: Raspbian GNU/Linux Version 9 (stretch)
• Python: 2.7 & 3.7 (I haven't tried any other versions)
• Pillow: 6.2.2

from PIL import Image, ImageDraw, ImageFont

def create_overlay(font_path):
    image_color = (128,128,128,255)
    # Create an image with background color inverse to the text color.
    image = Image.new('RGB', (640, 480), color=image_color)
    text = "Sample Overlay Text"
    text_color_tuple = 255,255,255,255
    outline_color_tuple = 0,0,0,255
    font = ImageFont.truetype(font_path, size=48)

    # Create the image to draw on.
    text_image = Image.new('RGBA', image.size, (255, 255, 255, 0))
    d = ImageDraw.Draw(text_image)
    # overlay location
    x, y = 0, 0

    # Draw overlay text.
    d.multiline_text(
        xy=(x, y),
        text=text,
        fill=text_color_tuple,
        font=font,
        align='left',
        stroke_width=2,
        stroke_fill=outline_color_tuple

    )
    return Image.alpha_composite(image.convert('RGBA'), text_image).convert('RGB')

if __name__ == '__main__':
    image = create_overlay('/home/pi/fonts/DejaVu/DejaVuSansMono.ttf')
    image.save("/home/pi/temp.jpg")

Obviously you will need to adjust the font location and the save location to get this to work, but it shouldn't require much modification. Please let me know if you need a better sample, or any additional information.

Thanks!

[radarhere]

What freetype versions are you using on the different environments? A simple reason for the difference might be different versions.

from PIL import ImageFont
print(ImageFont.core.freetype2_version)

[FormerLurker]

The version is 2.6.3

Here is the pillow install requirement in my setup.py: pillow >=6.2.0<7.0.0

Edit: This is on the Raspbian GNU/Linux Version 9 (stretch), will add the version from windows next.. Sorry, it slipped my mind.

[FormerLurker]

On windows it's 2.10.1... Hmm.. How can I ensure this subpackage (ImageFont) is installed with the correct version? I had kind of (probably naively) assumed that these would be upgraded as well during the Pillow upgrade..

[FormerLurker]

So, I tried upgrading libfreetype6-dev, but I got the following message: libfreetype6-dev is already the newest version (2.6.3-3.2).

Uninstalling and re-installing pillow also did not change the libfreetype version, but I guess that was expected. I the stroking feature simply not compatible with stretch?

[radarhere]

Testing with freetype 2.6.3 on Stretch, I was able to replicate the problem. Testing with 2.9.1 on Buster, it works, so that does seem to be the cause.

How are you installing Pillow? To try and be helpful, one option would be to try installing from binary. If you're comfortable, another option would be to try installing the latest freetype from source.

[radarhere]

I've created PR #4401 to resolve this, so that Pillow will be able to work with FreeType on Stretch.

[FormerLurker]

You are a hero! Thanks so much, and I must apologize that I missed your message from 8 days ago somehow. I would have been 100% willing to install pillow in the way you are describing, but it looks like your PR takes care of this. I will watch for the PR to be merged, and will create a new issue if I find any problems.

Again, thank you so much!