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

Overview
This library is a wrapper around the excellent FreeType 2.0 library,
available at:
	http://www.freetype.org/

This library allows you to use TrueType fonts to render text in SDL
applications.

To make the library, first install the FreeType library, then type
'./configure' then 'make' to build the SDL truetype library and the
showfont and glfont example applications.

Be careful when including fonts with your application, as many of them
are copyrighted.  The Microsoft fonts, for example, are not freely 
redistributable and even the free "web" fonts they provide are only 
redistributable in their special executable installer form (May 1998).
There are plenty of freeware and shareware fonts available on the Internet
though, and may suit your purposes.

This library is under the zlib license, see the file "COPYING.txt" for details.

Portions of this software are copyright © 2013 The FreeType Project (www.freetype.org).  All rights reserved.

Enjoy!
	-Sam Lantinga 		(6/20/2001)
Comments
  • Segfault on Windows 2.0.18 release for certain fonts/sizes

    Segfault on Windows 2.0.18 release for certain fonts/sizes

    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: Capture

    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
    
    opened by Starbuck5 23
  • FreeType and ZLib functions no longer exported

    FreeType and ZLib functions no longer exported

    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.

    opened by rtrussell 22
  • Add left/right/center align support to wrapped text

    Add left/right/center align support to wrapped text

    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.

    opened by Starbuck5 21
  • Add support for vendored libraries in CMake

    Add support for vendored libraries in CMake

    • 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

    opened by madebr 19
  • "Couldn't find glyph" with libfreetype 2.11, works fine with 2.10.4

    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?

    opened by Mikolaj 19
  • ClearType-style LCD rendering

    ClearType-style LCD rendering

    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. image

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

    opened by andre-barata 19
  • Use minor version for feature releases

    Use minor version for feature releases

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

    opened by smcv 18
  • Release 2.0.16 ETA?

    Release 2.0.16 ETA?

    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!

    opened by a-hurst 17
  • Cmake work

    Cmake work

    • 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

    opened by madebr 16
  • Behavior of

    Behavior of "Wrapped" with small lengths

    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!

    opened by Starbuck5 9
  • build script enhancements

    build script enhancements

    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.

    opened by Xeverous 9
  • Failing to compile with harfbuzz 4.4.1

    Failing to compile with harfbuzz 4.4.1

    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.

    opened by mikelatiolais 0
  • "Unicode" means "UCS-2"

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

    opened by icculus 8
  • Add a semi-automatic test for #221

    Add a semi-automatic test for #221

    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.

    opened by smcv 4
  • Re-enable HAVE_NEON_INTRINSICS

    Re-enable HAVE_NEON_INTRINSICS

    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
    
    
    opened by 1bsyl 7
  • Simplify by using SDL_SIMDAllocAligned()

    Simplify by using SDL_SIMDAllocAligned()

    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

    opened by 1bsyl 1
  • TTF_RenderUTF8_Blended very very slow in Android

    TTF_RenderUTF8_Blended very very slow in Android

    It takes more than 1 second to run this function...

    QQ20220404-200106@2x

    SDL_Color oColor = {0xFF, 0xFF, 0xFF};

    for (auto s : oMsgVec) { auto nStart = SDL_GetTicks64();

    TTF_RenderUTF8_Blended(pFontHelper->m_pFont, s.c_str(), oColor);
    
    auto nEnd = SDL_GetTicks64();
    
    SDL_Log("%s: time = %d", s.c_str(), nEnd - nStart);
    

    }

    opened by iBruCe07 4
Releases(release-2.20.1)
Owner
Simple Directmedia Layer
Simple Directmedia Layer (SDL) is a framework for creating cross-platform games and applications.
Simple Directmedia Layer
A font cooking library

Font Chef Font Chef is a cross-platform C99 and C++ library to create character atlas of pre-rasterized glyphs from a font at a specified size and col

Leonardo Guilherme de Freitas 45 Apr 25, 2022
C++ font-lock for Emacs

Syntax highlighting support for "Modern C++" - until C++20 and Technical Specification. This package aims to provide a simple highlight of the C++ lan

Ludwig PACIFICI 168 Jul 13, 2022
font rendering, Zep vim emulator, microui integration

LabFont This project is an exploration of getting text into a rendeing pipeline based on @floooh's sokol. Frameworks such as Dear ImGui solve text ren

Nick Porcino 14 Sep 11, 2022
Portable, Noto-powered font-rendering abstraction based on FreeType and Raqm

Mechascribe Mechascribe is still under construction and nothing is functional yet. Mechascribe is a text rendering abstraction trying to support as mu

null 4 Jan 27, 2022
A terminal-based, mouse-driven BDF (bitmap) font editor.

bdfedit A terminal-based, mouse-driven BDF font editor. Capable of reading, writing, and editing bitmap font files fully within the terminal, and enti

Andrew 6 Oct 25, 2022
Free (libre) font editor for Windows, Mac OS X and GNU+Linux

FontForge FontForge is a free (libre) font editor for Windows, Mac OS X and GNU+Linux. Use it to create, edit and convert fonts in OpenType, TrueType,

null 4.9k Nov 22, 2022
cross-platform bitmap font implementation

Component for rendering text with bitmap font on all openfl targets. This set of classes is heavily based on classes from pixelizer (https://github.co

Zaphod 49 Oct 26, 2021
Filter driver which support changing DPI of mouse that does not support hardware dpi changing.

Custom Mouse DPI Driver 하드웨어 DPI 변경이 불가능한 마우스들의 DPI 변경을 가능하게 하는 필터 드라이버 경고: 해당 드라이버는 완전히 테스트 되지 않았습니다 Install 해당 드라이버는 서명이 되어있지않습니다. 드라이버를 사용하려면 tests

storycraft 4 Sep 23, 2022
A Visual Studio extension that provides enhanced support for editing High Level Shading Language (HLSL) files

HLSL Tools for Visual Studio This extension is for Visual Studio 2017 / 2019. Go here for the Visual Studio Code extension. HLSL Tools is a Visual Stu

Tim Jones 429 Nov 26, 2022
layer to control the global priority of any vulkan application

vk-force-priority vk-force-priority allows you to control the global priority of any vulkan application. Building from Source Dependencies Before buil

Georg Lehmann 5 Sep 2, 2021
A data plane framework that supports any layer-7 protocols.

中文 meta-protocol-proxy Why MetaProtocol is needed? Almost all open source and commercial Service Meshes currently support only two Layer-7 protocols -

Aeraki 56 Oct 17, 2022
Application layer for sounding rockets software

Lynx On-Board Software The on-board software represents the top layer of the rocket's firmware. This includes all the logics needed for a successful f

Skyward Experimental Rocketry 4 Apr 13, 2022
Yet another abstraction layer - a general purpose C++ library.

Yet Another Abstraction Layer What yaal is a cross platform, general purpose C++ library. This library provides unified, high level, C++ interfaces an

Marcin Konarski 14 Jul 27, 2022
Wayfire plugin for handling touchpad gestures globally in a layer-shell surface

wf-globalgestures Global touchpad gestures plugin for Wayfire: implements a special protocol (also in this repo) that lets clients request that a part

null 3 Oct 3, 2022
Translation layer from ANARI to OSPRay, ANARILibrary and ANARIDevice "ospray".

ANARI-OSPRay Translation layer from Khronos® ANARI™ to Intel® OSPRay: ANARILibrary and ANARIDevice "ospray". Status This is an experimental project, v

OSPRay 8 Aug 30, 2022
Webusb-libusb - Translation layer from libusb to webusb.

webusb-libusb IMPORTANT: This implementation requires a patched version of Emscripten to work properly. This project is a translation layer from libus

Luigi Cruz 49 Jul 23, 2022
A Direct3D9 to Vulkan layer using the DXVK backend. [Upstreamed to DXVK]

This work has been upstreamed and is continuing development there This repo is only open for the remaining issues on the tracker https://github.com/do

Joshie 808 Dec 1, 2022
A d3d9 and d3d10 to d3d11 translation layer.

DXUP A D3D9 and D3D10 -> D3D11 Translation Layer Get latest build here or tagged builds here. What's the point? The main reason is for DXVK, a D3D11->

Joshie 242 Nov 18, 2022
This program converts ASCII STL files to RT files for miniRT.

STL to RT This program converts ASCII STL files to RT files for miniRT. Input the ASCII STL file to the standard input and output the RT file from the

null 5 Mar 29, 2021