You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: unspecified Reported for operating system, platform: Linux, x86
Comments on the original bug report:
On 2006-06-20 02:03:48 +0000, Sam Lantinga wrote:
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.
On 2006-06-20 02:04:50 +0000, Sam Lantinga wrote:
Created attachment 137
main.c
On 2006-06-20 02:06:24 +0000, Sam Lantinga wrote:
Created attachment 138
font.ttf
On 2006-08-23 02:46:29 +0000, Frederick Lee wrote:
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.
On 2006-09-04 01:02:51 +0000, Mike Frysinger wrote:
this is def a freetype bug ... i just finished debugging this crap for Gentoo ;)
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Linux, x86
Comments on the original bug report:
On 2006-06-20 02:03:48 +0000, Sam Lantinga wrote:
On 2006-06-20 02:04:50 +0000, Sam Lantinga wrote:
On 2006-06-20 02:06:24 +0000, Sam Lantinga wrote:
On 2006-08-23 02:46:29 +0000, Frederick Lee wrote:
On 2006-09-04 01:02:51 +0000, Mike Frysinger wrote:
On 2007-02-03 03:29:38 +0000, Ryan C. Gordon wrote:
The text was updated successfully, but these errors were encountered: