Imagefont logic does not remove spacer color

Issue #57 resolved
Anonymous created an issue

When creating an imagefont, the spacer color is not removed from the image. There is code to do this, but it is applied to the wrong data. The following test case will demonstrate the issue. Initialize the data with this code.



id = love.image.newImageData("imagefont.png") image = font =, "1234") image2 =


When I displayed image and image2 in the draw callback, I saw that image2 had had the spacer color removed and replaced by transparency, but image had not. This implies the code to replace the color is applied to the imagedata, but does not affect the image.

The spacer color is also not removed when loading an imagefont directly from file. To see this, simply create a suitable imagefont file and include the spacer color in the middle of a font glyph subimage. It should not become transparent, as it did not do so for me.

Comments (6)

  1. Anonymous

    This code and the sample image font file from the Wiki will demonstrate the problem just fine. You will see that the two images derived from the same imagedata do not agree. The first one keeps the yellow spacer color and it bleeds into the glyphs when is called with scaling factor of two. The second image is converted from the iamgedata after the newImageFont call, and it does not have the spacer color. This rather strongly implies that Löve removes the spacer color from the imagedata object and not the actual image that is used for the font.

    Save the image in this wiki page as imagefont.png for this program to access:

    id = love.image.newImageData("imagefont.png")
    image =
    font =,
    	" abcdefghijklmnopqrstuvwxyz" ..
    image2 =
    function love.draw(), 10, 10), 10, 110)"YELLOW BARS", 10, 210, 2, 2)
  2. the_leg

    This happens because love doesn't regenerate the OpenGL texture after it replaces the spacer pixels. I'm attaching a patch which resolves this. You might have a better way of accomplishing the same thing, just wanted to share my findings. This is for 0.62. I didn't have this issue in the tip release.

  3. Log in to comment