Skip to content

Reduce the number of Font classes (3117) #1577

Open
@GalacticEmperor1

Description

@GalacticEmperor1

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:

  1. 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.
  2. 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.
  3. Then deprecate pygame.freetype.Font. I think this one does get used (I know I am personally using it in pygame_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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions