Por que algumas formas geométricas simplesmente não ficam legíveis na tela
Você provavelmente já tentou colorir um conjunto de polígonos em um arquivo SVG ou num projeto de CAD e descobriu que, na prática, as cores não funcionavam como deveria. O problema não é a teoria — você sabe que um triângulo pode ser azul e um quadrado vermelho. O problema é que, quando você junta seis formas geométricas no mesmo viewport com preenchimentos sólidos, as bordas se perdem, os contrastes falham e o resultado final parece um borrão. Já perdi pelo menos duas horas refazendo diagramas porque não considerei a saturação relativa entre formas adjacentes. O que muita gente não considera de imediato é que a escolha da cor das formas geométricas raramente é sobre estética. É sobre distinguibilidade. E distinguibilidade depende de três coisas: distância perceptual entre as cores, espessura do stroke e o fundo onde o desenho vai ser renderizado. Se qualquer uma dessas variáveis estiver fora de controle, o resto não importa.
cor das formas geométricas — o que funciona na prática
A primeira coisa que eu faço antes de abrir qualquer ferramenta é montar uma paleta em espaço de cor perceptualmente uniforme. Esqueça RGB para isso. Vá de Lab ou OKLCH. A diferença é enorme: em RGB, duas cores que parecem próximas na tela podem estar absurdamente distantes perceptualmente, e vice-versa. Eu uso o OKLCH porque é mais direto — você define luminosidade primeiro, depois croma e matiz, e as cores que resultam têm distância perceptual previsível. Para três formas, uma separação de uns 15 a 20 pontos de luminosidade entre elas costuma ser o mínimo que mantém tudo legível em projeções impressas e em telas com calibração mediana. Um detalhe que pega todo mundo: formas geométricas com áreas muito diferentes exigem tratamento diferente de cor. Um triângulo pequeno sobreposto a um hexágono grande não pode simplesmente receber a mesma saturação. O olho humano tende a subestimar cores saturadas em áreas pequenas e a superestimá-las em áreas grandes. Minha correção simples é reduzir o croma em cerca de 10 a 15 pontos para formas com área inferior a 15% da área total do conjunto. Parece arbitrário até você testar.
Também é importante entender que a cor do preenchimento e a cor do stroke não são a mesma decisão. Muitos projetos falham porque o stroke é aplicado automaticamente com uma cor derivada do preenchimento, geralmente mais escura. Isso funciona para formas isoladas, mas quando há sobreposição ou proximidade, o stroke acaba criando bordas visuais concorrentes que confundem a leitura. O que eu faço é definir o stroke como uma cor neutra de alto contraste em relação ao fundo, não em relação ao preenchimento. Fundo branco? Stroke preto ou cinza muito escuro. Fundo escuro? Stroke branco ou cinza claro. A cor do preenchimento fica apenas para identificar a forma, não para definir sua borda.
Como montar um sistema que não quebra na primeira alteração
Se você está trabalhando com formas geométricas de forma recorrente — seja em documentação técnica, dashboards, visualizações educacionais ou geração de PDFs — montar um sistema baseado em tokens ou variáveis de cor é essencial. A alternativa é clicar em cada forma individualmente toda vez que o cliente mudar a paleta, o que é insuportável em pouco tempo. No meu fluxo atual, eu trabalho com uma tabela de correspondência simples: identificador da forma, classe semântica, cor Lab, cor OKLCH, cor HEX de fallback e espessura padrão do stroke. Cada forma no projeto referencia esse identificador. Quando preciso ajustar a paleta, altero só a tabela e o resto se resolve. Em SVG isso se traduz em classes CSS. Em ferramentas como Figma ou Illustrator, uso estilos de objeto ou swatches ligados a variáveis. Em Python, com matplotlib ou plotly, uso dicionários. O princípio é o mesmo.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um caso concreto que ilustra por que isso importa: em um projeto recente, precisávamos gerar diagramas com dezenas de formas geométricas sobrepostas para um manual técnico. As primeiras versões usavam cores RGB puro, sem separação de luminosidade garantida. O resultado era ilegível para quem tinha visão de cores normal e impossível para quem tinha daltonismo. Refizemos toda a paleta em OKLCH, garantindo diferença mínima de 18 pontos de luminosidade entre quaisquer duas cores adjacentes no diagrama. O tempo de produção aumentou em cerca de 40 minutos na primeira vez, mas nas iterações seguintes a ajustes de paleta passaram de 90 minutos para oito. A diferença é que, sem o sistema de tokens, cada mudança de cor exigia revisão manual de todas as formas.
O problema que ninguém menciona: formas com transparência
Transparência é onde a cor das formas geométricas realmente testa seu projeto. Quando duas formas semitransparentes se sobrepõem, a cor resultante não é uma média simples — ela depende do fundo subjacente, da ordem de renderização e do modelo de mistura ativo. Em SVG, o padrão é Porter-Duff multiply, que escurece. Em ferramentas de design vetorial, costuma ser blend multiplicativo ou normal com alpha. E a maioria das bibliotecas de plotagem científica usa alpha-compositing padrão, que produz resultados diferentes de novo. Meu workaround para isso é simples, mas custa tempo de quem não espera: desistir de transparência para formas que se sobrepõem e usar apenas opacidade plena com cores perceptualmente distintas. Se a sobreposição é essencial para o significado da visualização, aí sim eu trabalho com transparência controlada, mas nunca abaixo de 85% de opacidade, e sempre valido o resultado sobre o fundo final — porque uma cor que funciona sobre branco pode ser completamente diferente sobre um fundo bege ou azul claro.
Outro ponto prático: se você precisa exportar para impressão, cores em modelo RGB precisam ser convertidas para CMYK, e essa conversão pode alterar drasticamente a distinguibilidade. Já vi projetos inteiros quebrarem porque uma cor que parecia distinta na tela virava praticamente a mesma coisa quando impressa. A correção é simples, mas só funciona se você checar antes de enviar para produção. Abre o arquivo no modo de prova de cor da sua ferramenta, com o perfil CMYK do papel que vai usar, e verifica se as diferenças de luminosidade permanecem acima de 12 pontos após a conversão. Se não permanecerem, ajuste as cores antes da conversão, não depois.
Ferramentas e links úteis
Para construção de paletas em espaço perceptualmente uniforme, o OKLCH Color Picker (oklch-color-picker.com) é direto e rápido. Para validar distinguibilidade, o Color Oracle (colororacle.org) simula deficiências visuais em tempo real e economiza muito tempo de teste manual. Se você trabalha com SVG, a extensão SVG Colorblind Checker no repositório oficial do projeto ajuda a identificar pares de cores problemáticos diretamente no arquivo. Para quem programa, a biblioteca Python colour-science (pip install colour-science) permite converter entre espaços de cor e calcular distâncias perceptuais com precisão aceitável. O módulo oklch do pacote palettable também é razoável para geração rápida de paletas discrimináveis. Não são perfeitos, mas resolvem o problema na maioria dos casos.
O que esse método não resolve
É honesto dizer que nenhuma paleta baseada puramente em cor funciona bem quando o número de formas excede sete a oito em um único diagrama. A limitação aqui não é técnica — é cognitiva. O olho humano distingue cores com facilidade até certo ponto, mas a carga de trabalho para associar cada cor a uma forma específica aumenta de forma não linear. Quando você chega nessa faixa, a solução não é melhorar a paleta, é mudar de estratégia: usar padrão de preenchimento (hachuras, texturas), rótulos diretos, ou dividir o conjunto em subdiagramas. Tentar forçar doze formas com cores diferentes vai resultar em algo que parece organizado mas é ilegível na prática, independentemente de quão bom seja o sistema de tokens que você montou. Também vale mencionar que ferramentas automatizadas de geração de paletas frequentemente ignoram a espessura de stroke e a relação com o fundo. Elas otimizam para distinguibilidade entre as cores em si, não para distinguibilidade no contexto de renderização final. Esse descompasso é a razão pela qual uma paleta que funciona perfeitamente no gerador pode falhar miseravelmente quando aplicada ao projeto real. Por isso a validação manual — ou pelo menos semiautomática — continua sendo necessária, mesmo com ferramentas modernas.
