Add pygame.font.set_kerning() function to enable users to disable kerning

[MyreMylar]

I've been hacking away again at trying to bring more feature parity between pygame.freetype.font and pygame.font.

I noticed that freetype.font lets you disable or enable kerning, and defaults it to off - meanwhile pygame.font has no kerning control and just defaults it to on. This PR adds a simple kerning control function to pygame.font.

NOTE: In the process of fiddling with this I noticed that the two will still likely never be fully aligned for kerning because there has been some kind of KERNING_MODE_SMART invented in the meantime in freetype - and which SDL_ttf uses. I can find no documentation on it, but it seems to improve the kerning of some rendered fonts in visual testing.

[MyreMylar]

Will try to find a test case for this either where there is a visual difference, or perhaps a size difference in the created surface for a glyph pair (e.g. 'V' & 'A').

Though it looks like 'smart kerning' is not disabled when kerning is disabled so maybe this won't even work very well.

[Gabryel-lima]

Estou tentando novamente trazer mais paridade de recursos entre pygame.freetype.font e pygame.font.

Percebi que freetype.font permite desativar ou ativar o kerning e desativá-lo por padrão - enquanto isso, pygame.font não tem controle de kerning e apenas o ativa por padrão. Este PR adiciona uma função simples de controle de kerning ao pygame.font.

NOTA: No processo de mexer nisso, notei que os dois provavelmente nunca estarão totalmente alinhados para o kerning porque houve algum tipo de KERNING_MODE_SMARTinvenção entretanto no freetype - e que SDL_ttf usa. Não consigo encontrar documentação sobre isso, mas parece melhorar o kerning de algumas fontes renderizadas em testes visuais.

I believe it's about, because I migrated from pygame to pygame-ce a short time ago, and I noticed this situation regarding access to the use of native os sources. I would even open another issue to see if people also came across this. And what's worse is that I understand very little lol. You did it?

[Gabryel-lima]

Estou tentando novamente trazer mais paridade de recursos entre pygame.freetype.font e pygame.font.

Percebi que freetype.font permite desativar ou ativar o kerning e desativá-lo por padrão - enquanto isso, pygame.font não tem controle de kerning e apenas o ativa por padrão. Este PR adiciona uma função simples de controle de kerning ao pygame.font.

NOTA: No processo de mexer nisso, notei que os dois provavelmente nunca estarão totalmente alinhados para o kerning porque houve algum tipo de KERNING_MODE_SMARTinvenção entretanto no freetype - e que SDL_ttf usa. Não consigo encontrar documentação sobre isso, mas parece melhorar o kerning de algumas fontes renderizadas em testes visuais.

I believe it's about, because I migrated from pygame to pygame-ce a short time ago, and I noticed this situation regarding access to the use of native os sources. I would even open another issue to see if people also came across this. And what's worse is that I understand very little lol. You did it?

I already discovered what I had done wrong. Hahaha

[Starbuck5]

I wrote up a test script and didn't see any kerning changes with arial or comicsans

import pygame

pygame.init()
win = pygame.Window()
screen = win.get_surface()

font = pygame.font.SysFont("Arial", 75)

text1 = font.render("Hello world VA Wa", True, "black")
font.set_kerning(False)
text2 = font.render("Hello world VA Wa", True, "black")

print(text1.get_width(), text2.get_width())

running = True

while running:
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            running = False

    screen.fill("lightgrey")

    screen.blit(text1, (30,30))
    screen.blit(text2, (30,130))

    win.flip()

pygame.quit()

[Starbuck5]

From an API design note, it seems like the fashion now in the font module is to move towards properties instead of getters/setters. As a nice bonus, a Font.kerning property would match the API in freetype.Font (not the default values, but the interface would be the same at least).

Any other opinions on setter vs property?

[MyreMylar]

Yeah I suspect this function may be broken in SDL_ttf, but I am not certain.

…

On Mon, 26 Feb 2024, 07:17 Charlie Hayden, ***@***.***> wrote: I wrote up a test script and didn't see any kerning changes with arial or comicsans import pygame pygame.init()win = pygame.Window()screen = win.get_surface() font = pygame.font.SysFont("Arial", 75) text1 = font.render("Hello world VA Wa", True, "black")font.set_kerning(False)text2 = font.render("Hello world VA Wa", True, "black") print(text1.get_width(), text2.get_width()) running = True while running: for event in pygame.event.get(): if event.type == pygame.QUIT: running = False screen.fill("lightgrey") screen.blit(text1, (30,30)) screen.blit(text2, (30,130)) win.flip() pygame.quit() — Reply to this email directly, view it on GitHub <#2718 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGDGGQ7MOQI4RUBHL5ULQLYVQZKBAVCNFSM6AAAAABDIEYJV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGQ2TSNZQGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Starbuck5]

Yeah I suspect this function may be broken in SDL_ttf, but I am not certain.

Looking into the source code, it seems like the kerning code is only active on the non-harfbuzz branch of compilation. That should probably be reported to SDL_ttf then.

In the meantime, I don't think we should expose an SDL_ttf feature we don't think works. Marking this as a draft.

[Starbuck5]

I've come up with a simple patch for SDL_ttf, I'll propose it to them in the next couple days.

In SDL_ttf, there's a call to hb_shape. Patched version:

hb_feature_t userfeatures[1];
userfeatures[0].tag = HB_TAG('k','e','r','n');
userfeatures[0].value = font->use_kerning;
userfeatures[0].start = HB_FEATURE_GLOBAL_START;
userfeatures[0].end = HB_FEATURE_GLOBAL_END;

hb_shape(font->hb_font, hb_buffer, userfeatures, 1);

[MyreMylar]

I'm going to close this for now to keep the PR list less messy, it is not some complicated bit of coding we can't forget and it's implementation relies on SDLFont releasing a new version, us incorporating that version and then even then it will probably need caveats about the function not actually working with older SDLs/SDLFont versions.

Basically, this is for re-opening/recreating in some happier, future time.