FNT: fontes bitmap de 1 bit

O Total Annihilation vem com uma coleção de arquivos .fnt para tudo, das mensagens de rádio na tela (comix.fnt) às telas de briefing das unidades (armbrief.fnt). São fontes bitmap minúsculas, de largura variável, com 1 bit por pixel, indexadas por código de caractere de 8 bits: no fundo, uma folha de sprites com uma tabela de consulta.

fonts/comix.fnt renderizada como folha de sprites de 16 colunas pelo kbot fnt sheet

kbot fnt render comix.fnt --text "kbot" --fg "#ffff00" --bg "#000000"

kbot fnt info     fonts/comix.fnt                    # one-line summary
kbot fnt describe fonts/comix.fnt --list             # full metadata + glyph list
kbot fnt sheet    fonts/comix.fnt -o sheet.png       # all glyphs as a grid
kbot fnt render   fonts/comix.fnt --text "Commander" --fg "#ffff00" --bg transparent -o caption.png
kbot fnt dump     fonts/comix.fnt -t ./glyphs        # one PNG per character

import "github.com/coreprime/kbot/formats/fnt"

f, _ := os.Open("fonts/comix.fnt")
defer f.Close()
font, _ := fnt.LoadFromReader(f)
fmt.Println(font.Height, "px,", font.GlyphCount(), "glyphs")
if g := font.Glyphs['A']; g != nil {
    fmt.Println("A is", g.Width, "px wide")
}

Estrutura no disco#

┌─ 4-byte header ──────────┐
│ uint8   Height           │   byte 0: shared by every glyph; the line height
│ uint8   (ignored)        │   byte 1: not part of the height
│ int8    Baseline         │   byte 2: rows the glyphs extend above the pen
│ uint8   FirstChar        │   byte 3: code of the first offset-table entry
├─ (256 − FirstChar) × u16 ┤   file offsets; 0 = glyph not defined
├─ Glyph data ─────────────┤   for each defined glyph:
│   uint8  Width           │   pixel width (1..255), also the pen advance
│   ⌈Width × Height/8⌉     │   1bpp pixels, MSB-first bit stream
└──────────────────────────┘

Todas as fontes da versão comercial têm FirstChar = 0, então o cabeçalho + a tabela de offsets ocupam 4 + 256 × 2 = 516 bytes, e os dados dos glifos começam logo depois.

Ferramentas mais antigas liam os bytes 2–3 como uma única palavra opaca de "flags"; na verdade são dois campos separados.

Como ler um glifo#

Os dados do glifo são um fluxo de bits contínuo, MSB primeiro, empacotado da esquerda para a direita e depois de cima para baixo, ou seja, varredura por linhas. O número de bits é Width × Height e o número de bytes guardados é ⌈(Width × Height) / 8⌉.

def read_glyph(file, offset, height):
    file.seek(offset)
    width = file.read(1)[0]
    if width == 0 or width > 128:
        return None
    n_bits  = width * height
    n_bytes = (n_bits + 7) // 8
    bits    = file.read(n_bytes)
    pixels  = []
    for i in range(n_bits):
        bit = (bits[i // 8] >> (7 - (i % 8))) & 1
        pixels.append(bool(bit))
    return Glyph(width, height, pixels)

Não há dados de kerning nem largura de avanço separada de Width. O jogo compõe o texto assim, e o kbot fnt render, a ferramenta MCP fnt_render e a pré-visualização de texto do explorador de recursos fazem o mesmo:

• cada byte do texto escolhe o glifo com aquele código (converta antes o texto UTF-8 para a página de código do jogo; o padrão de kbot fnt render --codepage é Windows-1252);
• um glifo avança a caneta exatamente pela sua largura, sem espaço extra;
• um caractere sem glifo não desenha nada e avança 0;
• o desenho para no primeiro NUL ou quebra de linha.

Uma fonte de 13 linhas com um A de 10 pixels e sem glifo de espaço desenha, portanto, "A A" com 20 pixels de largura.

Exemplo comentado: comix.fnt#

$ kbot fnt describe fonts/comix.fnt
Height:        14 px
Baseline:      1 (glyph rows start this many rows above the pen)
First char:    0x00
Glyphs:        94 / 256 defined
Glyph width:   min=3 max=13 mean=5.9
Ranges:        0x20-0x7D

Como ler isso: é uma fonte de 14 pixels de altura que cobre o ASCII imprimível (do espaço até }). As larguras vão de 3 (i, l) a 13 (M, W). As 162 posições não definidas são, na maioria, caracteres de controle não imprimíveis; o resto são extras do Latin-1 que o jogo não exibe.

A tabela de offsets dos dez primeiros caracteres de comix.fnt:

char  offset    width  bytes  meaning
0x20  0x021C    4      7     space
0x21  0x0223    3      5     '!'
0x22  0x0228    5      9     '"'
0x23  0x0231    6     11     '#'
0x24  0x023C    5      9     '$'
...

O mesmo conteúdo sai com kbot fnt describe --list.

Dicas de renderização#

O kbot fnt render aceita:

Um caractere que não existe na fonte não desenha nada e não ocupa espaço, como no jogo.

Armadilhas#

• A ordem dos bits é MSB primeiro dentro de cada byte. LSB primeiro é a convenção mais comum nas fontes bitmap modernas; não presuma.
• O fluxo de bits é contínuo entre as linhas: não há preenchimento até o limite de um byte no fim de cada linha de varredura.
• Os bytes 2 e 3 são a linha de base e o código do primeiro caractere, e não uma palavra de flags. Um código de primeiro caractere diferente de zero encurta a tabela de offsets.
• Os caracteres são bytes, não pontos de código Unicode. € é o byte 0x80 em Windows-1252; tomar um ponto de código módulo 256 escolhe o glifo errado.
• Não há metadados sobre quais caracteres são suportados. É preciso percorrer a tabela de offsets para descobrir o conjunto de glifos.

Tamanhos típicos#

Veja também#

• PAL: as fontes não trazem paleta; o renderizador precisa que você escolha uma cor de primeiro plano e de fundo ou aplique a paleta do TA manualmente.
• Glossário: 1bpp, fluxo de bits MSB primeiro.