Description
Issue №3117 opened by MyreMylar at 2022-04-05 15:33:47
Right now pygame has four classes that do the job of loading a font - pygame.Font
, pygame.SysFont
, pygame.ftfont.Font
and pygame.freetype.Font
. Deep underneath all four use the freetype library.
Supporting all four classes is sometimes a frustrating maintenance burden - I've recently seen a couple of PR's caught out by the existence of ftfont, and I'm not sure there is any good justification for us continuing to have four other than - they already exist. With SDL_ttf getting new updates recently, and the much greater ease of pushing PRs to modern SDL I think it no longer makes obvious sense to wrap freetype ourselves.
My high-level three step proposal is to:
- First try and gradually winnow the four Fonts backend down to one set of underlying C code that wraps
SDL_ttf
while maintaining the existing four Font classes facing the users. Ideally we could do this with python wrappers around a more fully featured Font class if performance is acceptable. This is a good primary step that will make adding new features a lot easier if we just have to change some wrapper code when adding a new font feature. - Once step 1 is complete deprecate
pygame.ftfont.Font
. This class' purpose would evaporate if we have only one backend, and I don't think it really gets used in much actual user code. - Then deprecate
pygame.freetype.Font
. I think this one does get used (I know I am personally using it inpygame_gui
) by users, but I suspect a lot fewer than use Font and SysFont.
Related current issues/PRs:
3023
2991
I expect this to be a pain in the butt to actually make work.
Comments
# # ankith26 commented at 2022-04-05 15:53:36
+1 for the general idea.
I think the first step we can do is deprecate ftfont
, it's something we could have done a while back. ftfont
was mainly intended when pygame.font
could not render UCS4 unicode, but it can now if SDL_ttf version is new enough.
# # Starbuck5 commented at 2022-04-06 19:19:19
This is very long term. Until recently, pygame.freetype was a super set of SDL_ttf. Now it’s more of a mixed bag.
I appreciate freetype for lots of features— off the top of my head:
- rendering a font at many sizes (SDL_ttf 2.0.18 supports this)
- rendering text at an angle
- rendering to an existing Surface
For now I’d support deprecating ftfont. We could put in some deprecation warnings.
One thing to be aware of is that (iirc) deprecation warnings only appear by default on python 3.8 and above. So we’ve been putting in several deprecation warnings, maybe we shouldn’t act on them until after we’ve dropped 3.6 and 3.7 support for a while.
# # MyreMylar commented at 2022-04-06 19:59:43
Yeah, there is some good stuff in freetype that we'd want to keep somehow.
Another thing I remembered is that right now android pygame (and perhaps web pygame?) doesn't support pygame.freetype.