SDL_ttf icon indicating copy to clipboard operation
SDL_ttf copied to clipboard

Lock emoji issue

Open rpx99 opened this issue 1 year ago • 11 comments

Screenshot_2023-12-18_09-34-42 Dear SDL_TTFs,

I am running the LEM editor with SDL2 GUI on OpenBSD. LEM uses a LOCK symbol in it's modeline to indicate a read-only buffer.

Unfortunately this does cause an error and I believe it is due to SDL_TTF.

Here is what's happening using the cl-sdl2-ttf package with sbcl (Steel Bank Common Lisp):

* (make-string 1 :initial-element #\LOCK) "🔒"

* (SDL2-TTF:RENDER-UTF8-BLENDED (sdl2-ttf:open-font #P"/home/rpx/common-lisp/lem/frontends/sdl2/resources/fonts/NotoColorEmoji.ttf" 15) (make-string 1 :initial-element #\LOCK) 255 255 255 0)

debugger invoked on a SDL2-TTF::SDL-TTF-ERROR in thread #<THREAD "main thread" RUNNING {1001480003}>: SDL Error (#<SDL-SURFACE {#X00000000}>): Text has zero width

So the error message is: SDL Error (#<SDL-SURFACE {#X00000000}>): Text has zero width But, generally it works, as I can demonstrate with the sigma symbol:

* (make-string 1 :initial-element #\GREEK_CAPITAL_LETTER_SIGMA) "Σ"

* (SDL2-TTF:RENDER-UTF8-BLENDED (sdl2-ttf:open-font #P"/home/rpx/common-lisp/lem/frontends/sdl2/resources/fonts/NotoColorEmoji.ttf" 15) (make-string 1 :initial-element #\GREEK_CAPITAL_LETTER_SIGMA) 255 255 255 0) #<SDL2-FFI:SDL-SURFACE {#X929E5262360}>

Does anybody know why that is happening?

My setup:

tron$ uname -a OpenBSD tron.fritz.box 7.4 GENERIC.MP#1544 amd64

tron$ doas pkg_info sdl2-ttf Information for inst:sdl2-ttf-2.20.2p2

tron$ doas pkg_info sdl2 Information for inst:sdl2-2.28.5

tron$ sbcl This is SBCL 2.3.11.openbsd.sbcl-2.3.11, an implementation of ANSI Common Lisp.

Any suggestions / advice appreciated!

Many thanks, Robert

rpx99 avatar Dec 21 '23 09:12 rpx99

Can you recompile some stuff, emoji should work Freetype needs to be compiled with FT_CONFIG_OPTION_USE_PNG

( cmake -DFT_DISABLE_PNG=OFF ../SDL_ttf_git )

1bsyl avatar Dec 21 '23 11:12 1bsyl

Many thanks for your suggestion.

I think Freetype is part of OpenBSDs xenocara and also part of the base system. Hmm..

rpx99 avatar Dec 21 '23 12:12 rpx99

you're welcome!

maybe it's faster for you to check: you can try to compile, SDL_ttf/examples/testapp.c

  • modify the source to only use your NotoFont emoji font
  • only use the string named "emoji"
  • set rendering blended ( F1 for help, "m" to toggle the blend/shaded/text rendering)

it should display the emoji in color ! if not, then freetype hasn't been compiled with png support ..

1bsyl avatar Dec 21 '23 12:12 1bsyl

Thanks again and sorry, but I don't know how to do that.

I will ask on the mailinglist if this is in place.

rpx99 avatar Dec 21 '23 13:12 rpx99

Follow up to this: a couple things I found while researching the problem (using an Arch system that was exhibiting the same symptoms).

  • The issue is manifesting in SDL2, and there isn't a good quick way to build the example files. Additionally, at this point, SDL2_ttf is still using Autotools, so the CMake parameter provided doesn't actually fix the problem.
  • Apparently, SDL2's build of Freetype doesn't enable PNG support by default. I've found two ways to get around this issue.
    1. Configure with CFLAGS="-DFT_CONFIG_OPTION_USE_PNG" LDFLAGS="-lpng" ./configure <options>. As far as I can tell, this is a functional workaround, but I haven't tested extensively.
    2. Use the system's version of Freetype by using ./configure --disable-freetype-builtin <options>. For Arch, at least, Freetype is built with PNG support, so this fixes that issue. It is quite possible that OpenBSD builds Freetype with PNG support, but if not, you might have to compile & install both SDL2_ttf and Freetype manually.

@rpx99, if the second workaround is the solution, it is probably better to open up an issue with OpenBSD package maintainers, as the issue is in their wheelhouse at that point.

OrdoFlammae avatar Dec 29 '23 19:12 OrdoFlammae

@OrdoFlammae thanks a lot for commenting! Think OpenBSDs system freetype doesn't have the option enabled, but I'll check with maintainer / the mailing list.

rpx99 avatar Dec 29 '23 20:12 rpx99

Maybe we should look into adding PNG support for SDL_ttf 3.0?

slouken avatar Jan 15 '24 20:01 slouken

Fix for arch seems this: link

Maybe adding PNG is the general fix?

rpx99 avatar Jan 15 '24 21:01 rpx99

@OrdoFlammae Tried Option ii for OpenBSD.

Recompiled Xenocara with FT_CONFIG_OPTION_USE_PNG enabled and Recompiled sdl2-ttf port with --disable-freetype-builtin

Works, but unfortunately time consuming.

Adding this to the main build in OpenBSD is tricky because libpng is in ports and building base components can't depend on that, so libpng would need adding to xenocara in some way, which would be a lot of work to handle in ports, it would also make it more difficult to get libpng updated, and might not be accepted in the first place.

Source

rpx99 avatar Jun 11 '24 08:06 rpx99

FYI rebuilding with FT_DISABLE_PNG=off does somewhat work, we're getting color emoji support (see here), the problem is that said emoji can't be scaled (in NotoColorEmoji for example, we're stuck to size 109, see this for more info) and so users get strange font size mismatches (see here).

Tracking the size issue at #363, but I thought it would also be relevant to mention it here.

Cheaterman avatar Jun 20 '24 12:06 Cheaterman