O problema que ninguém explica direito sobre ligaduras neutras
Eu passei as últimas semanas tentando colocar o OpenType certo num site de um cliente que queria manter a consistência tipográfica entre serifadas e sans-serif, e o arquivo-fonte dele tinha 47 variantes de peso diferente. A coisa mais difícil não era encontrar o arquivo, era entender por que algumas combinações de letra simplesmente ignoravam a ligadura quando você ativava CSS font-feature-settings. O problema principal é que a maioria dos guias que você encontra na internet começa dizendo que é só adicionar uma propriedade CSS e pronto. Na prática, não funciona assim. Vou explicar primeiro como eu cheguei a resolver isso no final, porque a definição padrão do que é uma ligadura neutra em OpenType geralmente confunde quem tá começando. Ligadura neutra é basicamente um glifo alternativo que o motor da fonte oferece quando detecta certas sequências de caracteres, mas ela não muda o código Unicode do texto. Isso significa que quando você vê "ff" renderizado como um único glifo, o still está como dois caracteres U+0066 U+0066 no source. A fonte decide sozinha se desenha aquilo juntinho ou separado, dependendo do recurso ativa. Esse detalhe é importante porque muitos desenvolvedores acham que precisam de um plugin JavaScript pra tratar isso, e precisam não precisam. O serviço é nativo do navegador.
onde encontrar liga neutra no dia a dia
Se você tá procurando onde encontrar liga neutra, a resposta curta é: depende do que você quer fazer. Vou listar os cenários mais comuns que eu vejo surgindo nos fóruns técnicos e nos emails de clientes. O primeiro cenário é o típico desenvolvimento web. Você quer ativar ligaduras tradicionais em headings com fontes como Lora, Merriweather ou Source Serif Pro. Aí você vai pro Google Fonts ou diretamente pro repositório da fonte, baixa o arquivo WOFF2 e coloca a regra CSS font-feature-settings: "liga" 1; ou a versão moderna font-variant-ligatures: common-ligatures;. Funciona bem na maioria dos casos, mas tem uma pegadinha: fontes otimizadas pra tela às vezes vêm sem o recurso "liga" habilitado por padrão no bundle. Já aconteceu comigo com a fonte Inter, que é extremamente popular e vem com ligaduras técnicas desativadas no peso regular. Você precisa verificar o mapeamento GLYPH no arquivo da fonte antes de assumir que o recurso existe.
O segundo cenário é diseño gráfico e tipografia para impressão. Aqui você lida com InDesign, Illustrator ou Affinity. Nessas ferramentas, você vai em Editar > Preferências > Tipografia e marca a opção "Ligaduras padrão". Mas o mais importante é que a configuração pode ser sobrescrita pelo documento. Eu tive um caso recente em que um arquivo INDD herdava configurações de um template antigo que vinha com ligaduras explicitamente desligadas. O texto parecia normal na pré-visualização porque o motor de rasterização do InDesign ignora ligaduras em algumas configurações de visualização. Eu levei duas horas pra perceber que o problema era a camada de display, não a fonte. A solução foi forçar a visualização em modo "Avançado" e depois reinserir o texto com o estilo aplicado do zero. O terceiro cenário, e aqui é onde a maioria das pessoas erra, é pesquisa acadêmica e documentação técnica. Se você tá produzindo um artigo com muitas abreviações, siglas ou termos compostos em latim, as ligaduras podem criar ambiguidade visual. Por exemplo, a sequência "fi" em "filosofia" vira um glifo único, mas em "físico" o "fi" aparece em posição differente e alguns motores de fonte tratam isso como cenário de contexto diferente. A maneira correta de lidar com isso é usar a propriedade font-feature-settings: "dlig" 0, "liga" 1; pra desligar ligaduras disionárias e manter só as comuns. Isso resolve 90% dos casos Problemáticos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Se você precisar baixar arquivos de fontes que já vêm com ligaduras neutras habilitadas e testadas, os repositórios mais confiáveis são o Google Fonts (graças à licença Apache), o Font Awesome Pro (pra ícones, não pra texto corrido), e o Adobe Fonts, que permite incorporar diretamente via CDN com o snippet javascript deles. O Adobe Fonts é especialmente útil porque ele injeta as regras OpenType automaticamente no host, então você não precisa configurar nada no CSS. O único problema é que ele requer JavaScript pra funcionar, o que quebra em crawlers e em contextsos SSR. Outro ponto que quase ninguém mencina: ligaduras neutras não funcionam em monospace fonts. Eu aprendi isso na marra quando um cliente pediu pra eu aplicar ligaduras num bloco de código com Fira Code. O Fira Code usa ligaduras de forma diferente — ele mapeia sequências completas como "===" e "!==>" pra glifos únicos, mas isso é controlado por uma feature chamada "calt" (contextual alternates), não por "liga". Se você tentar ativar apenas "liga" no Fira Code, nada acontece. A configuração correta é font-variant-ligatures: contextual-ligatures;. Já perdi tempo debugando isso em três projetos seguidos antes de entender a diferença entre os dois recursos.
Para quem tá usando Linux e precisa instalar fontes localmente, o comando básico é copiar o arquivo TTF ou OTF pra ~/.fonts/ ou ~/.local/share/fonts/, executar fc-cache -fv e verificar com fc-list | grep nome-da-fonte. O processo é simples, mas o problema real é que muitas distribuições Linux vêm com um subsetor de fontes padrão que não inclui ligaduras completas. A fonte Liberation Serif, por exemplo, que é o substituto open source da Times New Roman nas distros baseadas em Debian, tem ligaduras básicas mas não as alternativas contextuais avançadas. Se você precisa de recursos tipográficos completos no Linux, provavelmente vai precisar baixar a fonte separadamente e instalar manualmente.
Por que o recurso falha em alguns navegadores
Existe uma limitação prática que todo mundo enfrenta e poucos conseguem explicar. Navegadores mais antigos, especialmente Internet Explorer e versões anteriores ao Safari 10, não suportam font-variant-ligatures. O fallback é usar font-feature-settings, mas mesmo assim o suporte é inconsistente. Eu já vi relatórios em que um cliente estava usando Safari 9 num iPad antigo e as ligaduras simplesmente não apareciam, enquanto no Chrome desktop funcionavam perfeitamente. A solução nesses casos é fazer feature detection com JavaScript usando CSS.supports() e aplicar uma classe conditiona, mas isso adiciona complexidade desnecessária pro projeto. O cenário mais frustrante que eu já enfrentei envolveu um cliente do setor jurídico que precisava que todos os documentos PDF gerados automaticamente mantivessem as ligaduras corretas. O problema é que a maioria das bibliotecas de geração de PDF no back-end, como Puppeteer ou wkhtmltopdf, renderizam o texto com subconjunto de glifos baseado no que aparece no DOM. Se a fonte não for embedada corretamente no PDF, as ligaduras são substituídas por glifos padrão separados. Eu resolvi esse problemaEmbedendo a fonte diretamente no PDF usando a opção pdf.fontBase64 do Puppeteer, mas isso aumentou o tamanho médio do arquivo de 200KB para 1,4MB por documento. Dependendo do volume de geração, esse pode ser um fator decisivo pra você buscar uma alternativa, como usar apenas ligaduras que são nativas do padrão PDF 1.4, que incluem "fi", "fl", "ffi" e "ff" como glifos padrão em muitas fontes embedded.
Se você está num cenário onde as ligaduras neutras simplesmente não são viáveis — seja por restrição de compatibilidade, performance ou especificação do projeto — a alternativa mais honesta é não usá-las. Muitas fontes modernas vêm com ligaduras visuais suficientes sem precisar de configuração extra. Helvetica Neue, por exemplo, tem um comportamento de kerning tão apertado que as ligaduras explícitas são quase imperceptíveis na maioria dos tamanhos de corpo. O esforço pra configurar o recurso muitas vezes não gera benefício perceptível pro usuário final. O que eu recomendo na prática é começar testando a fonte que você pretende usar direto no site codepen.io ou num arquivo HTML simples com as propriedades font-feature-settings aplicadas. Cole o snippet, alterne entre ligaduras ativadas e desativadas, e verifique se a mudança é perceptível no tamanho de corpo que você vai usar no projeto. Se não houver diferença visível, não gaste tempo configurando o recurso. Se houver diferença mas não nos navegadores-alvo do projeto, documente essa limitação early no briefing com o cliente e proponha uma alternativa de design que não dependa do recurso.
