Justif - Justificação Knuth-Plass e microtipografia para a web

• Justif é uma demo web que compara diretamente a renderização padrão do navegador com justificação de texto em nível editorial
• É possível configurar separação silábica, protrusão de caracteres, expansão de largura, ajuste de espaçamento entre letras e alinhamento do espaçamento da última linha
• Também dá para ajustar a largura mínima da última linha e o alcance da pontuação pendente, além de comparar com o resultado de text-wrap: pretty
• É possível testar textos literários e técnicos em inglês, além de textos RTL em hebraico e árabe e japonês, com fontes serif, sans e monospace
• Mede lado a lado, em comparação com a renderização do navegador, número de linhas, quebras com hífen, linhas com overflow, últimas linhas curtas e variação de espaços e rivers

---

Justificação e configurações detalhadas

• O Justif foi criado para testar justificação Knuth-Plass e vários recursos de microtipografia na web
  • separação silábica
  • protrusão de caracteres
  • expansão de largura
  • ajuste de espaçamento entre letras
  • alinhamento do espaçamento da última linha
• A pontuação pendente só pode ser usada com a protrusão de caracteres ativada, e pode ser aplicada ao fim da linha, ao início da primeira linha ou ao texto inteiro
• A largura mínima da última linha pode ser ajustada para 0.33, e a largura do bloco de texto para 13em

Comparação e medição de textos e fontes

• É possível escolher textos para comparação entre Alice in Wonderland, Frog Prince, Frankenstein, Ulysses, posts técnicos, RFC 2324 e amostras tipográficas
• Também há textos RTL em hebraico e árabe, além de textos em japonês
• As fontes compatíveis incluem Junicode, EB Garamond, Alegreya, IM Fell English, Vollkorn, Amstelvar, Latin Modern, Georgia, Roboto Flex, Courier Prime, IBM Plex Mono e fontes do sistema
• Ao clicar ou pressionar longamente o resultado, a renderização padrão do navegador aparece para comparação com a renderização do Justif
• As ferramentas de comparação oferecem suporte a text-wrap: pretty, desfoque, régua de margens e exibição de espaçamento irregular
• As métricas incluem número de linhas, quebras com hífen, linhas com overflow, últimas linhas curtas, rivers, espaço médio, desvio médio em relação ao espaço natural, desvio padrão e o maior espaço

[GN⁺]

Comentários no Lobste.rs

• Este projeto foi feito com vibe coding usando Fable https://news.ycombinator.com/item?id=48946738#49002419

  • Questiono se essa tag é realmente necessária, já que o tema do texto não é vibe coding
    Não tenho interesse em ler relatos de uso de LLM e gostaria de filtrá-los, mas na prática parece que a tag é aplicada, independentemente do conteúdo, sempre que há apenas a suspeita de uso de um assistente de programação
    Neste caso o uso é claro, mas já vi posts de projetos receberem a tag só porque aceitam contribuições de pessoas que usam assistentes de programação
  • Admito sem rodeios que usei uma LLM ao criar este projeto
    Mas o termo vibe coding e a tag usada aqui já perderam utilidade; precisamos de uma expressão mais precisa e produtiva para distinguir textos sobre uso de LLM de resultados em cujo processo de criação uma LLM foi usada incidentalmente
  • Lagosta 1: “Eles desenvolveram um remédio que cura câncer!”
    Lagosta 2: “Pois é… mas usaram AlphaFold, CRISPR e… rufem os tambores… Fable”
    Lagosta 1: “Meu Deus, inaceitável! Vamos jogar tudo fora pelo bem da humanidade e passar 40 anos desenhando proteínas no quadro-negro com lápis de cor!”

• O resultado é muito bonito e vai além até do TeX sem o pacote microtype
  Esses recursos de composição tipográfica deveriam ser tratados diretamente pelo navegador
  Alguns navegadores implementaram text-wrap: pretty, mas parece haver uma limitação a poucas linhas

  • O Safari atual tem uma implementação decente de pretty, mas há um bug quando usado junto com justify
    https://matklad.github.io/2026/02/14/justifying-text-wrap-pretty.html
  • Pela especificação de text-wrap: pretty, trata-se de uma dica pura, sem comportamento definido
    Ela só diz que o agente de usuário deve priorizar uma composição melhor em vez de velocidade e considerar várias linhas ao decidir quebras de linha; fora isso, é igual a auto
    Pode evitar uma última linha curta demais, espaços que parecem rios entre as linhas, hífens consecutivos etc., mas a forma exata de melhoria varia entre navegadores
    Pelo que lembro, isso entrou na especificação para evitar restrições excessivas quando vários navegadores disseram que implementariam de formas diferentes
    É uma situação parecida com a descontinuação do Web SQL, quando ficou exposto que as implementações acabariam usando SQLite
    Espero que um dia esses recursos sejam aplicados por padrão em text-wrap: auto, fazendo com que text-wrap: pretty não tenha efeito algum, e também espero que https://bugzilla.mozilla.org/show_bug.cgi?id=630181 seja implementado
    Dicas assim não são novidade; will-change também era uma dica de otimização para navegadores da geração anterior
    Na época em que foi especificado, o Firefox quase não precisava dela, e para alguns motores de nova geração ela nem ajudava, mas ainda assim foi muito abusada; talvez tivesse sido melhor manter o transformZ(0), que era um hack explícito
  • Em um mundo ideal, esta biblioteca não precisaria existir
    Na demonstração é possível alternar text-wrap: pretty e testar o comportamento por navegador; a forma como Blink, WebKit e Gecko lidam com isso é surpreendentemente diferente, então recomendo conferir em vários navegadores

• Há muito tempo acho que pontuação pendurada costuma ser aplicada em excesso
  Se ela chama atenção, já passou do ponto; em especial, “ quase sempre se destaca, então deveria avançar para fora menos da metade do que avança hoje
  Por outro lado, gosto de como o “ no início de um parágrafo funciona quase como uma pequena indentação
  O resultado com a indentação pendurada desligada e apenas uma protrusão mais sutil ligada é tolerável, mas na maioria dos casos prefiro desligar ambas
  Esse tratamento depende muito da fonte
  Na fonte serifada que uso, Equity, aplicar isso a “f,” no fim da linha fica estranho, porque o kerning já coloca a vírgula sob o f, então até a parte superior do f acaba projetada para fora da linha
  Se uma fonte serifada coloca caudas ou saliências das letras fora da largura do glifo para que elas se projetem naturalmente, isso me parece um alvo mais apropriado do que a maioria dos sinais de pontuação
  Em ajuste de espaçamento entre letras, letter-spacing é perigoso porque não combina bem com ligaduras
  Se as ligaduras forem aplicadas primeiro, fica algo como “T h i s i s fi n e!”; se um letter-spacing diferente de zero desativa as ligaduras, o f colide com o ponto do i
  Geralmente acontece o segundo caso, mas isso varia conforme o sistema de escrita, a fonte e recursos OpenType ativados explicitamente, e também é fácil ocorrer sem intenção

  • Pessoalmente, gosto da aparência da pontuação pendurada, mas é claro que isso pode ser alterado nas configurações
    Concordo que o espaçamento entre letras é complicado por causa das ligaduras, mas acho que fica aceitável com o limite padrão de ±3%
    No fim do primeiro parágrafo do exemplo “Type Specimen”, dá para ver uma sequência de ligaduras fl, fi e ffi, e o limite de 3% também é configurável
  • Acho que a pontuação pendurada pode explicar algo que me irritou em alguns sites suecos, quando uma aspa dupla direita de abertura ficava sozinha no fim da linha anterior
    Em sueco, usa-se apenas a aspa dupla direita tanto no início quanto no fim de citações
    Há muito tempo me pergunto se existe uma forma de informar ao navegador o idioma ou locale de um texto específico para que ele trate automaticamente aspas, separadores decimais etc.

• Quero apontar que os exemplos usam uma largura de linha artificialmente estreita para destacar a melhoria
  Em geral se recomenda que uma linha tenha cerca de duas vezes o alfabeto minúsculo, ou seja, aproximadamente 60 caracteres de largura

  • Imagino que a largura das colunas dos jornais antigos fosse parecida com a dos exemplos, mas isso não significa que deva ser o padrão a seguir hoje
  • É possível aumentar a largura da coluna para comparar em uma largura de corpo de texto mais realista
    A diferença é bem menos dramática, mas ainda clara, e mesmo com largura de linha de 36em as estatísticas ficam muito melhores do que o padrão

• Fico me perguntando se a tag vibe coding foi aplicada só porque o autor disse em outro site que usou uma LLM
  O conteúdo do link não tem relação com LLM nem com vibe coding, então agora essa tag parece uma caça às bruxas

  • Vendo com mais boa vontade, é porque essa tag cumpre dois papéis: além de indicar que o texto trata de vibe coding, ela também é frequentemente usada como aviso de conteúdo sensível
    Isso entra em conflito com o uso mais óbvio, causa confusão e pode parecer agressivo demais
    Não é ideal uma única tag ter dois propósitos, mas em geral sou a favor de avisos de conteúdo sensível e da possibilidade de filtrar livremente coisas que você não quer ver
    Embora seja uma tag confusa, pelo menos ela não prejudica o autor