SDL_ttf: "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?

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 19 (6 by maintainers)

Most upvoted comments

Hello, at Solarus Games we are facing the same issue since June 2021, but after reading this issue I managed to narrow it down to a specific font and size used in one of our games.

First and foremost, I can confirm that the issue is in the combination (FreeType 2.11 + SDL2_ttf 2.0.15) and works fine with (FreeType 2.11 + SDL2_ttf main). This on a standard MSYS2 installation in Windows 10.

The font in question is a very common font used for Chinese languages and is in here (get the .tar.gz file): https://sourceforge.net/projects/wqy/files/wqy-zenhei/0.8.38 (Pangu)/

After unpacking the tar archive, the font is in the wqy-zenhei.ttc file.

The test code is based on the snippet in https://github.com/libsdl-org/SDL_ttf/issues/152#issuecomment-948522751 :

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

int main(int argc, char** argv) 
{
   SDL_Window* win;
   int w = 700;
   int h = 300;

   if((SDL_Init(SDL_INIT_VIDEO) != 0))
   {
      printf("[!] can't initialize SDL %s\n", SDL_GetError());
      exit(-1);
   }

   if(!(win = SDL_CreateWindow("Local Video", 0, 0, w, h, SDL_WINDOW_SHOWN | SDL_WINDOW_BORDERLESS)))
   {
      printf("[!] can't create Window %s\n", SDL_GetError());
      exit(-1);
   }

   SDL_Renderer *ren = NULL;
   ren = SDL_CreateRenderer(win, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);
   if (ren == NULL){
      printf("[!] can't create Renderer %s\n", SDL_GetError());
      return 1;
   }

   // Select the color for drawing. 
   SDL_SetRenderDrawColor(ren, 255, 255, 255, 255);

   SDL_RenderClear(ren);
   SDL_Surface *surf1 = NULL;
   SDL_Surface *surf2 = SDL_CreateRGBSurface(0, w/10, h/10, 16, 0, 0, 0, 0);
   {
      TTF_Font *font;
      const char * fontname = "wqy-zenhei.ttc";
      int sz = 16; // [12-16]: see below in surf1 == NULL check
      const char  *txt = "中文（中国）";
      SDL_Color c1;
      SDL_Color c2;
      int i1;
      int i2;
      i1 = SDL_MapRGB(surf2->format, 0x80, 0x00, 0x00); // Red
      i2 = SDL_MapRGB(surf2->format, 0x80, 0x80, 0x80); //

      SDL_GetRGB(i1, surf2->format, &(c1.r), &(c1.g), &(c1.b));
      SDL_GetRGB(i2, surf2->format, &(c2.r), &(c2.g), &(c2.b));

      TTF_Init();

      font = TTF_OpenFont(fontname, sz);
      if (font == NULL)
      {
         printf("no font!\n");
         exit(1);
      }

      surf1 = TTF_RenderUTF8_Shaded(font, txt, c1, c2);
      if (surf1 == NULL)
      {
         // with sizes [12-16]: broken in FreeType 2.11 + SDL_ttf 2.0.15 / works in FreeType 2.11 + SDL_ttf 'main'
         // with other sizes, the surface is created successfully
         printf("could not render TTF surface!\n");
         exit(1);
      }
   }

   SDL_Texture *tex1 = SDL_CreateTextureFromSurface(ren, surf1);

   {
      SDL_Rect srcrec;
      SDL_Rect dstrec;
      srcrec.x = 0;
      srcrec.y = 0;
      srcrec.w = surf1->w;
      srcrec.h = surf1->h;
      dstrec.x = 20;
      dstrec.y = 20;
      dstrec.w = surf1->w;
      dstrec.h = surf1->h;
      SDL_RenderCopy(ren, tex1, &srcrec, &dstrec);
   }

   SDL_RenderPresent(ren);
   SDL_FreeSurface(surf1);
   SDL_Delay(3000);
   SDL_DestroyTexture(tex1);
   SDL_DestroyRenderer(ren);
   SDL_DestroyWindow(win);
   SDL_Quit();
   return 0;
}

@1bsyl given that this works as expected in SDL2_ttf main, we are looking very forward for a release of SDL_ttf 2.0.16 😃

hhromic on Oct 21, 2021

It’s been fixed on master a couple of months ago and still no release, so the only hope is that (some) distros apply the patch by hand, but we are probably not in that age any more — many packages, many users, few volunteers.

I think I will just leave it be and create a workaround for now. @NickMcConnell: if Angband SDL frontend users start complaining at some point, just ask them to downgrade (or upgrate, if available at that point) freefont (or SDL_ttf, if available at that point). There is now 16x16xw.woff in Angband, so at least one font should still work. 😃

Mikolaj on Oct 21, 2021