ttf does not provide TTF_GlyphIsProvided

[boredcoder411]

same as title, no TTF_GlyphIsProvided in the sdl2-ttf package

[shellohunter]

ttf_measure APIs missing too, such as: https://wiki.libsdl.org/SDL2_ttf/TTF_MeasureUTF8
those api are quite helpful when dealing with line wrapping.

is there any reason for dropping those APIs, or just because of short of hands?

[veeableful]

Hi, sorry about the missing APIs 💦 I will add them once I'm available to do so.

[veeableful]

Hi @boredcoder411 and @shellohunter, I have added the bindings to the master branch. Would you like to try it out?

[shellohunter]

measure APIs works as expected. thanks! will them be in next tag?

btw, I noticed that v0.5 is in beta, it would be nice if sdl2 enums have enum-like typedefs in golang, something like this:

type MouseButton uint8
const(
     MouseButtonLeft MouseButton = 0
     MouseButtonRight MouseButton = 1
)

language servers can make use of it, providing better auto-completion.

[veeableful]

@shellohunter Yes! They will be in the next tag.

We have constants ButtonLeft and ButtonRight. Is that what is being referred to?

[shellohunter]

constants are just integers, what I mean is to add specific types to group constants like this: https://gobyexample.com/enums , then go can make basic type checking to prevent misuse, and it will be more comprehensive to LSP.

[veeableful]

@shellohunter we do have the Button type. Is there something that you find missing?

If there is, please create another issue!

[shellohunter]

@veeableful just noticed they are already available in master branch. no issues anymore.

[lmorg]

Just wanted to share that I'm very grateful for v0.5.0 and the GlyphsIsProvided API specifically too.

Thank you for all your dedication to this project

[lmorg]

It looks like GlyphsIsProvided is already "deprecated" (in the sense that it's not recommended) in SDL because it's only a uint16. Instead they recommend GlyphsIsProvided32.

• https://wiki.libsdl.org/SDL2_ttf/TTF_GlyphIsProvided -- added SDL_ttf 2.0.12.
• https://wiki.libsdl.org/SDL2_ttf/TTF_GlyphIsProvided32 -- added SDL_ttf 2.0.18.

As per the documentation, the 16-bit version of that API doesn't account for a wide range of code points, including emoji (that latter being how I stumbled upon this problem).

Given Go runes are 32-bit, I wonder if it is worth switching the Go lang mapping for GlyphIsProvided to the C TTF_GlyphIsProvided32 so that Go defaults to the most up-to-date version of that API. And have the Go method accept a rune instead of uint32. This would mean we'd need to cast the rune (int32) to a uint32 but, unless I'm overlooking something obvious, that shouldn't be a problem. And it's likely an operation that the API consumer would want and do themselves anyway.

I appreciate this would be a breaking change but v0.5.0 is still in alpha so it's arguably a safe point to do so.

Are you happy for me to raise a PR to make this change, is this something you'd rather pick up, or do you disagree with this approach entirely?

[veeableful]

Hi @lmorg, thank you bringing that up. I think keeping the function names predictable would be desirable so GlyphIsProvided would use TTF_GlyphIsProvided and GlyphIsProvided32 would use TTF_GlyphIsProvided32. I would certainly be happy to accept the PR!

[lmorg]

PR: #621