We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 254

Summary: TTF_RenderUNICODE_Solid fails when rendering strings containing spaces
Product: SDL_ttf Reporter: Sam Lantinga <slouken>
Component: miscAssignee: Sam Lantinga <slouken>
Status: RESOLVED INVALID QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: bernard, phaethon-33f5024c, vapier
Version: unspecified   
Hardware: x86   
OS: Linux   
URL: http://bugs.debian.org/374062
Attachments: main.c
font.ttf

Description Sam Lantinga 2006-06-20 02:03:48 UTC 
From: "C Rodrigues"
Subject: TTF_RenderUNICODE_Solid fails when rendering strings containing spaces
Date: Sat, 17 Jun 2006 01:44:29 +0000

Package: libsdl-ttf2.0-0
Version: 2.0.8-2

libfreetype6 version 2.2.1-2
libsdl1.2debian version 1.2.10-3

When attempting to render a string containing spaces using 
TTF_RenderUTF8_Solid(), rendering fails and NULL is returned.  Rendering is 
successful when the string contains no spaces.  Rendering is successful with 
TTF_RenderUTF8_Blended() or TTF_RenderUTF8_Shaded().  The failure appears to 
be independent of the choice of font.  The included file and font 
demonstrate the problem.  It was compiled with

gcc main.c -lSDL_ttf -lSDL

I investigated the problem further using the source package.  When running 
the program provided, an error code is returned by the call to Find_Glyph in 
TTF_RenderUNICODE_Solid at approximately line 1080 of SDL_ttf.c.  This error 
does not seem to occur if the third argument to Find_Glyph is changed to be 
CACHED_METRICS|CACHED_PIXMAP instead of CACHED_METRICS|CACHED_BITMAP.  I do 
not know if such a change affects the expected rendered image.

I discovered this problem because it causes some pygame code to raise 
exceptions.
Comment 1 Sam Lantinga 2006-06-20 02:04:50 UTC 
Created attachment 137 [details]
main.c
Comment 2 Sam Lantinga 2006-06-20 02:06:24 UTC 
Created attachment 138 [details]
font.ttf
Comment 3 Frederick Lee 2006-08-23 02:46:29 UTC 
I blame freetype.

I ran into this bug when I returned to working on a text-heavy pygame program.

With freetype 2.1.10 active (via LD_LIBRARY_PATH), bug does not occur; with freetype 2.2.1 active, the bug occurs.  Many many printf()'s led me to a one-line change in freetype/src/raster/ftrend1.c:178 between v2.1.10 and v2.2.1.  In freetype-2.1.10 (no bug), this lines reads:

  if ( FT_ALLOC( bitmap->buffer, (FT_ULong)pitch * height ) )

and in freetype-2.2.1 (buggy), it reads:

  if ( FT_ALLOC_MULT( bitmap->buffer, pitch, height ) )

The space character (ASCII 32) yields pitch=0 height=0.  From what I can tell, FT_ALLOC_MULT leads to a realloc()-style call that flags 0-size resizes as an error in the name of security (src/base/ftutil.c:123), whereas FT_ALLOC leads to a simple alloc()-style call which flags only negative sizes as a risk (src/base/ftutil.c:80).

I can't find a ready explanation for the DPMSDisable message, even though I suffer it myself.

A workaround for me was to always enable anti-aliasing, which apparently kicks in grayscale mode (instead of monochrome), and thus the 'smooth' renderer, which still uses the FT_ALLOC macro.
Comment 4 Mike Frysinger 2006-09-04 01:02:51 UTC 
this is def a freetype bug ... i just finished debugging this crap for Gentoo ;)

http://bugs.gentoo.org/142453
http://lists.gnu.org/archive/html/freetype/2006-07/msg00009.html

the freetype-2.2.1 release has this bug but latest cvs works for me ... so i'd just close this as 'INVALID:BUG_IN_FREETYPE'
Comment 5 Ryan C. Gordon 2007-02-03 03:29:38 UTC 
Closing as INVALID, bug in Freetype. The experts have spoken.  :)

Thanks to everyone that researched this!

--ryan.