Open rpx99 opened 11 months ago
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 )
Many thanks for your suggestion.
I think Freetype is part of OpenBSDs xenocara and also part of the base system. Hmm..
you're welcome!
maybe it's faster for you to check: you can try to compile, SDL_ttf/examples/testapp.c
it should display the emoji in color ! if not, then freetype hasn't been compiled with png support ..
Thanks again and sorry, but I don't know how to do that.
I will ask on the mailinglist if this is in place.
Follow up to this: a couple things I found while researching the problem (using an Arch system that was exhibiting the same symptoms).
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../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 thanks a lot for commenting! Think OpenBSDs system freetype doesn't have the option enabled, but I'll check with maintainer / the mailing list.
Maybe we should look into adding PNG support for SDL_ttf 3.0?
@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.
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.
@madebr, can/should we enable FT_CONFIG_OPTION_USE_PNG in the vendored FreeType we use?
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