Support for TrueType (.ttf) font files with Simple Directmedia Layer.

Over at pygame we got an issue report after updating to SDL_ttf 2.0.18 that rendering a font that previously worked segfaulted their program. It only seems to segfault at certain sizes.

I wanted to be sure this was a problem at the C level, and not an unrelated regression by pygame, so I put together a small test script.

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

int main(int argc, char *argv[])
{
    SDL_SetMainReady();
    SDL_Init(SDL_INIT_VIDEO);

    SDL_Window *window = NULL;
    SDL_Surface *screen = NULL;

    window = SDL_CreateWindow("Example", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 500, 150, SDL_WINDOW_SHOWN);

    screen = SDL_GetWindowSurface(window);
    SDL_FillRect(screen, NULL, SDL_MapRGBA(screen->format, 0, 0, 120, 255));

    printf("running on patch level %i\n", SDL_TTF_PATCHLEVEL);

    TTF_Init();

    // font size 70 = segfault, 20 = fine
    TTF_Font* f = TTF_OpenFont("PlayfairDisplay-Regular.ttf", 20);
    printf("error=%s\n", SDL_GetError());

    SDL_Color white;
    white.r = 255;
    white.g = 255;
    white.b = 255;
    white.a = 255;

    //SDL_Surface *text = TTF_RenderText_Blended(f, "Hello world", white);
    SDL_Surface *text = TTF_RenderUTF8_Blended(f, "Hello world", white);
    printf("text=%p\n", text);
    printf("error=%s\n", SDL_GetError());

    SDL_BlitSurface(text, NULL, screen, NULL);
    printf("error=%s\n", SDL_GetError());

    SDL_UpdateWindowSurface(window);
    printf("error=%s\n", SDL_GetError());

    // Keep the main loop until the window is closed (SDL_QUIT event)
    int exit = 0;
    SDL_Event eventData;
    while (!exit)
    {
        while (SDL_PollEvent(&eventData))
        {
            switch (eventData.type)
            {
            case SDL_QUIT:
                exit = 1;
                break;
            }
        }
    }

    SDL_Quit();

    return 0;
}

Both pygame and my test script are compiled with Visual Studio, and use the 64 bit dev VS SDL_ttf 2.0.18 release. I tried to replicate this bug on my Mac, but I was unable to.

Running this in the VS debugger yields: Unhandled exception at 0x00007FFDE6C723F6 (ntdll.dll) in SDL_c_test.exe: 0xC0000028: An invalid or unaligned stack was encountered during an unwind operation. ^ This pops up over the call to TTF_RenderUTF8_Blended

Call stack:

This hits the playfair family, at least regular and semibold (those are the ones I tested). PlayfairDisplay-Regular.zip

I also tested this through pygame with all the system fonts pygame could detect, and got failures on the fonts

algerian, castellar, gigi, imprintshadow, blackadderitc, edwardianscriptitc, kunstlerscript
maturascriptcapitals, oldenglishtext, msoutlook, parchment, vivaldi, vladimirscript

FreeType and Zlib appear to be embedded in SDL2_ttf-2.0.18.dll rather than being supplied as separate DLLs as previously. Unfortunately this means that functions in FreeType and Zlib which were previously exported, and could be called by the main application (for example my app calls FT_Library_Version() and gzopen() etc.), are no longer available.

Can I request that if FreeType and ZLib are going to be embedded, their public functions are added to the DLL's export table.

Hello. This covers part of #160.

I probably did plenty of stuff wrong.

The challenging bit was getting the underlines and strikethroughs to move with the text, so I added another parameter to drawLine that moves everything over on the x.

• Adds TTF_WITH_HARFBUZZ option to enable/disable harfbuzz
• Adds TTF_WITH_FREETYPE_VENDORED and TTF_WITH_HARFBUZZ_VENDORED options to enable/disable vendoring.
• The export of targets + generation of the .pc file was already there, so I only needed to add support for the vendored libraries there
• add 'd' suffix for debug libraries
• allow parallel installation of shared/static libraries in the same install prefix (mostly useful for linux distributions)
• when building a debug SDL_ttf library, also create a libsdl2_ttfd.so shared library

A prefix might look like this:

prefix
├── include
│   └── SDL2
│       └── SDL_ttf.h
├── lib64
│   ├── cmake
│   │   └── SDL2_ttf
│   │       ├── SDL2_ttfConfig.cmake
│   │       ├── SDL2_ttfConfigVersion.cmake
│   │       ├── SDL2_ttf-shared-targets.cmake
│   │       ├── SDL2_ttf-shared-targets-debug.cmake
│   │       ├── SDL2_ttf-shared-targets-release.cmake
│   │       ├── SDL2_ttf-static-targets.cmake
│   │       ├── SDL2_ttf-static-targets-debug.cmake
│   │       └── SDL2_ttf-static-targets-release.cmake
│   ├── libSDL2_ttf-2.0d.so -> libSDL2_ttf-2.0d.so.0
│   ├── libSDL2_ttf-2.0d.so.0 -> libSDL2_ttf-2.0d.so.0.1900.0
│   ├── libSDL2_ttf-2.0d.so.0.1900.0
│   ├── libSDL2_ttf-2.0.so -> libSDL2_ttf-2.0.so.0
│   ├── libSDL2_ttf-2.0.so.0 -> libSDL2_ttf-2.0.so.0.1900.0
│   ├── libSDL2_ttf-2.0.so.0.1900.0
│   ├── libSDL2_ttf.a
│   ├── libSDL2_ttfd.a
│   ├── libSDL2_ttfd.so -> libSDL2_ttf-2.0d.so.0
│   ├── libSDL2_ttf.so -> libSDL2_ttf-2.0.so.0
│   └── pkgconfig
│       └── SDL2_ttf.pc
└── share
    └── licenses
        └── SDL2_ttf
            └── COPYING.txt

@rmg-nik can you please test this?

Fixes #101 Fixes #208

I'm getting "Couldn't find glyph" with libfreetype 2.11. The same executable works fine when I dynamically link it with libfreetype 2.10.4.

This is for last release of SDL_ttf (2.0.15). Apparently Windows' pacman, Homebrew, probably Nix and possibly many more package SDL_ttf with libfreetype 2.11, so this is a disaster.

The full error is

LambdaHack --dbgMsgSer --logPriority 1
INFO: OpenGL shaders: ENABLED
INFO: Created renderer: opengl
DEBUG: Couldn't find glyph
LambdaHack: SDLCallFailed {sdlExceptionCaller = "SDL.Font.shadedGlyph", sdlFunction = "TTF_RenderGlyph_Solid", sdlExceptionError = "Couldn't find glyph"}

and it happens always and right after opening a window in this application

https://github.com/LambdaHack/LambdaHack

e.g., you can always see this in this executable built on Windows

https://ci.appveyor.com/api/buildjobs/qtf0mr42l38b3cvq/artifacts/Allure_0.10.3.0-dev-2021-10-19_windows-x86_64.zip

and probably with this executable on Linux, if you run it in a system with libfreetype 2.11

https://github.com/LambdaHack/LambdaHack/suites/4095162996/artifacts/104398309

It looks similar to the error in #119, but I can't fix it by using a newer SDL_ttf, because my Homebrew, Debian, Nix and other users use whatever version package managers give them (and whichever libfreetype version). Also, for package containing SDL_ttf and related libraries, CIs that I use to build packages decide which versions of the libraries to provide.

What to do?

This is a request, if possible, to add support for ClearType-style LCD rendering, which FreeType already seems to support.

This makes smaller font sizes more readable, by basically using the R G and B portions of every pixel as additional subpixels with different luminance levels.

maybe a new hinting type would be a good place to set the feature on. like : TTF_SetFontHinting(mainFont, TTF_HINTING_LCD_SUBPIXEL);

Similar to https://github.com/libsdl-org/SDL_mixer/pull/383. This is my last PR like this, unless someone is particularly interested in SDL_rtf (which isn't in the Steam Runtime or Debian).

• Revert "Make it possible to build with older SDL (for GitHub CI)"

  SDL < 2.0.10 would have freed the memory with SDL_free(pixels) rather than SDL_SIMDFree(pixels), which is invalid when pixels is a pointer into the middle of a malloc-allocated block.

  SDL_SIMDFree(pixels) expects the pointer pixels to be like this, with a poitner to the malloc'd block "behind" the texture data:

              sizeof(void*)
                |<--->|
    [ unused    | ptr | texture data...               ]
       ^                 ^
       |                 |
      ptr               pixels
  
    |<-- malloc'd block                            -->|
  

  which is also what this function has been constructed to do.

  This reverts commit 9a86e3f1e167f9d117a1723c67c802cda1a48e3a.

• Relax required SDL version to 2.0.10

  Commit 99f64c8 bumped the dependency to 2.0.12, but in fact 2.0.10 should be enough for SDL_SIMD_ALIGNED.

• workflows: Add basic CI using Github Actions

• workflows: Run showfont

  We can't be very thorough here, but this is a simple check that it's working at all.

• build: Use minor version number for feature releases

  Similar to what has been done in SDL itself, this allows micro versions with an odd minor version to be used as prereleases for a stable release. It also allows micro versions with an even minor version to be used to fix regressions in their corresponding .0 release if that becomes necessary.

• cmake: On Unix, make the library ABI-compatible with the Autotools build

  This is not yet implemented for macOS, only for generic Unix (in practice meaning Linux and *BSD).

With SDL2 2.0.16 being released a few hours ago, and plenty of new additions to SDL_ttf since the last release in 2019, I was wondering whether there was a similar target release date for SDL_ttf 2.0.16? I maintain the Python bindings for SDL2 and its add-on libraries (ttf, image, mixer), so I'm just trying to get an idea of when I'll need to update my bindings to support the new set of functions.

Thanks in advance!

• Use SDL2TTF_ prefix for all options
• Create SDL2_ttf::SDL2_ttf when building a shared library, create SDL2_ttf::SDL2_ttf-static when building a static library
• Use same CMake layout as SDL_image/SDL_mixer
• Create libSDL2_ttfd.so symbolic link (when building debug build type)
• Add PrivateSdlFunctions.cmake script for common functionality between SDL_image/SDL_mixer
• Add FindXXX.cmake scripts for dependencies that don't provide cmake configuration files
• Add CMakeLists.txt + cmake scripts to source distribution (EXTRA_DIST of autotools)
• Test CMake on mingw64 (using system dependencies there)
• Add MacOS CI
• Create symbolic link at build time + install it
• Only install SDL2_ttf.pc when building a shared SDL2_ttf (to avoid overwriting when later installing a static SDL2_tff)
• Allow parallel installation with cmake support of a static and shared SDL2_ttf
• Fixes CMake Macos versioning
• add MSVC to the CI test matrix
• test the installed cmake scripts

Fixes #141 Fixes #143 Fixes #226

I posted this under the SDL_ttf pre release announcement on Discourse, but I also wanted to raise it here. Especially since this behavior will need to be supported as is after a release, for backwards compatibility.

I’ve been playing around with the wrapped text functions, and I’m concerned about how they handle small wrap values.

At wrap length 0, the text renders as a single line, and newline characters are still rendered as unknown characters. I expected this to behave like the normal text rendering functions but newline aware.

With a positive but very small wrap length, the text doesn’t fully show up. Or parts of letters might show up. I expected this to allocate at least enough space to put at least one character of the input string on each line.

Pinging the author of the functions @1bsyl. Thank you for all the work keeping SDL_ttf golden!

I have trouble building the project using MinGW-w64 toolchain.

For CMake approach:

• CMake script is written so that it only expects CMake-based builds, it searches for *.cmake files but I have only *.pc files for pkg-config (I could make a PR to make a CMake option to use pkg_check_modules() instead of FindPackage() - please let me know if you could accept such change)
• CMake script contains outdated SDL_ttf version information

For configure approach:

• The script works but incorrectly attempts to check for OpenGL support which results in OpenGL unnecessarily disabled

configure.log:

configure:13738: checking for OpenGL support
configure:13758: gcc -o conftest.exe -g -O2 -IC:/usr/include/freetype2 -IC:/usr/include/libpng16 -IC:/mingw64/mingw64/include -Dmain=SDL_main -IC:/usr/SDL2-2.0.10/x86_64-w64-mingw32/include/SDL2   conftest.c  -LC:/usr/lib -LC:/mingw64/mingw64/lib -lfreetype -lpng16 -lz -lbz2 -LC:/usr/SDL2-2.0.10/x86_64-w64-mingw32/lib -lmingw32 -lSDL2main -lSDL2 -mwindows -lGL >&5
C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lGL
collect2.exe: error: ld returned 1 exit status

The library is named opengl32, not GL on Windows.

I have a use case to draw UTF-8 encoded strings on screen with a type writer effect. A type writer effect gives users the impression that text is being typed onto the screen.

As far as I can tell the SDL_ttf API does not support fetching code points or human perceived characters, grapheme clusters, from UTF-8 strings. If I got the implementation right the library is able to convert UTF-8 encoded grapheme clusters to UTF-32 code units using both FreeType and Harfbuzz internally, but does not expose these capabilities to the users.

Would it be possible to expose such an API?

I'm trying to install SDL_ttf on OSX Monterey from the repo. I created a symlink in external pointing to my harfbuzz source, and copied the .deps directory over. It compiles fine until it hits this: make: *** No rule to make target external/harfbuzz/src/hb-ms-feature-ranges.cc', needed byexternal/harfbuzz/src/libSDL2_ttf_la-hb-ms-feature-ranges.lo'. Stop.

Has something been deprecated? I'm not seeing that file anywhere in the harfbuzz source, only a header.

It appears that when we say "Unicode" in SDL_ttf, we mean UCS-2 encoding (each char is 16-bits).

This covers the Basic Multilingual Plane, which covers an enormous amount of human language, but it does not cover the entirety of Unicode...and while probably no one cares about, I don't know, Klingon, the limitation means it can't do emoji glyphs, which people care about a lot.

The doesn't-break-ABI solution here is to say the "UNICODE" functions take UTF-16 encoding, which is an extension of UCS-2...most characters are the same, but there's some magic extension bits to make some codepoints take a two 16-bit value sequence, which gets you access to values > 0xFFFF. This is what win32 ended up doing, in WinXP or so, so all their Unicode functions didn't change but could handle the higher values when they show up in a string. UTF-16 is kind of the worst of all worlds: variable size like UTF-8 but wastes bits like UCS-4...but it gets the job done in a backwards compatible way.

If we want to break ABI, change the Unicode functions to take a Uint32 instead of a Uint16 (UCS-4 encoding)...each codepoint takes 32 bits and we're good to go.

Otherwise, probably look for STR_UNICODE in the source code and see where it gets used, and clean out UCS-2isms.

(If we do nothing, these higher codepoint values are available to apps if they encode their strings in UTF-8, since that can already represent those values.)

This needs to be given a valid font as a command-line argument, but is otherwise automatic.

Includes #223.

I haven't wired this up to the CMake build system or the CI, because I don't want to put this on the critical path for 2.20.0, but it does seem to work.

It seems to me ARM_NEON is working and could be re-activated: https://github.com/libsdl-org/SDL_ttf/blob/main/SDL_ttf.c#L122

diff --git a/SDL_ttf.c b/SDL_ttf.c
index 8a4bb3d..68909ea 100644
--- a/SDL_ttf.c
+++ b/SDL_ttf.c
@@ -119,7 +119,7 @@ int TTF_SetScript(int script) /* hb_script_t */
 #endif
 
 /* Round glyph width to 16 bytes use NEON instructions */
-#if 0 /*defined(__ARM_NEON)*/
+#if defined(__ARM_NEON)
 #  define HAVE_NEON_INTRINSICS 1
 #endif

Simplify by using SDL_SIMDAllocAligned()

need this PR first: https://github.com/libsdl-org/SDL/pull/5650 See https://github.com/libsdl-org/SDL/issues/5641