Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TTF_RenderUNICODE_Solid fails when rendering strings containing spaces #6

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed
Labels
invalid This doesn't seem right

Comments

@SDLBugzilla
Copy link
Collaborator

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:

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 ;)

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'

On 2007-02-03 03:29:38 +0000, Ryan C. Gordon wrote:

Closing as INVALID, bug in Freetype. The experts have spoken. :)

Thanks to everyone that researched this!

--ryan.

@SDLBugzilla SDLBugzilla added bug invalid This doesn't seem right labels Feb 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

1 participant