4. Tipografia — 2 famílias de sistema + 1 celebratória de fronteira estreita

Em uma frase: Montserrat para marca e interface (400/500/600/700), JetBrains Mono para dado e identificador, Caveat só em display celebratório de 1 a 3 palavras.

Vocabulário desta seção: subset

O que esta seção NÃO cobre: A Caveat NÃO entra nos tokens nem em corpo de texto, documento, material técnico, interface ou e-mail. — se é disto que você precisa, não preencha em silêncio: gere o pedido de cobertura (https://ds.seed.eng.br/pedidos/).

4.1 Montserrat — marca e interface#

Do display ao corpo. Pesos carregados pelo sistema: 400 (Regular), 500 (Medium), 600 (SemiBold), 700 (Bold) — são os quatro que o subset seed (gen-subset-fontes.py), os 17 moldes e o registry @seed/fontes servem (medido em 2026-09-15, FT-P2, MANIFESTO §225.3). O 300 (Light) existe como TTF em 03-assets/fontes/montserrat/ e é permitido em peça impressa, que embute a fonte que usa; em tela, corpo é Regular (400) — até esta versão o §4.1 mandava Light no corpo, a tela-documento obedecia e recebia 400 em silêncio, porque nenhum molde carregava o 300 (veredito dele, gate do Grupo 2, MANIFESTO §226.1: "V-FT2.4 light: b"). Itálico não é carregado: <em> rende como oblíquo sintético do navegador, e é o aceito ("V-FT2.3 itálico: b"; 76 elementos medidos, 0 B). 800 (ExtraBold) e 900 (Black) são display de marketing (§4.3) e não entram nos moldes — e por isso <strong>/<b> dentro de texto que já é 700 não engrossa (o bolder pede 900 e não há face): a ênfase ali é por cor (--seed-text-brand-strong, peso herdado), regra em seed-componentes.md §75.8 ("V-FT2.1 strong: b"). Versão variável: preferir onde o consumidor a suporta; os moldes servem estáticos.

4.2 JetBrains Mono — dados e técnica#

Pesos: 400, 500, 700. Papel exclusivo: dados de medição (kWh, kWp, demanda), identificadores (UC, ART, nº de proposta), código, timestamps, e acento técnico em labels micro (o caption pode ser mono — ver escala). Algarismos tabulares nativos: colunas de números alinham. Nunca em títulos ou parágrafos.

4.3 Camada expressiva e fonte celebratória (decisões de 2026-07-31)#

Camada expressiva da Montserrat — pesos 800/900 liberados para display de marketing. A família tem 9 pesos; o sistema usa 4 no dia a dia, e o marketing ganha ExtraBold (800) e Black (900) para títulos de impacto em social e campanhas. Repertório oficial de tratamento (usar antes de pensar em fonte nova): Black gigante com tracking apertado · grifo amarelo (accent-highlight) atrás da palavra-chave · contraste Light+Black na mesma frase · contorno/outline do Black · caixa alta empilhada · número gigante em JetBrains Mono como quebra técnica. Fundamento (pesquisa 2026): o erro mais comum é buscar fonte nova quando o sistema só precisa ser usado com mais criatividade.

Fonte celebratória: Caveat (Google Fonts, SIL OFL, pesos 400–700 variável, PT-BR completo). Escolhida pelo Rafael em comparativo real de 3 candidatas (vs. Shantell Sans e Kalam, mockup "Feliz 2026!" na linguagem v5.0). É a resposta oficial à necessidade que a Indie Flower atendia de forma errada — o registro manuscrito para momentos humanos, agora com fonte contemporânea e fronteiras duras:

• Onde: display de peças celebratórias e de emoção — datas comemorativas, celebrações, conquistas, campanhas humanas. 1 a 3 palavras por peça (ex.: "Feliz 2026!"), sempre em Bold (700) para presença.
• Nunca: corpo de texto, propostas, documentos, material técnico, licitação, UI/produtos, e-mail. Por decisão deliberada, a Caveat não entra nos tokens (seed-tokens.*) — mantê-la fora do sistema de produto é o que garante a fronteira.
• Sempre pareada com layout limpo: Montserrat no restante da peça, lei 70/20/10 valendo.
• Fundamento (pesquisa 2026): tipografia manuscrita é tendência central ("imperfect by design" — reação à perfeição gerada por IA), com a ressalva de mercado que adotamos como regra: funciona para o caloroso/humano, nunca para o corporativo/técnico.

4.4 Aposentadorias (supersede formal)#

• Indie Flower — aposentada (2026-07-30). A tagline manuscrita "Soluções Sustentáveis" sai de cena como elemento visual; o texto segue existindo como texto normal quando fizer sentido. Motivo: a fonte (marker fina, genérica, de 2010) envelhecia o visual — mas a categoria manuscrita provou-se válida e ganhou sucessora oficial com fronteiras: a Caveat (§4.3).
• Neo Tech — aposentada (2026-07-30). Não tinha papel definido, não está no Google Fonts, nenhuma peça recente a usava.

4.5 Pilhas de fallback (tokens) — e desde 2026-08-26 elas são PLANO B de verdade#

⚠⚠ A pilha não é mais o mecanismo de entrega da fonte — é reserva. Decisão dele em 2026-08-26 ("podemos deixar o plano B, mas temos que forçar sempre a fonte canônica"): peça impressa EMBUTE a família (contrato TP1, aborta se faltar) e bancada/tela referencia por URL relativa os TTF de 03-assets/fontes/. A pilha abaixo só trabalha em arquivo aberto fora do repositório ou mutilado. Instalação no sistema é opcional e documentada em 03-assets/fontes/LEIA-ME.md. ⭐ Antes disso, "fallback" era eufemismo: sem @font-face em lugar nenhum, a pilha era o mecanismo primário — e o mono rasterizava Consolas em tudo que estava vivo.

--seed-font-sans: 'Montserrat', -apple-system, 'Segoe UI', Roboto, Arial, sans-serif;
--seed-font-mono: 'JetBrains Mono', 'SF Mono', Consolas, 'Courier New', monospace;

⛔ O SUBSET seed NÃO COBRE TUDO — e o buraco só aparece na peça pronta (novo na v5.42). Medido em 2026-09-08 ao refazer dois documentos com o DS: o montserrat-seed-400.woff2 não tem a seta → (U+2192), e o navegador trocou os três caracteres pelo Segoe UI do sistema, sem erro, sem aviso e sem que ninguém percebesse — foi o conferir-peca.py (CP-2) que achou, medindo o PDF entregue. Os TTF completos de 03-assets/fontes/ têm o glifo.

Regra que fica: peça de TELA usa o subset (é o que ele existe para fazer — peso de página); peça IMPRESSA e documento que vira PDF usam a fonte completa, embutida em woff2, pelo mesmo motivo — a cobertura — pelo qual o PPTX e o DOCX usam o TTF completo (03-assets/fontes/ttf-por-url.md). O woff2 completo tem os MESMOS glifos e o mesmo cmap do TTF (1.312 pontos de código, 2.747 glifos por peso); só a compressão muda. Ele é gerado pelo gen-subset-fontes.py em 03-assets/fontes/montserrat/woff2-completa/ (300 a 700), com --checar. ✅ REV-P6, 2026-09-26 — a letra desta regra dizia "TTF completo". Veredito dele na folha da REV-P1, v2 (MANIFESTO §249.2 e §250), verbatim: "3 fonte das peças: woff2". Medido na aplicação: as 67 peças que embutiam o TTF passaram a 39,4 MB (eram 135,6 MB; −96,2 MB), com o PNG de MD5 igual em 67 de 67 e o PDF com as mesmas páginas, as mesmas fontes e 0 px de diferença a 150 dpi em 67 de 67. E, em qualquer caso, a conferência é do arquivo pronto: o CP-2 reprova fonte de fora do DS, e é assim que um fallback silencioso vira defeito visível. ✅ MR-P17 FECHADA em 2026-09-13 — ele decidiu AMPLIAR (folha "Fila do DS — decisões rápidas", D-2 = A, verbatim "ampliar o subset (com o gerador e o re-render)", MANIFESTO §208 e §210). Desde a v5.46 o subset seed cobre a faixa de setas e sinais: os 25 pontos de código de U+2190–U+22FF que a Montserrat possui (as 8 setas ← ↑ → ↓ ↔ ↕ ↖ ↗ ↘ ↙, ∂ ∅ ∆ ∏ ∑ − ∕ ∙ √ ∞ ∫ ≈ ≠ ≤ ≥), nas duas famílias — 230 pontos de código na Montserrat e 234 na JetBrains Mono. E o subset passou a ter GERADOR: 06-validacao/geradores/gen-subset-fontes.py declara o repertório faixa a faixa, gera os sete woff2 de forma determinística (duas gerações, mesmo MD5; --checar prova o disco contra o regenerado) e confere o nome interno de cada arquivo. Custo medido na geração: Montserrat 400 25.928 → 26.728 B (+800), 500 +760, 600 +852, 700 +820; JetBrains Mono +892 a +964 B por peso. As 12 famílias de peça que embutem o subset em base64 foram regeradas pelos próprios geradores e a evidência PNG re-renderizada. A regra "peça de tela usa o subset; impresso e PDF usam a fonte completa" continua — a ampliação fecha o buraco da seta em tela, não substitui a fonte inteira no papel (desde a REV-P6, a fonte inteira vai em woff2, acima).

4.6 Regras absolutas (herdadas de 2018, auditadas e mantidas)#

Sem sombras em texto · sem layouts diagonais · sem texto em curva · line-height títulos 1.1–1.2, corpo 1.5–1.7.

4.7 Escala tipográfica#

Nota da v5.0: o CAPTION em mono é o acento de "precisão de engenharia" da linguagem editorial (§10). A escala vale para peças, sites e documentos; a nota da v4.1 sobre escala própria do ERP morre junto com o erp-seed-design.md — produtos usam esta escala (densidades específicas serão tokens de componente na Fase 3).

4.8 Piso tipográfico por classe de peça (novo na v5.40)#

Por que esta subseção existe. A escala da §4.7 é de tela, em px, e por isso o canon nunca teve resposta para uma pergunta simples: qual é o menor tamanho de texto aceitável num documento impresso? A lacuna apareceu quando o conferidor de peça (conferir-peca.py, contrato CP, F9.10) mediu dois PDF da casa e encontrou 76 e 148 trechos abaixo do menor degrau da escala de tela — sem ter régua para dizer se aquilo estava certo ou errado. Régua que não existe não reprova ninguém, então o item avisava em vez de reprovar. Fechada pelo veredito dele em 2026-09-08, verbatim: "pode adotar a tabela acima".

Três regras que vêm de carona da NBR 9050 e valem para toda peça de campo: fonte sem serifa; texto em caixa alta e baixa, evitando texto na vertical; e caixa alta apenas em mensagem de advertência. Elas já estavam no seed-praticas.md §23 como convenção nossa — agora têm norma.

⚠ O que é lei e o que é convenção, dito na cara: o 12 pt e a relação 1/200 são norma; o 10 pt e o 8 pt são decisão da casa, tomadas com o custo medido (adotar o piso de 8 pt custou mexer em 10 % e 15 % dos trechos dos dois documentos auditados; um piso único de 10 ou 12 pt seria redesenho, 74 % a 97 %). Quem precisar contestar o 10 e o 8 contesta uma convenção, não uma norma.

Como isto é medido: o CP-3 do conferir-peca.py reprova qualquer texto abaixo de 8 pt em peça de página impressa e informa quantos ficam abaixo de 10 pt; em peça de tela, o piso continua sendo o menor degrau da §4.7 (11 px).

---