This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Android (All), x86_64

Comments on the original bug report:

On 2014-06-15 11:08:23 +0000, wrote:

SDL update hg:8820(0e935d5b193a) triggers -Wformat-security warning in the SDL_ttf usage of SDL_SetError. This breaks the android NDK build, as it has a default -Werror=format-security flag set.

The default -Werror=format-security is set by [ANDROID-NDK]/build/core/build-binary.mk

A possible solution is disabling this -Werror flag, by setting LOCAL_DISABLE_FORMAT_STRING_CHECKS=true in a the [SDL_ttf]/Android.mk file.

This affects SDL_image, SDL_ttf.

Duplicate bug report for SDL_image: https://bugzilla.libsdl.org/show_bug.cgi?id=2586

Cheers,
Roald

Change-diff of fix:
diff -r 997babb2f547 Android.mk
--- a/Android.mk Sun May 11 11:20:09 2014 -0400
+++ b/Android.mk Sun Jun 15 13:07:43 2014 +0200
@@ -63,4 +63,6 @@

LOCAL_EXPORT_C_INCLUDES += $(LOCAL_C_INCLUDES)

+LOCAL_DISABLE_FORMAT_STRING_CHECKS=true
+
include $(BUILD_SHARED_LIBRARY)

On 2016-01-17 16:35:27 +0000, Philipp Wiesemann wrote:

This might have been fixed here (like in bug 2586):
https://hg.libsdl.org/SDL_ttf/rev/73118378dae8

On 2017-06-07 17:07:10 +0000, Ryan C. Gordon wrote:

Yeah, I think this got fixed a while ago.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch (non-scalable.patch, text/plain, 2014-06-05 23:15:03 +0000, 680 bytes)
• Font that used to load until 2.0.12 (vgasys.fon, application/x-ms-dos-executable, 2014-06-05 23:16:23 +0000, 6512 bytes)

Reported in version: 2.0.12
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2014-06-05 23:15:03 +0000, wrote:

Created attachment 1671
Patch

SDL_ttf used to load non-scalable fonts such as vgasys.fon (attached).

Test:
$ showfont vgasys.fon
Couldn't load 18 pt font from vgasys.fon: Couldn't set font size

With previous versions, or with attached fix (which reverts a 2.0.12 change):
$ showfont vgasys.fon
Font is generally 16 big, and string is 16 big

Please consider the attached patch for inclusion :)

On 2014-06-05 23:16:23 +0000, wrote:

Created attachment 1672
Font that used to load until 2.0.12

On 2014-06-05 23:18:21 +0000, wrote:

By the way, never mind the "application/x-ms-dos-executable" content-type from Mozilla, that's the normal headers for MS console fonts :/

On 2014-06-16 01:28:41 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL_ttf/rev/86aa91bce20c

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• main c file + hindi fonts (bug_ttf.tar.gz, application/x-gzip, 2013-01-12 14:31:10 +0000, 168787 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2013-01-12 14:31:10 +0000, Sylvain wrote:

Created attachment 1016
main c file + hindi fonts

When rendering some specific sequence of Hindi characters, the surface is created but there is memory corruption. it crashes when trying to do a FreeSurface.

It crashes with SDL 1.2 & 2.0, with the SDL_ttf-2.0.11 (not test with the lastest version of ttf). hope this is not a duplicate !

(on linux 64 bits)

Attached, a C file to reproduces the crashes + Hindi fonts.

On 2013-01-13 02:11:56 +0000, Sylvain wrote:

I closed it as it did not appear on the latest version of SDL_ttf,
sorry

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch by Tomi (see http://unclemion.com/onscripter/bug-reporting/comment-page-1/#comment-9027) (renderglyph_shaded.patch.txt, text/plain, 2012-02-27 21:18:57 +0000, 450 bytes)

Reported in version: 2.0.11
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2012-02-27 21:18:57 +0000, wrote:

Created attachment 830
Patch by Tomi (see http://unclemion.com/onscripter/bug-reporting/comment-page-1/#comment-9027)

As described at http://unclemion.com/onscripter/bug-reporting/comment-page-1/#comment-9027 onscripter-en displays blank space instead of font because of TTF_RenderGlyph_Shaded. This behaviour was not present in versions prior to 2.0.11 (at least 2.0.10 works properly). Attached patch was proposed as solution and is confirmed to work.

On 2013-08-13 17:13:40 +0000, wrote:

I cannot find the code so I think that it changed completely and maybe the bug is not there, but it would be great if you could take a look and confirm.

On 2013-08-14 03:12:46 +0000, Sam Lantinga wrote:

I believe this is fixed in the latest release. Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL_ttf_VS2013.sln (SDL_ttf_VS2013.sln, text/plain, 2013-11-14 07:08:47 +0000, 2776 bytes)
• SDL_ttf_VS2013.vcxproj (SDL_ttf_VS2013.vcxproj, Application/xml, 2013-11-14 07:09:23 +0000, 16709 bytes)
• glfont_VS2013.vcxproj (glfont_VS2013.vcxproj, Application/xml, 2013-11-14 07:09:39 +0000, 16624 bytes)
• showfont_VS2013.vcxproj (showfont_VS2013.vcxproj, Application/xml, 2013-11-14 07:09:59 +0000, 16604 bytes)

Reported in version: unspecified
Reported for operating system, platform: Windows (All), All

Comments on the original bug report:

On 2013-11-14 07:08:47 +0000, Joe LeVeque wrote:

Created attachment 1437
SDL_ttf_VS2013.sln

Attached are Visual Studio 2013 Solution/Project files for SDL_ttf.

On 2013-11-14 07:09:23 +0000, Joe LeVeque wrote:

Created attachment 1438
SDL_ttf_VS2013.vcxproj

On 2013-11-14 07:09:39 +0000, Joe LeVeque wrote:

Created attachment 1439
glfont_VS2013.vcxproj

On 2013-11-14 07:09:59 +0000, Joe LeVeque wrote:

Created attachment 1440
showfont_VS2013.vcxproj

On 2013-11-16 20:22:34 +0000, Sam Lantinga wrote:

Added, thanks!
https://hg.libsdl.org/SDL_ttf/rev/7e3e91b2e62f

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch fixing calling conventions of tests (callconv.patch, text/plain, 2006-05-13 18:33:25 +0000, 1681 bytes)

Reported in version: unspecified
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-05-13 18:32:34 +0000, Marc Peter wrote:

cleanup functions used with atexit() need to use the compiler's default calling convention. SDL_Quit and TTF_Quit use SDL_CALL which may be different.

Watcom makefile for Win32 following in another "bug".

On 2006-05-13 18:33:25 +0000, Marc Peter wrote:

Created attachment 129
patch fixing calling conventions of tests

On 2006-05-14 17:13:41 +0000, Sam Lantinga wrote:

I removed the use of atexit() in the test programs, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-24 20:21:26 +0000, Klaus Blindert wrote:

First: Thanks for this nice library.
We are going to use it in our game engine: www.fifengine.de
But now to the bug(s).

This is perfectly valid code on Linux.
But on Windows it throughs the second exception,
when the font file exists.

SDL_RWops* rwops = SDL_RWFromFile(filename.c_str(),"r");

if( rwops ) {
mFont = TTF_OpenFontRW(rwops,1,size);
} else {
throw GCN_EXCEPTION("Error loading file:"+filename +
" SDL_Error: "+std::string(SDL_GetError()));
};

if (mFont == NULL) {
throw GCN_EXCEPTION("Error loading file: "+filename +
" TTF_Error: "+std::string(TTF_GetError()));
}

We introduced RWops, for the following reason:
The following snippet works on windows and linux,
but SEGFAULTS when the file is nonexistent. This can be worked around,
but is still a bug.

mFont = TTF_OpenFont(filename.c_str(),size);

if (mFont == NULL) {
throw GCN_EXCEPTION("Error loading file: "+filename +
" TTF_Error: "+std::string(TTF_GetError()));
}

Since we use a virtual filesystem, it would be good, if SDL_TTF works
with RWops together.

I didn't find anything related. It's too late today to dive into
the TTF sourcecode, but I will assist in figuring the problem out.
I think, we'll be able to work around the bug ...
Library version is 2.0.7

Greetings, Klaus (aka Phoku)

On 2006-01-27 03:46:04 +0000, Mikael Eriksson wrote:

When creating the RWops, you have to specifiy the mode as "rb", not just "r".

This is also safe on linux.

On 2006-01-27 03:54:44 +0000, Sam Lantinga wrote:

Good point, thanks Mikael!

On 2006-01-27 11:23:24 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-09-23 16:32:08 +0000, mko wrote:

TTF_RenderText_Solid method does not work any more since the sdl-ttf-2.0.8.
After analyse, the second parameter (char* text) does not accept a string with one or more spaces. In this case, the string will not be displayed.

For information, I work on a gentoo linux with amd64 processor, and I use the libsdl 1.2.11

On 2006-11-24 01:42:22 +0000, andreas wrote:

This is a known bug in FreeType and is fixed in their CVS.

Reference; http://www.mail-archive.com/[email protected]/msg00802.html

As a workaround, building SDL_ttf with v2.1.10 or earlier may solve the problem.

On 2006-12-21 00:20:55 +0000, Jesse Andrews wrote:

if it helps at all:

SDL_Color color={0,0,0};
SDL_Surface *text_surface;
text_surface=TTF_RenderText_Solid(font,"Hello World!",color);
printf("Error: %s\n", TTF_GetError());

returns

Error: Failed loading DPMSDisable: /usr/lib/libX11.so.6: undefined symbol: DPMSDisable

but I guess we just have to live with it not working until FreeType has another release and it is picked up by most distros :(

On 2007-02-13 05:24:19 +0000, Ryan C. Gordon wrote:

(Not an SDL bug, resolving bug entry.)

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), x86_64

Comments on the original bug report:

On 2011-08-23 01:38:46 +0000, Vittorio Giovara wrote:

Hi, i'm just opening the bug to follow up the discussion here: http://forums.libsdl.org/viewtopic.php?t=6957&sid=c0fd687d04dfc2c1ca2895654f4e345b

Basically it would be nice to have the freetype library independent of x11 presence for better osx integration (and macappstore approval process)

On 2012-01-02 22:06:32 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_ttf/rev/46d697e5d3dc

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• the digital ttf font (digital_7.ttf, application/octet-stream, 2010-03-11 00:01:01 +0000, 33976 bytes)

Reported in version: 2.0.9
Reported for operating system, platform: Other, ARM

Comments on the original bug report:

On 2010-03-11 00:01:01 +0000, wrote:

Created attachment 500
the digital ttf font

when I use digital-7.ttf, only top half text is drawn, however, on WinXP/PC, the font seems no problem.

the font link is:
http://www.fonts4free.net/dsplus/m.php?p=digital_7.zip

On 2012-01-02 22:08:33 +0000, Sam Lantinga wrote:

I just tried this font with the build I'm getting ready to release and it works fine.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows 7, x86

Comments on the original bug report:

On 2013-10-23 04:20:17 +0000, Joe LeVeque wrote:

It appears as though in begin_code.h the following line was removed in SDL changeset 7860:

#define inline __inline

and replaced with:

SDL_INLINE

However, SDL_ttf.c still has references to inline, which are now undefined. It seems like they need to be replaced with SDL_INLINE as well.

On 2013-11-08 22:18:18 +0000, Joe LeVeque wrote:

This appears to have been fixed with SDL changeset 7881.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.11
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2012-07-02 06:50:41 +0000, Folkert van Heusden wrote:

SDL_TTF is currently not thread-safe. That is: SDL_TTF at itself might be thread-safe but the FreeType library underneath is not accessed in a thread-safe way.
Please consider extending SDL_TTF so that each thread can do a SDL_TTF_Init()-like call which returns a thread-specific structure containing the result of FT_Library (http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Library ).

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Modified source code of SDL_ttf.c. (SDL_ttf.c, text/plain, 2014-04-09 13:39:04 +0000, 76597 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2014-04-09 13:39:04 +0000, George Wu wrote:

Created attachment 1611
Modified source code of SDL_ttf.c.

SDL_ttf didn't quite show hospitability to Asian languages using UTF-8 and UNICODE . When using TTF_RenderUTF8_Blended_Wrapped() function (which the other to *_Blended_Wrapped() functions finally calls), it generates overlapped characters and wrong line wrapping. This patch is intended to fix these issues.
The change I made begins from line 1849 and ends from line 2277, see attachment. Please ignore changes elsewhere. It does work on my system, but robustness is not assured. I would be glad if someone tests it on an OS other than Windows.

On 2014-04-13 18:20:09 +0000, Philipp Wiesemann wrote:

The modified file is based on the last release and also contains an unused TTF_SetFontSize() from bug 2487.

A related bug is 2492 (it links here).

On 2019-01-31 14:01:31 +0000, Sylvain wrote:

closing since it's a duplicate of bug 2487 and 2492

*** This bug has been marked as a duplicate of bug 2487 ***

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• The TTF_SetFontSize() function. (file_2487.txt, text/plain, 2014-04-09 13:54:11 +0000, 2199 bytes)
• patch (patch_bug_2487_tff_setFontSize.diff, text/plain, 2018-10-30 19:43:24 +0000, 2019 bytes)
• test case (main_bug_2487_ttf_setFontSize.c, text/x-csrc, 2018-10-30 19:48:43 +0000, 8247 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2014-04-09 13:54:11 +0000, George Wu wrote:

Created attachment 1612
The TTF_SetFontSize() function.

In SDL_ttf-2.0.12, the font size cannot be set dynamically. To reset the font, I must close the original font, and load it with a new size again.
This patch suggests an API change of SDL_ttf. It adds a function TTF_SetFontSize(), whose code is uploaded as attachment.
Robustness fixme:
Original height and new height of a font are both integers, the final glyph_italics field (integer) will not be so accurate after re-setting the size many times.
Source:
Fixed from the code on http://blog.csdn.net/fghjkldf/article/details/11562443 (line 77).

On 2014-04-13 18:53:29 +0000, Philipp Wiesemann wrote:

The TTF_SetFontSize() function uses TTF_CloseFont() on the TTF_Font if there was an error which then also deletes the TTF_Font.
I think this is confusing because I would expect the TTF_Font to be still usable after calling TTF_SetFontSize(). There is no return value which tells me that I can not use it again.

The other TTF_Set*() also do not have return values so maybe a consistent solution would be to have TTF_SetFontSize() set the error message but not delete the TTF_Font. (This assumes that trying to set the font size and failing does not corrupt the TTF_Font in any way.)

To make TTF_SetFontSize() usable it also needs to be added to SDL_ttf.h.

The function TF_SetFontSize() is also available in an attachment at bug 2486.

On 2018-10-30 19:43:24 +0000, Sylvain wrote:

Created attachment 3418
patch

Add a patch for this based on head with similar behaviour.

On 2018-10-30 19:48:43 +0000, Sylvain wrote:

Created attachment 3419
test case

test case to try it. keyboard o/p to change increase/decrease the font size.

On 2019-01-31 13:49:22 +0000, Sylvain wrote:

Fixed in ttps://hg.libsdl.org/SDL_ttf/rev/1f3d498496da

On 2019-01-31 14:01:31 +0000, Sylvain wrote:

*** Bug 2486 has been marked as a duplicate of this bug. ***

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• test case (main_bug_ttf.c, text/x-csrc, 2014-04-17 06:53:12 +0000, 2214 bytes)
• ttf font (DroidSansFallback.ttf, application/x-font-ttf, 2014-04-17 06:55:45 +0000, 4529044 bytes)
• ttf font with no problem (DroidSans.ttf, application/x-font-ttf, 2014-04-17 07:00:28 +0000, 114976 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2014-03-29 13:42:33 +0000, Sylvain wrote:

Hi,

With latest version, on Linux. (but whatever OS would do the same).

I try to render the string "Jap" in size 50, and what appears to be rendered is "Jap."
The "." is in fact the begining of the "J"

The first glyph has a value "minx" of -14
And so, should be "compensated for the wrap around with negative minx".

... basically :

in the function TTF_RenderUTF8_Shaded:
line 1586:
we have the initialisation to false :

first = SDL_FALSE

and it should be

first = SDL_TRUE

Thanks,

Sylvain

On 2014-04-17 06:53:12 +0000, Sylvain wrote:

Created attachment 1622
test case

test case

On 2014-04-17 06:55:45 +0000, Sylvain wrote:

Created attachment 1623
ttf font

And also the font for the testcase. All fonts do not make the bug appear. This one does.

On 2014-04-17 06:59:28 +0000, Sylvain wrote:

I was thinking of this patch :

diff -r 1854597a90fd SDL_ttf.c
--- a/SDL_ttf.c Sun Feb 02 02:32:02 2014 -0800
+++ b/SDL_ttf.c Thu Apr 17 08:55:46 2014 +0200
@@ -1583,7 +1583,7 @@

 /* Load and render each character */
 textlen = SDL_strlen(text);

• first = SDL_FALSE;

• first = SDL_TRUE;
  xstart = 0;
  while ( textlen > 0 ) {
  Uint16 c = UTF8_getch(&text, &textlen);

But this is not perfect. The "." does not appear, but the "J" is not fully rendered.

On 2014-04-17 07:00:28 +0000, Sylvain wrote:

Created attachment 1624
ttf font with no problem

This TTF font has no problem !

On 2014-04-22 11:21:40 +0000, Sylvain wrote:

Sorry, the two fonts are different. So the "J" is rendered as exepected when the patch is applied.

Please double-check the patch and apply it.
Thanks

On 2014-06-28 18:43:15 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL_ttf/rev/86d0c63699f4

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• No freetype internals patch. (SDL_ttf-2.0.7-noftinternals.patch, text/plain, 2006-09-04 03:11:41 +0000, 436 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-09-04 03:11:02 +0000, Ryan C. Gordon wrote:

This apparently came from freetype.org itself...

http://freetype.org/freetype2/patches/SDL_ttf-2.0.7-noftinternals.patch

Sam, can you apply this patch? I wanted to make sure there wasn't a reason the code exists as it does before I applied it myself (compatibility with some legacy version?).

--ryan.

On 2006-09-04 03:11:41 +0000, Ryan C. Gordon wrote:

Created attachment 162
No freetype internals patch.

On 2006-09-14 02:54:31 +0000, Sam Lantinga wrote:

It was for legacy FreeType compatibility, but I'm inclined to apply it if it comes from FreeType.org

On 2006-12-17 16:30:48 +0000, Torsten Giebl wrote:

Please apply this patch.

I am using the latest FreeType 2.2.1 on Windows,
Linux and Mac OSX with this patch without problems.

On 2007-02-13 05:18:16 +0000, Ryan C. Gordon wrote:

Fixed in svn revision # 2971.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Big image on top is the output. Small image beneath is an example of correct rendering. (tibstack.jpg, image/jpeg, 2014-01-25 02:42:48 +0000, 77351 bytes)

Reported in version: 2.0.11
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2014-01-25 02:42:48 +0000, wrote:

Created attachment 1537
Big image on top is the output. Small image beneath is an example of correct rendering.

The main developer for the Kivy project stated in IRC that he believed that the problem might be located in FT_Get_Kerning(), where only delta.x is used and never delta.y.

My test code: https://github.com/ironhouzi/sdl2-sdl_ttf-test

The correct rendering is done on my system: Slackware 14.1, in the Konsole terminal emulator on KDE 4.10.5. The truetype font used is MS Himalaya, which is by far the most Unicode compliant font in existence which covers the address space used for the example. A download link is available in the Github repository.

In case the attachment didn't work:

Image of the output: http://imgur.com/vKLVpt1
Image of how it should be displayed: http://imgur.com/V0zS1rm

This is the output of the SDL_Version testing at the beginning of my code
:
compiled with SDL_ttf version: 2.0.12
running with SDL_ttf version: 2.0.11

Don't hesitate to contact me with any questions or requests. This is a complete show stopper for my project, so I will try to do everything I can to help the elimination of the bug.

On 2014-01-25 02:47:33 +0000, wrote:

Using FreeType version 16.2.10

On 2014-02-02 09:57:38 +0000, Sam Lantinga wrote:

I checked the kerning, and delta.x and delta.y are both 0 for all characters in the string. The advance is 0 for the characters that stack upon one another, which is what I would expect.

Notice though that the glyph shape actually changes when they are composed in this way. I think the font system that KDE is using may actually be substituting glyphs for character sequences. ICU provides advanced functionality to do this sort of thing, but it's not included with SDL.

I could be totally wrong though. Can you confirm?

On 2014-02-02 10:16:39 +0000, Sam Lantinga wrote:

Doing more research, it looks like what you need is an OpenType shaping engine.

Searching around I found some examples of harfbuzz and SDL, which might be closer to what you need:
https://github.com/wutipong/drawtext-sdl2-freetype2-harfbuzz
https://github.com/wutipong/drawtext-sdl2-freetype2-harfbuzz/blob/master/sdl-ft-harfbuzz/main.cpp

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.10
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2010-03-21 04:41:17 +0000, Tobias Leich wrote:

Hi, if I do:

TTF_SetFontHinting(font, TTF_HINTING_LIGHT); // TTF_HINTING_LIGHT == 1

then:

TTF_GetFontHinting(font):

returns 65536 instead of TTF_HINTING_LIGHT (1).

You do a translation is the Set~ function:

void TTF_SetFontHinting( TTF_Font* font, int hinting )
{
if (hinting == TTF_HINTING_LIGHT)
font->hinting = FT_LOAD_TARGET_LIGHT;
else if (hinting == TTF_HINTING_MONO)
font->hinting = FT_LOAD_TARGET_MONO;
else if (hinting == TTF_HINTING_NONE)
font->hinting = FT_LOAD_NO_HINTING;
else
font->hinting = 0;
Flush_Cache( font );
}

But none in the Get~ function:

int TTF_GetFontHinting( const TTF_Font* font )
{
return font->hinting;
}

The FT_~ constants are not 0..3 like the TTF_~ are (freetype/freetype.h):

#define FT_LOAD_TARGET_( x ) ( (FT_Int32)( (x) & 15 ) << 16 )

#define FT_LOAD_TARGET_NORMAL FT_LOAD_TARGET_( FT_RENDER_MODE_NORMAL )
#define FT_LOAD_TARGET_LIGHT FT_LOAD_TARGET_( FT_RENDER_MODE_LIGHT )
#define FT_LOAD_TARGET_MONO FT_LOAD_TARGET_( FT_RENDER_MODE_MONO )
#define FT_LOAD_TARGET_LCD FT_LOAD_TARGET_( FT_RENDER_MODE_LCD )
#define FT_LOAD_TARGET_LCD_V FT_LOAD_TARGET_( FT_RENDER_MODE_LCD_V )

Cheers

On 2010-03-25 02:03:14 +0000, Sam Lantinga wrote:

This is fixed in source control, thanks!
http://hg.libsdl.org/SDL_ttf/rev/346309f53e45
http://hg.libsdl.org/SDL_ttf/rev/25ec85256dca

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.11
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2012-07-02 00:11:04 +0000, Nitz wrote:

Hi Mr.Sam,
Actually i am using SDL_ttf for some application. While going through the code i found that:

In TTF_OpenFontIndexRW( SDL_RWops *src, int freesrc, int ptsize, long nFontIndex ) function when if( ! TTF_initialized ) condition gets true, code just set error and return NULL but file is still open, there is no handling to close the file in this condition which causes crash in the code.

Inside this if( ! TTF_initialized )condition there should be some function call also for closing the file i.e SDL_RWclose.

Earlier the code is in SDL_ttf-2.0.11 ver.

TTF_Font* TTF_OpenFontIndexRW( SDL_RWops src, int freesrc, int ptsize, long nFontIndex )
{
TTF_Font font;
FT_Error error;
FT_Face face;
FT_Fixed scale;
FT_Stream stream;
int position;

    if ( ! TTF_initialized ) {
            TTF_SetError( "Library not initialized" );
            return NULL;
    }
  //Some code 

}

Fix should be Like this

TTF_Font* TTF_OpenFontIndexRW( SDL_RWops src, int freesrc, int ptsize, long nFontIndex )
{
TTF_Font font;
FT_Error error;
FT_Face face;
FT_Fixed scale;
FT_Stream stream;
int position;

    if ( ! TTF_initialized ) {
            SDL_RWclose(src);
            TTF_SetError( "Library not initialized" );
            return NULL;
    }
  //Some code 

}

Thanks for your support.

Best Regards,
NITZ

On 2012-07-02 05:25:58 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_ttf/rev/ef14fbc2201c

On 2012-07-05 23:39:01 +0000, Nitz wrote:

(In reply to comment # 1)

Fixed, thanks!
http://hg.libsdl.org/SDL_ttf/rev/ef14fbc2201c

Mr.Sam kindly apply patch here also:
/* Check to make sure we can seek in this stream */
position = SDL_RWtell(src);
if ( position < 0 ) {
TTF_SetError( "Can't seek in stream" );
if ( freesrc ) {
SDL_RWclose( src );
}
return NULL;
}

Thanks and Regards
Nitz

On 2012-07-07 06:01:13 +0000, Sam Lantinga wrote:

Whoops, good catch. Fixed, thanks!

On 2013-04-16 05:46:26 +0000, Nitz wrote:

Hi Mr.Sam
The same patch should be applied here also, like this

/* Check to make sure we can seek in this stream */
position = SDL_RWtell(src);
if ( position < 0 ) {
TTF_SetError( "Can't seek in stream" );
if ( freesrc ) {
SDL_RWclose( src );
}

return NULL;
}

This is not applied yet, I think it was missed :)

On 2013-04-17 04:44:11 +0000, Sam Lantinga wrote:

It looks like it's fixed to me, did I miss something?
http://hg.libsdl.org/SDL_ttf/rev/e716077c97c5

On 2017-09-10 05:41:50 +0000, Sam Lantinga wrote:

I double checked, and this is fixed.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2014-03-28 21:01:16 +0000, wrote:

Hoping that I've just made a silly mistake in my code. Trying to open up a TTF file, lazy.ttf on Fedora 19.

if(TTF_Init() == -1)
std::cout << "TTF failed to initialize." << std::endl;
TTF_Font *f = TTF_OpenFont("lazy.ttf", 22);
if(f == nullptr)
std::cout << TTF_GetError() << std::endl;

This code works for me fine on Windows 8, however it doesn't work for me on Fedora 19, giving me the error "Couldn't load font file.". I have the font file in the correct directory and I've scoured the internet in an attempt to find a solution to no avail. My project is in codeblocks and everything is linked correctly to my knowledge.

Sorry if this isn't a bug and is just a mistake on my end.

Thanks

On 2014-12-19 10:14:46 +0000, Yohann Ferreira wrote:

Hi there,

For info, this bug looks similar to: https://bugzilla.libsdl.org/show_bug.cgi?id=2127

It seems the following patch may have fixed the problem:
http://hg.libsdl.org/SDL_ttf/rev/86aa91bce20c

Hopefully this will help you.

Best regards,

On 2017-09-10 05:55:04 +0000, Sam Lantinga wrote:

If this is the font you're trying to load, this works fine with the latest SDL_ttf release:
http://www.dafont.com/lazy.font

If not, please reopen the bug and attach the font for diagnosis.

Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• sdl-ttf-expose-hinting.patch (sdl-ttf-expose-hinting.patch, text/plain, 2008-09-04 18:05:55 +0000, 1980 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2008-09-04 18:05:28 +0000, Gregory Smith wrote:

This patch allows setting the hinting style of each TTF_Font. The options are none, light, mono(chrome), and normal/default. This is useful because it allows access to FreeType's slight hinter, which IMO looks much better for in-game interfaces.

On 2008-09-04 18:05:55 +0000, Gregory Smith wrote:

Created attachment 273
sdl-ttf-expose-hinting.patch

On 2009-09-26 01:31:07 +0000, Sam Lantinga wrote:

Thank you very much for your patch!

Do you give me permission to release your code with SDL 1.3 and future versions of SDL under both the LGPL and a closed-source commercial license?

On 2009-09-26 08:28:59 +0000, Gregory Smith wrote:

Yes, you may use this patch as you described.

On 2009-09-26 14:33:24 +0000, Sam Lantinga wrote:

Thanks! Your changes are in for the next release.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2007-01-29 19:31:46 +0000, Ryan C. Gordon wrote:

Discussion and patch are here (was this Cygwin-specific?)...

http://article.gmane.org/gmane.comp.lib.sdl/30644

--ryan.

On 2007-02-13 05:26:33 +0000, Ryan C. Gordon wrote:

Fixed in svn revision # 2973.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• test case (misplaced_glyph.c, text/x-csrc, 2014-07-03 19:03:01 +0000, 1859 bytes)
• the font (HelveticaNeue-Regular.ttf, application/font-truetype, 2014-07-03 19:03:26 +0000, 49832 bytes)
• screenshot (Screen Shot 2014-07-03 at 2.56.49 .png, image/png, 2014-07-03 19:04:40 +0000, 26702 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2014-07-03 19:03:01 +0000, Sylvain wrote:

Created attachment 1728
test case

Some glyph are misplaced with this font.
here's a test case + picture.

On 2014-07-03 19:03:26 +0000, Sylvain wrote:

Created attachment 1729
the font

On 2014-07-03 19:04:40 +0000, Sylvain wrote:

Created attachment 1730
screenshot

On 2014-07-04 09:47:20 +0000, Sylvain wrote:

When using size 12, the 'n' gets a bad "horiBearingY" value from freetype (at least compared to the 'u').
This is the Y offset, when writing in horizontal layout.

See:
http://www.freetype.org/freetype2/docs/glyphs/
http://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html

If you use a different size (11 or 13), you get better result because the "horiBearingY" of 'u' and 'n' are equals
But it seems that if the font get loaded with different hint flags, you have also better result.

So after loading the font, you can use:

TTF_SetFontHinting(font, TTF_HINTING_LIGHT);

On 2014-12-19 10:12:05 +0000, Yohann Ferreira wrote:

Hi Sylvain, :)

I'm no SDL_ttf Guru master but I've been having a similar problem with my own app, and I've tried to sum up the problem and how we fixed it there:
https://bugzilla.libsdl.org/show_bug.cgi?id=2104#c12

Hopefully, this will help you or anyone else have info on the possible root cause of the problem.

Best regards,

On 2014-12-19 13:11:32 +0000, Sylvain wrote:

Hi Yohann,

For the record, this issue is from another person, see this thread :
http://forums.libsdl.org/viewtopic.php?p=44210

The font is "scalable".

Values from freetype seems to have the glitch.

I think SDL handles correctly the y offset. The glitch is already present in the freetype value (due to freetype rendering/scaling/filtering).

(freetype version is 2.5.2)

Cheers

scalable[S] horibearingY = 576 height = 576 font.ascent=12
scalable[u] horibearingY = 448 height = 448 font.ascent=12
scalable[n] horibearingY = 384 height = 448 font.ascent=12
scalable[:] horibearingY = 448 height = 448 font.ascent=12
scalable[ ] horibearingY = 0 height = 0 font.ascent=12
scalable[2] horibearingY = 576 height = 576 font.ascent=12
scalable[0] horibearingY = 576 height = 576 font.ascent=12
scalable[1] horibearingY = 576 height = 640 font.ascent=12
scalable[4] horibearingY = 576 height = 576 font.ascent=12
scalable[-] horibearingY = 256 height = 64 font.ascent=12
scalable[7] horibearingY = 576 height = 576 font.ascent=12
scalable[j] horibearingY = 576 height = 768 font.ascent=12
scalable[a] horibearingY = 384 height = 384 font.ascent=12
scalable[p] horibearingY = 384 height = 576 font.ascent=12
scalable[q] horibearingY = 384 height = 576 font.ascent=12
scalable[r] horibearingY = 384 height = 448 font.ascent=12
scalable[w] horibearingY = 448 height = 512 font.ascent=12
glyph[S] miny=0 maxy=9 yoffset=3
glyph[u] miny=0 maxy=7 yoffset=5
glyph[n] miny=-1 maxy=6 yoffset=6
glyph[:] miny=0 maxy=7 yoffset=5
glyph[ ] miny=0 maxy=0 yoffset=12
glyph[2] miny=0 maxy=9 yoffset=3
glyph[0] miny=0 maxy=9 yoffset=3
glyph[1] miny=-1 maxy=9 yoffset=3
glyph[4] miny=0 maxy=9 yoffset=3
glyph[-] miny=3 maxy=4 yoffset=8
glyph[0] miny=0 maxy=9 yoffset=3
glyph[7] miny=0 maxy=9 yoffset=3
glyph[-] miny=3 maxy=4 yoffset=8
glyph[0] miny=0 maxy=9 yoffset=3
glyph[2] miny=0 maxy=9 yoffset=3

On 2014-12-19 14:21:25 +0000, Yohann Ferreira wrote:

Hi again Sylvain,

Thanks for the links. :)

I think SDL handles correctly the y offset. The glitch is already present in the freetype value (due to freetype rendering/scaling/filtering).

Just to understand correctly what is happening, I guess you mean a different horibearingY from the height? Or even something else?

scalable[n] horibearingY = 384 height = 448 font.ascent=12
glyph[n] miny=-1 maxy=6 yoffset=6

I'll look into adding a light font hinting, btw. :)

Regards, :)

On 2014-12-19 14:45:52 +0000, Sylvain wrote:

The issue that was initially reported was "letters 'u' and 'n' are rendered misplaced".

With this log:

scalable[u] horibearingY = 448 height = 448 font.ascent=12
scalable[n] horibearingY = 384 height = 448 font.ascent=12

We see that freetype says "letters 'u' and 'n' have same height".
And also "'u' and 'n' are not aligned" (because of the different horiBearingY).
So, even before rendering the "letters 'u' and 'n' are misplaced".

I am not a freetype expert, but it seems to me, the issue is with freetype.

Using the light font, is just a workaround to have the same font-size without the glitch. (But, who knows, the same kind of issue may appears with other glyph).

On 2014-12-19 21:59:51 +0000, Yohann Ferreira wrote:

Hi Sylvain, :)

Thanks for all the info. there is indeed something fishy with horizBearingY.

Can you tell how you got the info? Did you had some log in sdl ttf?
In fact, I must say I was wondering whether the FT_CEILING and FT_FLOOR could somehow get in the way.

If they don't, the next step is the freetype code source!

On 2014-12-20 08:43:45 +0000, Sylvain wrote:

Hi,

Yes, the log comes from a few "printf" added into SDL_ttf.c.
The FT_CEIL/FT_FLOOR are also defines in this file.

43 /* Handy routines for converting from fixed point */
44 #define FT_FLOOR(X) ((X & -64) / 64)
45 #define FT_CEIL(X) (((X + 63) & -64) / 64)

I've Tried with freetype 2.5.4, and also freetype 2.4.0. Same issue.

On 2017-09-10 06:02:00 +0000, Sam Lantinga wrote:

I can reproduce this with the SDL_ttf test program:
./showfont ~/Downloads/HelveticaNeue-Regular.ttf 12 "Sun: 2014-07-02"

I'm not sure what we can do if FreeType is returning bad values...

On 2017-09-10 12:03:29 +0000, Sylvain wrote:

I think I did nothing for that, except changing the font.
Maybe let's just close the bug :)

On 2017-09-10 16:19:59 +0000, Sam Lantinga wrote:

Okay, sounds good. :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Const correctness patch (SDL-ttf-sgreene-constify-1.1.patc, text/plain, 2006-09-08 20:27:57 +0000, 3500 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-09-08 20:27:35 +0000, Ryan C. Gordon wrote:

Date: Fri, 8 Sep 2006 13:02:01 -0400
To: [email protected]
From: Steaphan Greene
Subject: Re: [SDL] Nonconstant arguments on SDL functions

Here are the same changes in a new patch matched up against current SVN.
Let me know if you find problems, but I did test these on Debian/Sparc,
Debian/PPC, Debian/386, Debian/Amd64 and Windows:386, though only with
gcc. This was a few months ago though.

Steaphan Greene
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt

On 2006-09-08 20:27:57 +0000, Ryan C. Gordon wrote:

Created attachment 163
Const correctness patch

On 2007-02-13 05:23:10 +0000, Ryan C. Gordon wrote:

Fixed in svn revision # 2972.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2009-11-16 03:03:07 +0000, wrote:

The webpage at [http://www.libsdl.org/projects/SDL_ttf/] does not list the changes in the most recent release. The webpage should use headings
like

and

so that it is possible to link to
[http://www.libsdl.org/projects/SDL_ttf/#changes] and
[http://www.libsdl.org/projects/SDL_ttf/# 2.0.10].

And of course the page should be syntactically correct:
http://validator.w3.org/

On 2012-01-02 22:09:06 +0000, Sam Lantinga wrote:

Good idea, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.10
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2010-03-11 03:27:50 +0000, Tobias Leich wrote:

Hi there, I actually do the bindings for SDL_perl to SDL_ttf and have noticed a bug.

In TTF_RenderUTF8_Solid the BOM is set to the first Uint16, but in the following line it gets overwritten.

Patch (like the other UTF8 functions already do):

================================================================================
diff --git a/SDL_ttf.c b/SDL_ttf.c
index 2a7d6f5..66fb19d 100644
--- a/SDL_ttf.c
+++ b/SDL_ttf.c
@@ -1288,7 +1288,7 @@ SDL_Surface *TTF_RenderUTF8_Solid(TTF_Font *font,
return(NULL);
}
*unicode_text = UNICODE_BOM_NATIVE;

• UTF8_to_UNICODE(unicode_text, text, unicode_len);

• UTF8_to_UNICODE(unicode_text+1, text, unicode_len);

  /* Render the new text */
  textbuf = TTF_RenderUNICODE_Solid(font, unicode_text, fg);
  ================================================================================

Cheers, Tobias Leich

On 2010-03-25 02:08:28 +0000, Sam Lantinga wrote:

This is fixed for the next release, thanks!
http://hg.libsdl.org/SDL_ttf/rev/d8d6a6d3cc73

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• protype patch (patch_bug_1399_ttf_streaming_texture.difff, text/plain, 2018-11-13 09:48:34 +0000, 6246 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2012-01-27 10:24:11 +0000, Rodrigo Cardoso wrote:

That's it, the summary is self explanatory =]

Would be much easier and faster when using SDL_Textures.

thanks!

On 2012-01-28 07:27:13 +0000, Sam Lantinga wrote:

This is something we can add in the SDL2 upgrade.

On 2018-11-13 09:48:34 +0000, Sylvain wrote:

Created attachment 3484
protype patch

This is a prototype for rendering text directly to streaming texture.
patch is diff'ed with bug 4361, and test-case app will be updated in bug 4374

It renders to a SD_Texture created with SDL_TEXTUREACCESS_STREAMING and format SDL_PIXELFORMAT_ARGB8888.
Only "Blended" is done. Not sure that it makes senses to do Solid/Shaded, as they are palletized surfaces and that would require a conversion.

Prototype/name of the function is:

int TTF_RenderUTF8_Texture(TTF_Font *font, SDL_Texture *texture, const char *text, SDL_Color fg)

But it should probably also include some dest x/y position.
The function doesn't add much rendering complexity as it only prepares datas and calls "Render_Line()".

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Android (All), ARM

Comments on the original bug report:

On 2011-10-22 07:00:24 +0000, Mike Chen wrote:

the latest SDL 1.3 download from HG allow user read resource from assets by JNI. I test it is OK in SDL_Image, but it does not compliant with SDL_ttf. When use the function of TTF_OpenFont*() it reports error of "Couldn't load font file". I trace the source code find "SDL_RWops rw = SDL_RWFromFile(file, "rb");" seems no problem.
but in TTF_Font TTF_OpenFontIndexRW( SDL_RWops *src, int freesrc, int ptsize, long index )
...
error = FT_Open_Face( library, &font->args, index, &font->face );
if( error ) {
TTF_SetFTError( "Couldn't load font file", error );
TTF_CloseFont( font );
return NULL;
}
it returns NULL
I have no idea what wrong in FT_Open_Face.

On 2011-10-24 17:37:20 +0000, Gabriel Jacobo wrote:

Your problem sounds exactly like the bug in # 1301, which was fixed a few days ago (changeset c9cb52d6d864), can you confirm you have that patch incorporated?

On 2011-10-25 06:53:06 +0000, Mike Chen wrote:

(In reply to comment # 1)

Your problem sounds exactly like the bug in # 1301, which was fixed a few days
ago (changeset c9cb52d6d864), can you confirm you have that patch incorporated?

Yes,it's what I really want! Thanks a lot.

On 2011-10-25 11:40:42 +0000, Gabriel Jacobo wrote:

You're welcome, I'll close the ticket.

*** This bug has been marked as a duplicate of bug 1301 ***

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch to add pkg-config for SDL_ttf (SDL_ttf-pkgconfig.diff, text/plain, 2009-07-07 03:33:59 +0000, 1087 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2009-07-07 03:33:59 +0000, Luca Bigliardi wrote:

Created attachment 337
patch to add pkg-config for SDL_ttf

Hi,
I'm attaching a patche to add pkg-config support to SDL_ttf.

pkg-config is used to retrieve information about installed libraries and
it's well integrated with build configurators (for instance
PKG_CHECK_MODULES autoconf macro).

Thank you,

Luca

On 2009-08-07 03:12:29 +0000, Sam Lantinga wrote:

This patch has been committed to subversion with revision 4672

Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• OpenWatcom makefile plus freetype 2.1.10 libs and headers (Watcom-Win32.zip, application/octet-stream, 2006-05-13 18:45:57 +0000, 722367 bytes)

Reported in version: unspecified
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-05-13 18:40:00 +0000, Marc Peter wrote:

The attached archive contains a makefile for use with OpenWatcom 1.4 or newer, including the headers of freetype 2.1.10, and freetype libraries built with OpenWatcom for static and dynamic link libraries.

It calls the OpenWatcom makefile from the main SDL distribution, as contained in the Subversion trunk, to be able to built the test executables.

On 2006-05-13 18:45:57 +0000, Marc Peter wrote:

Created attachment 130
OpenWatcom makefile plus freetype 2.1.10 libs and headers

On 2006-05-14 17:16:17 +0000, Sam Lantinga wrote:

This is in subversion, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-09-05 04:13:58 +0000, Nicos wrote:

Sometimes you might wish to disable kerning so that characters do not move when they change. Please add an option to disable kerning either on a per font basis or per render call.

On 2009-09-26 01:14:46 +0000, Sam Lantinga wrote:

You got it:
Added API to disable kerning: TTF_GetFontKerning()/TTF_SetFontKerning()

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, x86_64

Comments on the original bug report:

On 2013-08-28 10:47:02 +0000, Ivan wrote:

based on font stash
https://github.com/apetrone/font-stash

or better ofxFontStash
https://github.com/armadillu/ofxFontStash

this will be very useful for embedded devices, like android or ios

On 2013-08-28 12:29:08 +0000, Ivan wrote:

Also this kind of work could be interesting
http://fractiousg.blogspot.ru/2012/04/rendering-text-in-opengl-on-android.html

On 2017-09-10 05:49:05 +0000, Sam Lantinga wrote:

It looks like you'd really want to use stb_truetype.h directly:
https://github.com/nothings/stb/blob/master/stb_truetype.h

I don't have time to work on this myself, but you're welcome to contribute a patch!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.12
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2013-12-01 17:31:35 +0000, Andrea wrote:

I'm using SDL2_ttf-2.0.12, if I try to render grade simbol the result have an A before the grade. For example if I want 12° the result is 12A°.
Is a my error or is a bug?
thank you
Andrea

On 2015-10-14 20:52:45 +0000, Philipp Wiesemann wrote:

Maybe the input string was not encoded in UTF-8.

On 2017-09-10 05:52:44 +0000, Sam Lantinga wrote:

Can you attach a simple C program that shows the problem?

Thanks!

On 2020-02-06 06:14:00 +0000, Sam Lantinga wrote:

You're using TTF_RenderText* functions, which take latin1 input. You should use the TTF_RenderUTF8* functions, which interpret the input correctly.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• font kerning size fix (kerning-size-fix.diff, text/plain, 2014-06-12 23:23:36 +0000, 1711 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2014-06-05 15:23:08 +0000, D wrote:

Hello! I've posted this to the forum, but no reaction there. So I duplicate this here to ease tracking.

I was working with fonts and faced a necessity of obtainig of kerning of glyph pair.
Documentation here: http://www.libsdl.org/projects/SDL_ttf/docs/ gave me no info on it.
So I spent some time to write own routine. When I finally looked into SDL_ttf.c I was quite surprised to find TTF_GetFontKerningSize function.
So the first point about TTF_GetFontKerningSize is old documentation on top of google search. Please, somebody, fix it
Second point is the fact that TTF_GetFontKerningSize behaviour looks strange (or even incorrect).
That is, it looks like the function takes characters codes and returns pair's kerning. But it doesn't.
If you look at the code of this function and at the code of appropriate text rendering function, you may notice that technically
TTF_GetFontKerningSize takes glyph's indices: Code:

int TTF_GetFontKerningSize(TTF_Font* f, int prev_index, int index)
{
FT_Vector delta;
FT_Get_Kerning( font->face, prev_index, index, ft_kerning_default, &delta );
return (delta.x >> 6);
}

And those indices cannot be obtained using other API's functions.
Considering above, I think its body should look like as follows (calculations in double is to increase acuracy ): Code:

int TTF_GetFontKerningSize(TTF_Font* f, int p, int c)
{
double res = 0.0;
int glyph_index = -1;
int prev_index = -1;

if(c == UNICODE_BOM_NATIVE || c == UNICODE_BOM_SWAPPED) 
{ 
   return 0.0; 
} 
if(p == UNICODE_BOM_NATIVE || p == UNICODE_BOM_SWAPPED) 
{ 
   return 0.0; 
} 

int error = Find_Glyph(f, c, CACHED_METRICS); 
if(error) 
{ 
   TTF_SetFTError("Couldn't find glyph", error); 
   return -1; 
} 
glyph_index = f->current->index; 
 
error = Find_Glyph(f, p, CACHED_METRICS); 
if ( error ) 
{ 
   TTF_SetFTError("Couldn't find glyph", error); 
   return -1; 
}        
prev_index = f->current->index; 

if ( prev_index && glyph_index ) 
{ 
   FT_Vector delta; 
   FT_Get_Kerning( f->face, prev_index, glyph_index, ft_kerning_default, &delta ); 
   res = delta.x; 
   res /= 64.0; 
} 

 return (int)res; 

}

I've tried this solution and it looks working.

Thank you for your attention.

On 2014-06-12 23:23:36 +0000, Jeffrey Carpenter wrote:

Created attachment 1680
font kerning size fix

I had the same trouble as the original author, and verified that his proposed patch does work for me, under Mac OS X v10.9.3. (Correspondence with the author via the SDL-dev mailing list shows his platform to be Xubuntu 14).

I'm not sure if this bug affects Windows at all, nor if the proposed changes change things.

Cheers,
Jeffrey Carpenter [email protected]

On 2014-06-16 01:25:10 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL_ttf/rev/4ecbc07f149f

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• example (main_bug_ttf.c, text/x-csrc, 2013-06-27 02:37:49 +0000, 2252 bytes)
• font thai (DroidSansThai.ttf, application/x-font-ttf, 2013-06-27 02:38:19 +0000, 35480 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2013-06-27 02:37:49 +0000, Sylvain wrote:

Created attachment 1198
example

Hey.

It seems to me this is a regression.

Some font : Thai and Hindi for instance are not more rendered (squares!).
many others : Latin, Chineese etc. are still fine.

This is a regression in SDL_ttf.c with the commit :
"Switched the default code path to be UTF-8"

The Bug still appears in the latest version of Trunk.

See example attached : c file + font.ttf

thanks,

Sylvain

On 2013-06-27 02:38:19 +0000, Sylvain wrote:

Created attachment 1199
font thai

On 2013-06-29 16:22:07 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_ttf/rev/83de51e7a428

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• The .fon file. (fixed8.fon, application/x-ms-dos-executable, 2013-10-01 21:05:36 +0000, 8704 bytes)

Reported in version: 2.0.12
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2013-10-01 21:05:36 +0000, Yohann Ferreira wrote:

Created attachment 1351
The .fon file.

Hi, :)

When loading the given .fon file, an error message is returned:
Fatal: Cannot load font from file 'text/fixed8.fon': Couldn't set font size

The same code was previously working, using SDL 1.2 and SDL_TTF 2.0.10.

I'll attach the .fon file (open licensed) which can also be downloaded from here:
https://github.com/christopho/zsdx/blob/master/data/text/fixed8.fon

We also tried:
TTF_OpenFont()
TTF_OpenFontRW()
TTF_OpenFontIndex()
or
TTF_OpenFontIndexRW()

with corresponding parameters but we couldn't get anything load.

Curious thing, the upstream dev told me that changing the .fon extension to .ttf did the trick(?!?)

This also happens on OSX AFAIK.

Thanks a lot for your help.

Best regards,

On 2013-10-02 08:39:38 +0000, Yohann Ferreira wrote:

Hi again,

More tests followed and the main upstream dev (christopho) told me that changing the .fon file to .ttf doesn't work after all.
Sorry, for the counter-saying.

I'll post a snippet testcase as soon as possible.

On 2013-10-02 15:14:46 +0000, Yohann Ferreira wrote:

Here is the gist of it:

#include "SDL_ttf.h"
#include <stdio.h>

int main(int /argc/, char ** /argv/)
{
if (TTF_Init() == -1) {
printf("TTF_Init: %s\n", TTF_GetError());
exit(2);
}

// load font.ttf at size 16 into font
TTF_Font *font;
font = TTF_OpenFont("./fixed8.fon", 16);
if (!font) {
    printf("TTF_OpenFont: %s\n", TTF_GetError());
    // handle error
    exit(1);
}

TTF_CloseFont(font);

TTF_Quit();

}

On 2013-10-03 08:32:01 +0000, Sam Lantinga wrote:

Have you tried debugging SDL_ttf? As far as I know, nothing in SDL_ttf has changed that would affect that, we're just using a newer version of FreeType.

On 2013-10-03 08:47:03 +0000, Yohann Ferreira wrote:

Hi, :)

Ack. I've requested some test on OSX. I'll do the same on Debian and will tell you whether we find something interesting for you.

Regards,

On 2013-11-07 11:19:55 +0000, Yohann Ferreira wrote:

Just to say I'm still on it. Stay tuned.

On 2014-09-24 10:14:33 +0000, Yohann Ferreira wrote:

Hey,

Seems the following bug is quite similar:
https://bugzilla.libsdl.org/show_bug.cgi?id=2468

Also, it seems that this fix is related to the problem:
http://hg.libsdl.org/SDL_ttf/rev/86aa91bce20c

I'd like to build the latest SDL_ttf with the newest Freetype version to debug several issues I've opened here.

Is there a reason you're still using FreeType 2.4.8?
(Freetype 2.5.x has fixed several issues about glyph metrics, among other things...)

Best regards,

Bertram

On 2017-09-10 05:51:50 +0000, Sam Lantinga wrote:

This is fixed in the latest SDL_ttf version.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• libsdl-ttf2.0-glyph_error_reporting.patch (libsdl-ttf2.0-glyph_error_reporting.patch, text/plain, 2012-01-27 12:00:35 +0000, 1586 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, Other

Comments on the original bug report:

On 2012-01-27 12:00:35 +0000, wrote:

Created attachment 808
libsdl-ttf2.0-glyph_error_reporting.patch

Debian contains the following bug report with a patch attached since a while ago, but I think that the upstream code still lacks these fixes/suggestions, so I don't think that it has been reported upstream. Anyway, it seems appropriate and useful to me to forward the bug report and patch.

http://bugs.debian.org/405378

Package: libsdl-ttf2.0-0
Version: 2.0.8-3+b1

I was just bitten by bug 374062 (any word if this will be fixed for
etch given that it is fixed upstream?), and found that there is no
error message set by sdl-ttf when it is unable to render a glyph,
which makes bugs like this a bit more difficult to track down. I
would really appreciate it if TTF_GetError() could return a useful
message in such situations. The attached patch does just that by
duplicating the existing error reporting for calls to Find_Glyph()
into the places where it is missing, although it might be nice to know
which glyph it was that could not be found...

The patch might be a bit out of date so maybe it doesn't apply cleanly, but that should be easy to fix if you're interested in incorporating it.

On 2012-01-28 07:29:23 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_ttf/rev/b09799bf8dff

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-19 05:10:45 +0000, Sam Lantinga wrote:

Current SDL_ttf (http://www.libsdl.org/cgi/cvsweb.cgi/SDL_ttf2/) seems
to calculate bounding boxes based on the maximum and minimum values that
appear in the font, as opposed to the used glyphs only. This means that
fonts containing some of the Unicode Block Elements will generally cause
SDL_ttf to use very large line spacing, even if the Block Elements are
not actually being used in the application.
http://www.unicode.org/charts/PDF/U2580.pdf

From Stepan Roh, project manager for the DejaVu font family:
In version 1.14 Box Elements were added
(created by David Lawrence Ramsey). Those glyphs have bigger descent than
other glyphs which cause the change of yMin value in TTF 'head' table from
-492 to -1034 (note that this value comes from Sans Mono and their Box
Drawing glyphs). This may explain your observations, however (I believe)
correct rasterizer should either compute bounding boxes of used glyphs
only (not of the whole font) or use typographic descents (either from
'hhea' table or from 'OS/2' table). I have DejaVuSans 1.14 installed in
KDE as a system font and it clearly uses one of those approaches.

As I look through SDL_ttf sources on a location you provided I see
(function TTF_OpenFontIndexRW):

       font->ascent  = FT_CEIL(FT_MulFix(face->bbox.yMax, scale));
       font->descent = FT_CEIL(FT_MulFix(face->bbox.yMin, scale));

... which looks like what I was talking about. I think you can try to
change it to:

       font->ascent  = FT_CEIL(FT_MulFix(face->ascender, scale));
       font->descent = FT_CEIL(FT_MulFix(face->descender, scale));

I have tested this suggested change with DejaVuSans 2.1 and after
this tweak, SDL_ttf now renders this font correctly in our application
(Battle for Wesnoth, http://www.wesnoth.org/). Please consider this
change for SDL_ttf.

(Stepan also had some other comments, see
http://sourceforge.net/mailarchive/message.php?msg_id=13151599
for his full message. The change above is the most generally relevant.)

-- Andras Salamon [email protected]

On 2006-01-27 11:23:16 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-05-01 05:26:41 +0000, Sam Lantinga wrote:

This is fixed in subversion, thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• picture showing mainly glyphs with lower part being misplaced (like p, q, ...). (glyph_misplaced.png, image/png, 2013-09-18 16:51:29 +0000, 465666 bytes)
• spreadsheet showing differences in glyph metrics between the two versions (font_metrics_comparison_sdl12_and_20.xls, application/vnd.ms-excel, 2013-11-06 15:48:37 +0000, 19968 bytes)

Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2013-09-18 16:51:29 +0000, Yohann Ferreira wrote:

Created attachment 1330
picture showing mainly glyphs with lower part being misplaced (like p, q, ...).

Hi there :)

I've been porting Valyria Tear for SDL2 the latest few days and it went rather smoothly. :D

The only thing I've been able to notice is that glyphs are now misplaced using SDL_TTF 2.0.12. (I'll attach a picture showing the problem asap.)
The text rendering code is untouched and I'll add links to code asap.

I've yet been able to compile the same app using the following lib version:
(from slctech.org)
http://www.slctech.org/~mackay/game20214/MingW_SDL2_Binaries.html

This version of the SDL2 libraries are a year old but when using them, glyph rendering on SDL2 was fine. May I assume a bug this is a new bug in SDL_ttf of has the behaviour of certain font metrics function(s) been fixed/changed?

Best regards,

Yohann / Bertram

On 2013-09-18 16:54:01 +0000, Yohann Ferreira wrote:

Fixed the last sentence (I should have reread more carefully, sorry)

"This version of the SDL2 libraries are a year old but when using them, glyph rendering on SDL2 is fine. May I assume this is a new bug in SDL_ttf or has the behaviour of certain font metrics function(s) been fixed/changed?"

On 2013-09-19 08:09:59 +0000, Yohann Ferreira wrote:

Happens also on Linux (Current Debian Sid) with the same library version. (2.0.12)

On 2013-09-21 14:36:06 +0000, Yohann Ferreira wrote:

Hi again,

I'm working on analysing the glyph info given for each font and compared them between the 2.0.9 (on SDL1.2) and 2.0.12 (with SDL 2.0.0).

As my application is using a glyph cache, all the rendering depends on what is returned by TTF_RenderGlyph_Blended() and TTF_GlyphMetrics().

I also set the hinting to LIGHT and enabled the kerning (doesn't change the rendering if disable both, just in case).

The problem now is that the SDL2.0 version doesn't seem to create stdout.txt/stderr.txt anymore on Windows XP si it might take more time.

On 2013-11-06 15:47:45 +0000, Yohann Ferreira wrote:

Hi again,

I took the time to compare the metrics given by TTF_GlyphMetrics() between 2.0.9 (SDL 1.2) and 2.0.12 (SDL 2.0)
You can find the spreadsheet here showing the differences.

In short, there are random differences in minx, maxx, maxy, and advance but never in the miny value given.

You might want to check how those fields are obtained.

Best regards,

On 2013-11-06 15:48:37 +0000, Yohann Ferreira wrote:

Created attachment 1411
spreadsheet showing differences in glyph metrics between the two versions

On 2013-11-07 09:34:46 +0000, Sam Lantinga wrote:

The SDL_ttf 2.0.9 and 2.0.12 are usually built against different FreeType versions. Can you verify that they're using the same version of FreeType? If so, the differences may be caused by bug-fixes in SDL_ttf since 2.0.9.

On 2013-11-07 10:54:57 +0000, Yohann Ferreira wrote:

Hi,

What I can tell right away is that SDL_TTF 2.0.9 and 2.0.12 are using the file libfreetype-6.dll as a dependency (on windows).
Now, it's not the same file size and creation date at all.

Now, when I copied the libfreetype-6.dll file used by SDL_TTF2.0.12 into the SDL-1.2/SDL_TTF-2.0.9 installation on windows, overwriting the previous same-named dll, I had no font display problems there when running the SDL_TTF-2.0.9 app.

The opposite cannot be done as the SDL-2.0 app won't start with the libfreetype-6.dll of the former version.

Is that a sufficient answer?

Best regards,

On 2013-11-07 11:11:02 +0000, Yohann Ferreira wrote:

You can also view the differences in dependencies more precisely with the debian pts, or I hope so:
http://packages.debian.org/squeeze/libsdl-ttf2.0-0 (2.0.9)
-> dep: libfreetype6 (>= 2.2.1) [kfreebsd-amd64, kfreebsd-i386]
dep: libfreetype6 (>= 2.3.5) [non kfreebsd-amd64, kfreebsd-i386]

http://packages.debian.org/sid/libs/libsdl2-ttf-2.0-0 (2.0.12)
-> dep: libfreetype6 (>= 2.2.1)

And I must precise the bug is also happening in Debian Sid atm, where I have libsdl_ttf(2.0.11-1) installed with libfreetype6 (>=2.2.1)
and libsdl2-ttf(2.0.12-1) with libfreetype6 (>=2.2.1) as a dependency also.

I'll check but I bet I'll have the exact same freetype .so file used for both.

I hope it'll help you

Best regards,

On 2013-12-03 09:32:50 +0000, Yohann Ferreira wrote:

Hi again,

freetype 2.5.1 is out:
http://sourceforge.net/projects/freetype/files/freetype2/2.5.1/

Among other changes, here is what can be read:

• In TrueType fonts, hinting of composite glyphs could sometimes deliver incorrect positions of components or even distorted shapes.

I do believe it might be linked to this issue.

Best regards,

On 2013-12-20 09:25:13 +0000, Yohann Ferreira wrote:

Hi again :)

Is a SDL_ttf release planned somewhere "soon", or should I rather compile the source myself against the latest libfreetype?

This would help me deal with this bug but also with the # 2127.

Best regards, and... Merry Christmas!

On 2014-09-24 10:17:48 +0000, Yohann Ferreira wrote:

Hi again,

It seems this issue is linked to the current one:
https://bugzilla.libsdl.org/show_bug.cgi?id=2622

I would also like to request that the next libsdl ttf version is linked against the latest freetype version, as 2.4.8 is aging, and several fixes have been made in glyph metrics computation AFAIK.

Thanks a lot and best regards,

Bertram

On 2014-12-19 10:08:26 +0000, Yohann Ferreira wrote:

Hi there,

Thanks to the recent work of Authenticate on Valyria Tear about SDL2, he's been able to determine that the 'top_y' or yoffset (in SDL_TTF) glyph value was the root cause of the problem.
See here: authenticate/ValyriaTear@a27d740

I'll try to sum up the what happened and what to do fix the problem:

Previously, on SDL_TTF 2.0.9 (SDL 1.2):
When caching a glyph into a surface/texture, we used to store the top_y value this way:

This is just a sampled piece of code but is taken from our actual source the most faithfully possible way:

// TTF_Font* font;

struct Glyph {
SDL_Surface* glyph;
...
int minx;
int maxx;
int miny;
int advance;
int top_y;
}
Glyph glyph;

char* character = 'j';
int minx = 0, maxx = 0, miny = 0; maxy = 0, advance = 0;
TTF_GlyphMetrics(font, character, &minx, &maxx, &miny, &maxy, &advance);

glyph.minx = minx;
...
glyph.top_y = TTF_FontAscent(font) - maxy;

Then, we were using the top_y value to place the texture when drawing, this way:

// Where to draw the text (axices (0,0) value pair is top left).
int xpos = 50;
int ypos = 50;

SDL_Rect surf_target;
surf_target.x = xpos + glyph.min_x;
surf_target.y = ypos + glyph.top_y;

Draw()

xpos += glyph.advance;

This used to work well for us for SDL1.2.

But on SDL2.0 / SDL_TTF2.0.12, it seems the top_y value aka the font Ascent minus the maxx of the glyph value was somehow set too low and the higher the glyph is, the lower it would end being displayed for us, giving the results shown on the previous screenshots.

Authenticate's work ended up in completely ignoring the maxy and ascent value of the font to place glyphs when rendering and it fixed the problem for us.
The rest of the code was basically the same.

When looking at the SDL_ttf 2.0.12 code, in SDL_ttf.c line 640.
It seems the yoffset value of the glyphs returned by Load_Glyph()
is 0 when the font isn't scalable and other more obscure conditions. And this might explain why we had the problem, since we were always assuming the yoffset aka top_y was equal to the ascent - maxy while SDL_TTF is clearly not doing this every time.

The problem may also be that in the SDL_TTF previous versions, our fonts were assumed to be scalable and answer the conditions to get a (correct?) yoffset value, while now, we have fonts not considered scalable, to the least.

The last problem we have now is that the glyph's kerning is now handled through the undocumented TTF_GetFontKerningSize() function which is unfortunately touched by this bug https://bugzilla.libsdl.org/show_bug.cgi?id=2779
The patch there looks pretty fine AFAIK, btw.

Thus, with all those conclusions, may I request you to add the TTF_GetFontKerningSize() to the SDL_TTF documentation? (Or maybe has it got to wait for the next SDL_TTF version?)
And consider pushing the patch present in 2779 if it answers the code guidelines and QA tests?

Also, do you know where I could grasp some older versions of the SDL_ttf code so that I can have a look at whether some conditions in setting the glyph metrics were changed?

Ah, and anyone, feel free to correct me if you see something wrong in what I just wrote.

Thanks a lot for reading all this and best regards,

On 2014-12-19 13:12:57 +0000, Sylvain wrote:

Hi,

Just quicky read your text. But you are rendering glyph per glyph ! That is already what SDL is doing for you!

Cheers,
Sylvain

On 2014-12-19 14:05:29 +0000, Yohann Ferreira wrote:

Hi Sylvain, :)

Just quicky read your text. But you are rendering glyph per glyph ! That is already what SDL is doing for you!

Yes, but for the need of our engine, we are storing the glyphs as part of gl texture, explaining our need to somehow extract the per-glyph rendering logic.
This is the fastest way to render text for us.

Of course, if we relied on SDL to render text, I wouldn't care about getting glyph metrics. :)

Regards,

Yohann

On 2014-12-22 20:45:58 +0000, Yohann Ferreira wrote:

Hi there,

A final comment to this before closing (Yes, I'm closing this bug :])

http://jcatki.no-ip.org:8080/SDL_ttf/SDL_ttf.html#SEC38
TTF_GLyphMetrics() documentation might need a change as now
TTF_RenderGlyph*() do render a glyph already taking in the account the baseline and computing it isn't useful anymore:
SDL_Rect rect;
int minx,maxy,advance;
TTF_GlyphMetrics(font,'g',&minx,NULL,NULL,&maxy,&advance);
rect.x=X+minx;
//rect.y=Y+TTF_FontAscent(font)-maxy; <---- Now useless
SDL_BlitSurface(glyph,NULL,screen,&rect);
X+=advance;

The latest documentation does state that this needs to be done though:
//TTF_Font *font;
//SDL_Surface *glyph,*screen;
SDL_Rect rect;
int minx,maxy,advance;
TTF_GlyphMetrics(font,'g',&minx,NULL,NULL,&maxy,&advance);
rect.x=X+minx;
rect.y=Y-maxy; <--- The font ascent doesn't need to be taken in account anymore according to the doc.
SDL_BlitSurface(glyph,NULL,screen,&rect);
X+=advance;

We could render the text just fine by removing the equivalent to removing -maxx to Y, so the bug isn't a bug anymore, just some outer logic to upgrade. Thanks for your help and patience.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch for configure.in to use pkg-config for freetype2 (configure.in.patch, text/plain, 2018-10-23 21:32:59 +0000, 1620 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2013-12-23 22:32:55 +0000, Joshua Root wrote:

Currently, SDL2_ttf's configure script uses freetype-config to find the freetype libs and cflags. The problem is that it doesn't have a flag like pkg-config's --static to distinguish between static and dynamic builds, so it always gives you the libs needed for static linking, which means you overlink in the dynamic case.

Using 'pkg-config {--libs,--cflags} freetype2' if available would avoid this problem.

Also, I'm pretty sure SDL2_ttf.pc needs to list freetype2 in its Requires: line so that 'pkg-config --libs --static SDL2_ttf' works properly.

On 2018-10-23 21:32:59 +0000, Neil Munday wrote:

Created attachment 3395
Patch for configure.in to use pkg-config for freetype2

This patch removes the reliance on freetype-config which has been removed from freetype2 and instead uses pkg-config instead.

On 2018-10-24 11:44:21 +0000, Ozkan Sezer wrote:

Fixed configury to use both pkg-config, and also freetype-config in
case it's not available.
https://hg.libsdl.org/SDL_ttf/rev/512e248bd4db
https://hg.libsdl.org/SDL_ttf/rev/268a58ec51b9

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• C source of SelectCharMap (SelectCharMap.c, application/octet-stream, 2013-07-10 04:43:03 +0000, 704 bytes)

Reported in version: 2.0.11
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2013-07-10 04:43:03 +0000, Matthias Kievernagel wrote:

Created attachment 1216
C source of SelectCharMap

See discussion on the forum:
http://forums.libsdl.org/viewtopic.php?t=9228

As noted there, I guess error handling has to be changed
to suit library style.
Currently, it returns 0 for "no error, charmap changed successfully"
and 1 for "error, invalid parameter or charmap not found".

Regards,
Matthias Kievernagel

On 2017-09-10 05:43:33 +0000, Sam Lantinga wrote:

This is a good idea, and is on the list for a future release.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch (SDL_ttf-2.0.10-cache.diff, text/plain, 2011-01-11 22:40:00 +0000, 1239 bytes)

Reported in version: 2.0.10
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2011-01-11 22:38:59 +0000, Peter Kosyh wrote:

It's like that cache of glyphs works only with symbols with codes <= 255. Se the code in SDL_ttf.c:

static FT_Error Find_Glyph( TTF_Font* font, Uint16 ch, int want )
{
int retval = 0;

if( ch < 256 ) { /* here it is. very strange approach! */
font->current = &font->cache[ch];
} else {

It is too bad, because leads to very high cpu load on slow machines. Here is a tiny patch, that makes cache more clever and speed up non english languages rendering about 50 times in my project (build wince, s60, android).

The idea is trivial:
static FT_Error Find_Glyph( TTF_Font* font, Uint16 ch, int want )
{
int retval = 0;
int hsize = sizeof( font->cache ) / sizeof( font->cache[0] );

int h = ch % hsize;
font->current = &font->cache[h];

if (font->current->cached != ch)
Flush_Glyph( font->current );

I hope (it is too hard to support own version of SDL_ttf), you will include this patch, or i can write more clever cache logic (built on list/hash).

On 2011-01-11 22:40:00 +0000, Peter Kosyh wrote:

Created attachment 552
Patch

Forgotten patch attached. :)

On 2011-02-28 15:00:04 +0000, Sam Lantinga wrote:

I'm looking at the possibility of bundling SDL_ttf with the commercial
license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_ttf
under both the LGPL and a closed-source commercial license?

Thanks!

On 2011-03-01 00:19:13 +0000, Peter Kosyh wrote:

(In reply to comment # 2)

I'm looking at the possibility of bundling SDL_ttf with the commercial
license option for SDL 1.3.

Do you give me permission to release your contributions to SDL_ttf
under both the LGPL and a closed-source commercial license?

Thanks!

Yes, you can use this patch as you want.

On 2011-03-01 01:09:20 +0000, Sam Lantinga wrote:

Thanks, your patch has been added!
http://hg.libsdl.org/SDL_ttf/rev/a6e04cc57348

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• main.c (main.c, text/plain, 2006-06-20 02:04:50 +0000, 1104 bytes)
• font.ttf (font.ttf, application/octet-stream, 2006-06-20 02:06:24 +0000, 65932 bytes)

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.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• The fixed TTF_RenderUTF8_Blended_Wrapped() function (file_2492.txt, text/plain, 2014-04-12 06:29:24 +0000, 9714 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2014-04-12 06:29:24 +0000, George Wu wrote:

Created attachment 1616
The fixed TTF_RenderUTF8_Blended_Wrapped() function

A fix for bug 2486, solving the crash problem when trying to draw English characters.
#Description:
Removed several SDL_stack_free() (SDL_free()) calls since I have changed the usage of variable 'str'. See comments in code.
#Remarks
Robustness and optimization are not assured. (Sorry but I am a newbie.)
#Known issues:
The character width calculation function utilGetGlyphWidthis still not working properly.

On 2014-04-13 19:05:00 +0000, Philipp Wiesemann wrote:

The new version of utilGetGlyphWidth() is missing for this fix to be useful. In bug 2486 it has only two parameters instead of three.

On 2014-04-14 02:24:06 +0000, George Wu wrote:

(In reply to Philipp Wiesemann from comment # 1)

The new version of utilGetGlyphWidth() is missing for this fix to be useful.
In bug 2486 it has only two parameters instead of three.

The parameter 'ch' is a dummy one, at least in current version of code. Thanks for figuring out.

On 2014-05-04 01:28:57 +0000, George Wu wrote:

I checked the code yesterday and found several spelling mistakes in comments, sorry.
By the way, I still don't get the right way to measure a glyph. I thought that maxx minx means the real width of a glyph (as shown in utilGetGlyphWidth()), which in fact is glyph->advance - glyph->minx or glyph->maxx - glyph->minx, but it works awful in my test cases. But how can it work in TTF_SizeUTF8()?
The conclusion is that, the right delimition of characters, including Western and Asian ones, is completed. However, measuring them is still a problem.

On 2019-01-31 14:03:47 +0000, Sylvain wrote:

For complex text shaping you may want either:

Bug 3211 - Complex text layout support
Bug 3046 - SDL_ttf + HarfBuzz

On 2019-10-23 09:15:18 +0000, Sylvain wrote:

So this is fixed with previous patches

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, Other

Comments on the original bug report:

On 2012-01-27 12:15:21 +0000, wrote:

Hello,

We're going to ship this patch with the Debian packages, and I think you are maybe interested in incorporating it upstream, otherwise our package fails to build in some circumstances (e.g. with gold linker, or when using --as-needed flags; both of which are common in Debian and Ubuntu).

http://anonscm.debian.org/gitweb/?p=pkg-sdl/packages/sdl-ttf2.0.git;a=blob;f=debian/patches/link_libm_ftbfs_binutils-gold;h=c4340971fa55b6e0632c327e52b7ab6523a34716;hb=7fe2cd8851d9a68b855af29b708154c1d4327672

I don't think that you want to incorporate the patch as is, but well, you get the idea :-)

Regards.

On 2013-08-13 17:16:06 +0000, wrote:

Could you please try to take again a look at this patch?

Fixing it upstream should be straightforward and harmless and it would make easier for packagers to not have to carry the patch release after release.

On 2013-09-02 20:43:19 +0000, Julian Ospald wrote:

Gentoo is going to apply this too, however adding "-lm" to LDFLAGS is not the way to go.

--- a/Makefile.am
+++ b/Makefile.am
@@ -35,6 +35,7 @@
-release $(LT_RELEASE)
-version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
endif
+libSDL2_ttf_la_LIBADD = @mathlib@

pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = SDL2_ttf.pc

On 2013-09-05 13:52:37 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_ttf/rev/e826b2504c66

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL_ttf.c.patch (SDL_ttf.c.patch, text/plain, 2006-04-01 19:44:43 +0000, 760 bytes)
• render embbeded bitmap/graymap correctly (SDL_ttf.c.embedded-bitmap.patch, text/plain, 2006-07-29 23:52:15 +0000, 4541 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-04-01 19:41:25 +0000, Kouya Sakamoto wrote:

Hi,

SDL_ttf can't properly render some size of TrueType font which has embedded bitmaps
in case of using TTF_Render..._Shaded() or TTF_Render..._Blended() function.
As its result, we get block images filled noise.

Attached patch prevent this problem by loading only outlined glyph
if it was called from above functions with scaled font.

Regards.

On 2006-04-01 19:44:43 +0000, Kouya Sakamoto wrote:

Created attachment 99
SDL_ttf.c.patch

On 2006-05-01 05:39:25 +0000, Sam Lantinga wrote:

Can you attach a link to a test font and a showfont command line, so I can test this out?

On 2006-05-06 22:39:58 +0000, Kouya Sakamoto wrote:

I'm sorry that should have attached this.

Sazanami Font is used well in Linux as Japanese font.
http://osdn.dl.sourceforge.jp/efont/10087/sazanami-20040629.tar.bz2
Following command reproduce the issue:

showfont sazanami-gothic.ttf

There is no problem when you put a "-solid" option to command line.

showfont -solid sazanami-gothic.ttf

When I set a ptsize to between 8 and 21 with the font, I get a strange result. And I also reproduce the issue with some truetype fonts using generally in Linux as Japanese font, and fonts that come with Windows.

On 2006-07-21 00:08:21 +0000, TOYAMA Shin-ichi wrote:

We met this bug on Tux Paint(Drawing Program for Children: http://www.newbreedsoftware.com/tuxpaint/), and I confirmed that proposed patch is effective to fix this problem.

Until now, with "Kochi" family fonts which has been mostly used as Japanese font on Linux, this bug appears only when relatively small font size (less than 16 point) is specified, so it seems remained unreported.

But with "Sazanami" font, which should be alternative to "Kochi" fonts somtime soon, this bug appears up to 21 point, so this will become more serious.

On 2006-07-29 23:52:15 +0000, KANOU Hiroki wrote:

Created attachment 155
render embbeded bitmap/graymap correctly

FT_IS_SCALABLE() means that the font is in outline format,
but does not imply that outline is rendered as 8-bit grayscale,
because embedded bitmap/graymap is preferred (see FT_LOAD_DEFAULT
section of FreeType2 API Reference).

I fixed Load_Glyph() to look at the actual number of depth (bits
per pixel) of rendered bitmap/graymap. This patch includes
additional support for graymap in two- or four-bit per pixel.
(FontForge supports the creation of embedded graymap in TTF).

On 2007-07-14 23:18:52 +0000, Sam Lantinga wrote:

This is fixed in subversion revision 3284, thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Rename the original solution to *_VS2008 (SDL_ttf_235.patch, text/plain, 2013-05-31 10:07:30 +0000, 66965 bytes)
• Rewired the solution to *_VS2008 (SDL_ttf_236.patch, text/plain, 2013-05-31 10:08:34 +0000, 1685 bytes)
• Added new *_VS2012 files (SDL_ttf_237.patch, text/plain, 2013-05-31 10:09:12 +0000, 50946 bytes)

Reported in version: unspecified
Reported for operating system, platform: Windows 7, x86

Comments on the original bug report:

On 2013-05-31 10:06:18 +0000, Jan Reitz wrote:

VS2012 project file is non existant.
I have prepared a patch where SDL2_ttf, glfont and showfont can be compiled and run under VS2012. Project files are very close to the project files from SDL_image, so most likely as bug-free as the SDL_image ones.

On 2013-05-31 10:07:30 +0000, Jan Reitz wrote:

Created attachment 1160
Rename the original solution to *_VS2008

Rename the original solution to *_VS2008

On 2013-05-31 10:08:34 +0000, Jan Reitz wrote:

Created attachment 1161
Rewired the solution to *_VS2008

On 2013-05-31 10:09:12 +0000, Jan Reitz wrote:

Created attachment 1162
Added new *_VS2012 files

On 2013-05-31 10:13:59 +0000, Jan Reitz wrote:

CC += [email protected]

Because he made the other VS2012 files in SDL.

On 2013-06-08 22:15:16 +0000, Andreas Schiffler wrote:

VS2010 and VS2012 solutions added with:
http://hg.libsdl.org/SDL_ttf/rev/efd80e6edf64

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Mac OS X 10.6, x86_64

Comments on the original bug report:

On 2010-03-03 11:56:47 +0000, Vittorio Giovara wrote:

SDL_ttf and SDL_net are the only two mainstream sdl projects that aren't shipped with the x86_64 architecture in Mac OS X framework bundle.
It is possible to compile the missing architecture from the latest svn sources.

would it be feasable to make a version bump to include latest mods and to ship a three-way universal framework bundle?

On 2010-07-08 04:04:07 +0000, Sam Lantinga wrote:

SDL_ttf 2.0.10 is now available. :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL2_ttf fix for using on iOS platform (SDL2_ttf.patch, text/plain, 2014-01-03 04:08:55 +0000, 2277 bytes)

Reported in version: 2.0.11
Reported for operating system, platform: iOS 6, iPhone/iPod touch

Comments on the original bug report:

On 2014-01-03 04:08:55 +0000, Jeffrey Carpenter wrote:

Created attachment 1511
SDL2_ttf fix for using on iOS platform

Linking to SDL2_ttf in an application fails -- said app dumps the terminal usage text of the apinames utility and then immediately exits.

This is because of external/freetype/apinames.c being compiled into SDL2_ttf. Removing this file from compiling within the supplied iOS xcode project file fixes the problem for me.

Cheers!
Jeffrey Carpenter [email protected]

On 2014-06-23 09:10:45 +0000, Davide Coppola wrote:

confirmed in 2.0.12 and in mercurial.

A fix is straightforward and takes only few seconds, just remove apinames.c from the project.

On 2014-06-24 09:04:54 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL_ttf/rev/b4e2b0ac9723

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-06-25 17:40:11 +0000, Samuel Mimram wrote:

Dear Developers!

Sometimes the "something" text is as wide as "somethingi". I wrote a line editor
for SDL, and it is a problem for me to determine the cursor position in pixels.
(I cannot say precisely the with of the text on the cursor's left side)
My wish is that the rendered surface be exactly as wide as the rendered text.

The second is that TTF_RenderText_Shaded() and TTF_RenderText_Solid() should have an "SDL_PixelFormat *format" parameter, so the newly generated surface would fit in the application instantly without any additional blitting.

I know it is not christmas so my third wish is very very optional. Make a
function with the name of TTF_RenderText_AlphaShaded(). It would be a mix of the
...Solid and the ...Shaded. The RGB channels would be filled with the ...Solid
algorythm and the Alpha channel would be filled with the ...Shaded algorythm. The result would be instant for blitting onto the screen. (The surface would be
always 32bit and the untouched areas of the surface would be transparent black)

Thanks for the TTF library! You saved my life ;-)
Thanks for reading my wishes!
I hope you will find useful the above.

More infos on the Debian bug report can be found at :
http://bugs.debian.org/206057

On 2006-06-30 04:33:35 +0000, Nicos wrote:

A workaround: scan the resulting surface from left and from the right and find the x for the first non non-transparent pixel for each side. Subtracting those values from the width will give you the "true" width.