Como o site da Tramoia foi construído

A Tramoia é uma zine brasileira sobre hacking, tecnologia e cultura digital cuja própria apresentação visual funciona como parte do conteúdo. O site não apenas imita um terminal antigo: páginas, molduras, logotipos e ilustrações foram compostos como arte de texto, preservando a linguagem gráfica de BBSs, artpacks ANSI, demoscene e revistas eletrônicas distribuídas em arquivos.

Esta pesquisa reconstrói o projeto a partir do site publicado, do repositório público da Tramoia, do histórico de alterações, dos arquivos-fonte e das referências deixadas no código. O objetivo é explicar, com evidências, como o resultado foi obtido, por que ele é tão marcante, quais partes ainda não estão documentadas e como construir algo semelhante.

Resumo executivo

O site da Tramoia é surpreendentemente simples na infraestrutura e sofisticado na direção artística:

• Não utiliza React, Vue, Astro, Next.js, Three.js, WebGL ou um CMS.
• É composto por HTML, CSS, fontes WOFF locais e JavaScript puro.
• Está hospedado como site estático no GitHub Pages, usando o domínio próprio tramoia.sh.
• A maior parte do desenho foi produzida como arte ANSI/CP437 e convertida para HTML.
• O conversor identificado com segurança é o projeto aberto rambkk/ansi-tools, creditado em comentários dentro das páginas.
• Cada trecho colorido da arte se transforma em um <span> com cor de texto e fundo. Por isso, uma única página pode conter milhares de elementos.
• As fontes vêm da tradição visual do IBM PC e correspondem a arquivos distribuídos pelo The Ultimate Oldschool PC Font Pack.
• A página principal usa uma simulação de fluidos escrita em JavaScript puro, inspirada no método de Jos Stam, que trata os caracteres da arte como obstáculos.
• A edição TRM 0x2 usa uma adaptação do clássico efeito de fogo de Doom, baseada na explicação de Fabien Sanglard. O fogo é formado pelas letras t, r, m, T, R e M.
• Os artigos parecem nascer como texto simples, ser diagramados numa grade ANSI e então convertidos para HTML. A ferramenta exata de desenho ou diagramação não foi documentada.
• A proposta funciona porque conteúdo, interface, assunto e técnica falam a mesma língua. Não é apenas um tema retrô aplicado a uma página convencional.

Em uma frase: a Tramoia é uma zine ANSI transformada em website, enriquecida com pequenos efeitos de demoscene e publicada por uma infraestrutura estática mínima.

Metodologia e critérios

A análise combinou:

1. inspeção do HTML, CSS e JavaScript entregues pelo site;
2. observação do DOM antes e depois da execução dos scripts;
3. verificação dos cabeçalhos HTTP e registros DNS;
4. leitura integral dos scripts fluid.js e doom_fire.js;
5. inspeção dos arquivos .ans, .txt, fontes e páginas de artigos;
6. análise da árvore e dos 19 commits públicos do repositório;
7. comparação da saída HTML com o conversor citado nas próprias páginas;
8. consulta às referências acadêmicas e técnicas deixadas pelos autores;
9. busca por diretórios, perfis e menções externas ao projeto.

As conclusões são classificadas desta forma:

As medições de DOM, arquivos e resposta do servidor refletem o estado observado em 29 de julho de 2026 e podem mudar.

O que é a Tramoia

A Tramoia se apresenta como uma zine brasileira de hacking. Sua estrutura remete às ezines e publicações de comunidades técnicas anteriores à web social: edições fechadas, expediente, artigos extensos, pseudônimos, endereços de contato e uma identidade visual criada com caracteres.

O projeto possui:

• uma página principal que funciona como capa, manifesto e ponto de entrada;
• a edição 0x1, disponível no diretório /trm1/;
• a edição 0x2, disponível em /trm2/;
• artigos individuais em HTML;
• versões em texto simples de vários artigos;
• artes originais em .ans;
• links para GitHub, Discord e perfil social.

O diretório Weird Net também classifica a Tramoia como uma zine brasileira de hacking com edições apresentadas em ASCII/ANSI. Essa descrição externa é coerente com o que os arquivos mostram.

A resposta curta: qual é a stack

Não há package.json, projeto Vite, configuração de Astro, Jekyll, Hugo, Eleventy, Webpack, banco de dados, API, painel administrativo ou processo de compilação versionado. O navegador recebe arquivos prontos.

Arquitetura pública do projeto

O repositório está na organização TRAMOIA-sh e usa o nome TRAMOIA-sh.github.io, padrão de repositórios de sites de organização no GitHub Pages. Um arquivo CNAME contém tramoia.sh, vinculando o domínio personalizado.

Uma representação simplificada da árvore é:

TRAMOIA-sh.github.io/
├── CNAME
├── index.html
├── style2.css
├── fluid.js
├── Web437_IBM_VGA_8x14.woff
├── Web437_IBM_VGA_9x8.woff
├── WebPlus_HP_100LX_6x8.woff
├── WebPlus_IBM_CGAthin.woff
├── WebPlus_IBM_VGA_8x16.woff
├── WebPlus_ToshibaSat_8x14.woff
├── trm1/
│   ├── index.html
│   ├── style.css
│   ├── artigos em .html
│   ├── fontes em .txt
│   └── imagens
└── trm2/
    ├── index.html
    ├── style.css
    ├── doom_fire.js
    ├── fire.js
    ├── artigo.html
    ├── artigos em .html
    ├── fontes em .txt
    └── artes em .ans

No estado analisado, o repositório possuía aproximadamente:

O predomínio de HTML não vem de uma aplicação complexa, mas da conversão de cada mudança de cor da arte ANSI em marcação individual.

Como a arte ANSI vira uma página web

1. A composição nasce numa grade de caracteres

Arte ANSI combina:

• caracteres do conjunto IBM Code Page 437;
• blocos, sombreados e linhas de moldura;
• sequências de escape para controlar cores;
• largura fixa, normalmente de 80 ou 120 colunas;
• metadados opcionais no padrão SAUCE.

É uma forma de arte de texto diferente de uma imagem raster. Cada posição continua sendo um caractere, mas fonte, cor e alinhamento fazem a página parecer uma ilustração.

Os arquivos .ans da Tramoia contêm sequências ANSI e registros SAUCE válidos. Entre os metadados encontrados:

O padrão SAUCE, criado pela ACiD em 1994, anexa dados como título, autor, grupo, data, dimensões e fonte a obras de texto. Sua presença comprova que os .ans não são meros arquivos renomeados: pertencem ao fluxo tradicional da ANSI art.

2. Um conversor transforma cores em <span>

Quase todas as páginas convertidas trazem no final o comentário:

<!-- https://github.com/rambkk/ansi-tools !-->

O ansi-tools oferece exatamente o processo necessário:

php ansi_to_html.php -f ARTE.ANS > ARTE.html

O conversor:

• interpreta sequências de cor ANSI;
• converte CP437 para Unicode UTF-8;
• lê informações SAUCE;
• preserva modos de cor como iCE;
• produz trechos HTML no formato usado pela Tramoia.

Uma linha convertida fica conceitualmente assim:

<pre id="artpre">
  <span style="color:white; background:black">╔══════════╗</span>
  <span style="color:aqua; background:black"> TRAMOIA  </span>
  <span style="color:white; background:black">╚══════════╝</span>
</pre>

Na prática, a arte tem centenas de linhas e milhares de mudanças de cor. A página principal possuía 2.937 elementos <span> na inspeção realizada. O índice estático da TRM 0x2 começava com 1.210 spans; após a animação de fogo ser criada, a página passava de 2.500 spans.

3. Links reais são inseridos no desenho

O texto visual continua dentro de <pre>, mas algumas áreas são transformadas em elementos <a>. Isso permite clicar em títulos de artigos, contatos e navegação sem abandonar a composição monoespaçada.

Esta etapa provavelmente é manual ou semiautomática. O conversor ANSI conhece cores e caracteres, mas não tem como adivinhar que determinado título precisa apontar para uma página. Não existe no repositório um gerador que automatize a injeção dos links.

4. O HTML recebe uma moldura mínima

O documento final usa uma estrutura extremamente curta em torno da arte:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>TRAMOIA</title>
    <link rel="stylesheet" href="style.css">
  </head>
  <body>
    <div class="txtdiv">
      <pre id="artpre">...</pre>
    </div>
    <script src="efeito.js"></script>
  </body>
</html>

O peso artístico está no conteúdo do <pre>, não em componentes de interface.

Como os artigos parecem ser produzidos

Os arquivos .txt contêm a prosa original, com títulos, parágrafos, referências e blocos de código. O texto correspondente reaparece dentro das páginas HTML, quebrado em linhas e envolvido pela moldura ANSI. Existe ainda trm2/artigo.html, que funciona como um molde visual vazio.

A sequência mais provável é:

1. o autor entrega o artigo como texto simples;
2. a equipe revisa e quebra o texto para a largura da edição;
3. o conteúdo é colocado dentro de uma moldura ou template ANSI;
4. títulos, separadores, cores e ilustrações são diagramados;
5. a arte ANSI é convertida com ansi-tools;
6. links são acrescentados ao HTML;
7. o arquivo pronto é enviado ao repositório.

Essa reconstrução é uma inferência forte, sustentada pela coexistência de .txt, .ans, template e HTML final. Não há um manual ou script de build público que confirme cada passo.

Também não é possível afirmar se a equipe desenhou as peças no PabloDraw, Moebius, TheDraw, outro editor ou ferramentas próprias. Moebius e PabloDraw são opções adequadas para reproduzir o processo, mas não devem ser apresentadas como ferramentas confirmadas da Tramoia.

A tipografia que faz o navegador parecer um IBM PC

O CSS declara seis fontes WOFF com nomes como:

• Web437_IBM_VGA_8x14;
• Web437_IBM_VGA_9x8;
• WebPlus_IBM_CGAthin;
• WebPlus_IBM_VGA_8x16;
• WebPlus_ToshibaSat_8x14.

Esses nomes correspondem à convenção do The Ultimate Oldschool PC Font Pack, coleção de fontes bitmap históricas adaptadas para uso moderno e web.

Na TRM 0x2, o <pre> usa prioritariamente a fonte Toshiba Satellite 8×14, com:

• tamanho de 14 px;
• altura de linha de 14 px;
• espaçamento entre letras igual a zero;
• white-space: pre;
• fundo preto e texto branco.

Essa escolha é decisiva. Uma fonte monoespaçada comum não preservaria as proporções corretas dos blocos, bordas e sombreados. O navegador precisa renderizar cada célula quase como uma tela em modo texto.

O CSS contém ainda:

• centralização da composição;
• links em ciano;
• links visitados em ciano escuro;
• rolagem horizontal em telas pequenas;
• tamanhos menores por clamp() em breakpoints;
• animações de cor e sombra para links e elementos com classe .torch;
• translateZ(0) e will-change como sugestões de otimização ao navegador.

A animação da capa: fluido colidindo com letras

O arquivo fluid.js tem cerca de 994 linhas e foi escrito sem biblioteca externa. Seus comentários citam:

• o artigo acadêmico Real-Time Fluid Dynamics for Games, de Jos Stam;
• o tutorial Fluid Simulation for Dummies, de Mike Ash.

Como funciona

O script:

1. mede uma célula da fonte no navegador;
2. lê o texto de #artpre;
3. transforma a área visível em uma grade;
4. marca todo caractere não vazio da arte como uma célula sólida;
5. reconhece certos pontos do desenho como emissores;
6. aloca campos numéricos para densidade e velocidade;
7. executa difusão, projeção e advecção;
8. injeta densidade e movimento aleatórios;
9. reage ao movimento do ponteiro;
10. desenha o resultado em camadas de texto sobre a arte original.

Na medição realizada, a simulação criou uma grade de 250 × 245, ou 61.250 células. Aproximadamente 34,9% estavam ativas naquele momento.

O detalhe mais criativo é que a arte não serve apenas de fundo. Os caracteres viram geometria de colisão: o fluido se desloca ao redor do logotipo, das bordas e das letras. É isso que dá integração ao efeito.

Como é desenhado sem Canvas

O script cria três elementos <pre> posicionados sobre a composição. Cada quadro substitui o textContent dessas camadas por grades de caracteres em tons de azul e ciano. Densidades diferentes escolhem caracteres diferentes, produzindo a ilusão de vapor ou líquido.

Portanto:

• não há Canvas 2D;
• não há WebGL;
• não há shader;
• não há Three.js;
• não há vídeo ou GIF;
• não há imagem de fundo animada.

É computação numérica convertida de volta em texto.

O algoritmo de Jos Stam

O método conhecido como Stable Fluids resolve uma aproximação visualmente estável do movimento do fluido. O código da Tramoia implementa as operações clássicas:

• difusão, que espalha densidade e velocidade;
• projeção, que reduz divergência e dá aparência incompressível;
• advecção, que transporta valores pelo campo de velocidade;
• condições de contorno, adaptadas para bordas e obstáculos;
• iterações do solucionador para aproximar o resultado.

O site não pretende ser uma simulação científica de alta precisão. É uma aplicação artística, otimizada o suficiente para produzir movimento coerente no navegador.

A animação da TRM 0x2: fogo de Doom feito de “TRM”

O arquivo trm2/doom_fire.js implementa um efeito inspirado no fogo de Doom para PlayStation. O comentário no código aponta para a análise How DOOM fire was done, de Fabien Sanglard.

Princípio do efeito

O fogo clássico usa uma matriz de intensidades:

1. a base recebe valores altos, que representam calor;
2. cada célula transfere parte da intensidade para uma célula acima;
3. um valor aleatório reduz o calor;
4. pequenos deslocamentos laterais criam turbulência;
5. cada intensidade é convertida numa cor de uma paleta.

A versão da Tramoia possui:

• uma paleta com 37 tons, do preto ao branco, passando por vermelho, laranja e amarelo;
• intensidade, decaimento, dispersão e vento configuráveis no código;
• execução-alvo em 14 quadros por segundo;
• uma grade cuja resolução se adapta à arte;
• caracteres sólidos usados como paredes;
• 35 pontos de origem do fogo;
• letras da palavra Tramoia como partículas.

A paleta textual é:

" trmTRM"

À medida que a intensidade sobe, o fogo troca espaços por t, r, m e suas versões maiúsculas. É uma apropriação particularmente boa do algoritmo: a marca passa a ser a matéria da animação.

O DOM produzido

Na página observada, o script calculou:

• grade de 240 × 148;
• 9.772 células sólidas;
• 35 fontes;
• aproximadamente 1.298 spans no overlay de fogo naquele instante.

O resultado também é desenhado num <pre> sobreposto, mas aqui as células ativas viram spans coloridos inseridos por innerHTML.

Painel experimental oculto

O HTML da TRM 0x2 contém um painel de controles comentado. Ele previa ajustes para:

• intensidade;
• decaimento;
• dispersão;
• vento;
• resolução;
• taxa de quadros;
• caractere-fonte;
• pausa.

O JavaScript ainda contém a lógica para conectar esses controles, embora eles não apareçam na página publicada. Isso sugere que o efeito foi desenvolvido de forma interativa e depois teve sua interface de laboratório removida da versão final.

Um protótipo alternativo não utilizado

O diretório também guarda fire.js, um experimento maior, com mais de 1.500 linhas e referências a outro artigo sobre simulação de fogo. Esse arquivo não é carregado pela página publicada. O efeito visível vem de doom_fire.js.

Essa distinção evita concluir, erroneamente, que todo código encontrado no repositório faz parte da produção.

Detalhes do HTML ao vivo

Página principal

Na inspeção realizada:

• uma única área <pre> concentra a obra;
• foram encontrados 2.937 spans;
• havia 16 links;
• não existiam imagens, SVG, Canvas, vídeo ou áudio;
• o arquivo HTML tinha aproximadamente 169 KB;
• fluid.js criava três camadas de texto com cerca de 61 mil posições cada.

TRM 0x2

Na inspeção realizada:

• o índice estático tinha 1.210 spans;
• havia links para dez artigos;
• o overlay de fogo acrescentava mais de mil spans;
• a arte ocupava uma área aproximada de 960 × 1.022 px no viewport usado;
• o JavaScript registrava a grade, as paredes e as fontes no console.

Artigos

Os artigos podem ser muito maiores que seus textos-fonte. Um texto de dezenas de quilobytes se torna uma página de centenas de quilobytes porque cada sequência colorida recebe marcação repetida.

Foram observados exemplos com:

• mais de 3 mil spans em uma página de aproximadamente 204 KB;
• quase 5 mil spans em uma página de aproximadamente 311 KB;
• páginas individuais acima de 450 KB.

Isso é o custo direto de preservar a arte como HTML colorido em vez de achatá-la numa imagem.

Hospedagem, domínio e entrega

Os cabeçalhos HTTP continham Server: GitHub.com, além de sinais da infraestrutura de cache usada pelo GitHub Pages. Os registros DNS do domínio raiz apontavam para os quatro endereços IPv4 documentados para GitHub Pages:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

O arquivo CNAME do repositório confirma o domínio:

tramoia.sh

O GitHub Pages publica arquivos HTML, CSS e JavaScript diretamente de um repositório. O suporte a domínio personalizado permite manter a hospedagem estática sem exibir o endereço github.io.

Consequências práticas:

• não existe servidor de aplicação para manter;
• não há banco de dados;
• cada atualização é um commit;
• o GitHub distribui os arquivos e cuida do TLS;
• o conteúdo continua acessível mesmo se as animações falharem;
• a superfície de ataque é pequena;
• o custo de hospedagem tende a ser nulo, fora domínio e e-mail.

Os registros de e-mail apontavam para encaminhamento da Porkbun, uma camada separada do site.

Histórico e autoria técnica

O repositório possuía 19 commits públicos no momento da pesquisa. A linha do tempo principal é:

O commit de publicação da 0x2 adicionou 35 arquivos e mais de 12 mil linhas. O histórico atribui a maior parte das alterações a identidades Git associadas a Caio Lüders, cujo perfil público liga tecnologia, segurança e arte. Também aparecem contribuições de Alley Pereira e Joao Fukuda.

Isso permite apontar Caio como principal implementador no histórico público, mas não autoriza relacionar automaticamente todos os pseudônimos do expediente a pessoas civis específicas. Os créditos editoriais da própria zine devem ser preservados como são apresentados.

Por que o resultado parece tão especial

1. A tecnologia não é decorativa

Um site convencional poderia usar uma fonte verde, um fundo preto e chamar isso de “terminal”. A Tramoia vai além: trabalha com limitações, formatos, caracteres, cores e processos realmente ligados à cultura que referencia.

2. A forma reforça o assunto

Hacking, BBS, underground digital, engenharia reversa, segurança, ANSI art e zines eletrônicas pertencem ao mesmo universo histórico. O leitor aprende algo sobre essa cultura apenas ao navegar.

3. Há contraste entre baixa e alta tecnologia

O conteúdo parece uma tela DOS, mas por baixo existe:

• conversão precisa de codificação;
• tipografia web;
• simulação numérica;
• detecção de obstáculos;
• interação com ponteiro;
• adaptação responsiva;
• publicação distribuída.

4. A página é uma obra, não um conjunto de componentes

Não há cabeçalho genérico, cartões repetidos, botão chamativo ou seção de marketing. A composição inteira é tratada como uma peça gráfica contínua. Isso produz autoria visual difícil de obter com bibliotecas de componentes.

5. O movimento respeita a linguagem do texto

O fluido é desenhado com caracteres. O fogo é desenhado com TRM. Nenhum efeito parece importado de um banco de animações.

6. A imperfeição artesanal contribui

O repositório inclui experimentos, arquivos grandes, código repetido e um fluxo editorial aparentemente manual. Para um produto comercial isso exigiria organização; para uma zine, também registra o processo e reforça a sensação de objeto feito por pessoas.

O que não foi possível confirmar

Apesar de o código publicado revelar quase toda a camada web, alguns detalhes permanecem desconhecidos:

• qual editor ANSI foi usado;
• quem desenhou cada peça visual;
• se há scripts privados para montar os artigos;
• como ocorre revisão e aprovação editorial;
• se o HTML recebe ajustes manuais depois da conversão;
• qual foi a divisão exata entre programação, arte e diagramação;
• quais mudanças visuais foram planejadas antes da implementação;
• se existe um arquivo mestre não publicado para cada edição.

Não foram encontradas entrevistas técnicas, README de produção, documentação de build ou bastidores detalhados. Qualquer resposta mais específica sobre essas etapas seria especulação.

Qualidade técnica: acertos

Infraestrutura simples

O projeto pode ser compreendido, arquivado e servido sem instalar dezenas de dependências. Não existe cadeia de atualização de framework.

Conteúdo legível sem JavaScript

Desativar JavaScript remove fluidos e fogo, mas preserva texto e navegação. Esse é um bom exemplo de aprimoramento progressivo.

Autonomia e privacidade

Não foram encontrados rastreadores, pixels de publicidade, bibliotecas externas em tempo de execução ou chamadas obrigatórias a APIs. Fontes e scripts são locais.

Endereços permanentes

Cada artigo possui URL própria e pode ser ligado diretamente.

Código e história públicos

O repositório permite estudar as escolhas, baixar a zine e acompanhar mudanças.

Coerência estética excepcional

O principal acerto não é mensurável por Lighthouse: é a consistência entre conteúdo, técnica, público e identidade.

Qualidade técnica: limitações e problemas

HTML muito volumoso

Milhares de estilos inline repetem color e background e inflam o tamanho dos documentos. Classes reutilizáveis reduziriam bastante o volume.

Custo de animação no DOM

A capa atualiza grandes grades textuais, e o fogo recria muitos spans coloridos. Em dispositivos lentos, isso pode consumir CPU, memória e bateria. Canvas 2D poderia preservar a aparência com menos nós DOM.

Movimento sem preferência de acessibilidade

Não foi encontrado tratamento para prefers-reduced-motion. Também não há um controle visível de pausa, apesar de a TRM 0x2 possuir código para isso.

Pouca semântica

Os artigos estão visualmente estruturados, mas quase tudo pertence a um <pre>. Faltam elementos como:

• <main>;
• <article>;
• cabeçalhos <h1> e <h2>;
• navegação semântica;
• idioma no elemento <html>;
• índice acessível.

Leitores de tela recebem uma longa sequência de caracteres decorativos antes ou junto do conteúdo.

Zoom desabilitado

O viewport observado inclui maximum-scale=1.0 e user-scalable=no. Isso prejudica pessoas que precisam ampliar o texto, especialmente porque as regras móveis reduzem bastante a fonte.

Metadados e descoberta mínimos

Não foram encontrados, nas páginas principais analisadas:

• descrição;
• Open Graph;
• cartão para redes sociais;
• URL canônica;
• dados estruturados;
• feed RSS;
• sitemap;
• manifesto;
• mecanismo de busca.

Processo não reproduzível

O repositório não possui README, licença explícita, comando de build ou instrução editorial. O resultado está aberto para leitura, mas o fluxo de produção não está pronto para novos colaboradores.

Pequenos defeitos observáveis

• os endereços de e-mail da página inicial foram interpretados como caminhos relativos do site, não como links mailto:;
• doom_fire.js possui mais de um caminho de inicialização e produziu mensagens repetidas no console;
• uma variável relacionada à colisão no laço de propagação do fogo está fixada como falsa, embora outras verificações de parede ainda sejam usadas;
• o protótipo fire.js permanece no diretório sem estar ligado à página;
• na data da verificação, a versão HTTP respondeu conteúdo em vez de apresentar redirecionamento explícito para HTTPS.

Esses detalhes não destroem a experiência, mas mostram que a página é uma obra experimental, não um produto endurecido para todos os cenários.

Como construir algo semelhante

Caminho A: reprodução historicamente fiel

Este método busca a mesma materialidade da Tramoia.

Ferramentas

• editor de texto para os artigos;
• Moebius, PabloDraw ou outro editor ANSI;
• arquivos de fonte do Oldschool PC Font Pack;
• ansi-tools;
• HTML, CSS e JavaScript;
• GitHub Pages ou hospedagem estática equivalente.

Processo

1. Escolher uma largura fixa, como 80 ou 120 colunas.
2. Escrever o artigo em Markdown ou texto simples.
3. Quebrar as linhas para caber na grade.
4. Criar uma moldura reutilizável no editor ANSI.
5. Inserir títulos, separadores, créditos e ilustrações.
6. Salvar .ans com metadados SAUCE.
7. Converter para HTML com ansi-tools.
8. Envolver a saída num <pre> que use a fonte correta.
9. Adicionar links reais aos títulos e referências.
10. Criar CSS responsivo e rolagem horizontal controlada.
11. Acrescentar uma animação própria, opcional.
12. Publicar os arquivos estáticos.

Estrutura sugerida

site/
├── index.html
├── style.css
├── effects.js
├── CNAME
├── fonts/
├── ansi/
│   ├── capa.ans
│   └── edicao-001.ans
├── sources/
│   └── artigos/
└── edicao-001/
    ├── index.html
    └── artigos/

Caminho B: mesma estética com engenharia moderna

É possível preservar a obra e melhorar manutenção, desempenho e acessibilidade.

Fonte única de conteúdo

Manter cada artigo em Markdown, com metadados:

---
title: "Título do artigo"
author: "Pseudônimo"
edition: "0x3"
slug: "titulo-do-artigo"
---

Um script de build poderia:

1. converter o texto para uma versão legível e semântica;
2. gerar a versão diagramada em ANSI;
3. converter ANSI para HTML;
4. inserir links a partir de marcadores;
5. gerar índice, RSS, sitemap e metadados sociais;
6. validar URLs e documentos.

Cores como classes

Em vez de repetir estilos inline:

<span class="fg-white bg-black">texto</span>

.fg-white { color: #aaa; }
.fg-cyan { color: #0ff; }
.bg-black { background: #000; }

Isso diminui o HTML e facilita mudar a paleta.

Duas camadas de leitura

Uma implementação acessível pode manter:

• a arte ANSI visível, marcada como decorativa quando apropriado;
• o mesmo artigo em HTML semântico para leitores de tela, busca e modo de leitura;
• um botão “modo texto”;
• navegação por títulos e landmarks.

Não basta esconder toda a versão textual com CSS de maneira que mecanismos de busca a confundam com conteúdo duplicado. A relação entre os dois modos deve ser clara e funcional.

Animação em Canvas

O cálculo de fluidos ou fogo pode continuar em JavaScript, mas a renderização pode usar Canvas 2D:

• menos elementos no DOM;
• atualização mais barata;
• possibilidade de usar um Web Worker;
• escala adaptável;
• pausa quando a aba não está visível;
• redução de resolução em aparelhos lentos.

Para conservar a aparência, o Canvas pode desenhar caracteres com a mesma fonte bitmap, em vez de trocar o efeito por partículas convencionais.

Acessibilidade obrigatória

@media (prefers-reduced-motion: reduce) {
  .animated-layer {
    display: none;
  }
}

Também seria importante:

• não bloquear zoom;
• oferecer pausa;
• manter contraste suficiente;
• definir lang="pt-BR";
• permitir navegação por teclado;
• usar foco visível;
• não comunicar informação apenas por cor;
• fornecer uma versão linear dos artigos.

Publicação automática

Uma ação de integração contínua poderia:

• converter os .ans;
• gerar o site;
• verificar links;
• medir tamanho;
• testar páginas sem JavaScript;
• publicar no GitHub Pages.

Essa automação não existe no repositório analisado; é uma recomendação para uma evolução ou projeto inspirado nele.

Como recriar o efeito de fogo

Uma versão mínima do algoritmo pode seguir esta lógica:

const width = 120;
const height = 60;
const heat = new Uint8Array(width * height);

function seedBottom() {
  const start = (height - 1) * width;
  heat.fill(36, start);
}

function propagate() {
  for (let y = 1; y < height; y += 1) {
    for (let x = 0; x < width; x += 1) {
      const source = y * width + x;
      const decay = Math.floor(Math.random() * 3);
      const drift = Math.floor(Math.random() * 3) - 1;
      const targetX = Math.max(0, Math.min(width - 1, x + drift));
      const target = (y - 1) * width + targetX;

      heat[target] = Math.max(0, heat[source] - decay);
    }
  }
}

Depois:

1. mapear 0..36 para uma paleta;
2. mapear faixas de calor para " trmTRM";
3. ignorar ou desviar células ocupadas pela arte;
4. desenhar em Canvas ou numa camada <pre>;
5. limitar a taxa de quadros;
6. pausar fora da tela;
7. respeitar redução de movimento.

O elemento autoral não está no algoritmo básico, amplamente conhecido, mas em fazer o fogo interagir com a diagramação e usar as letras da publicação.

Como recriar a simulação de fluido

Uma implementação inspirada na capa precisa de:

1. uma grade de densidade;
2. duas grades de velocidade, horizontal e vertical;
3. buffers auxiliares;
4. difusão;
5. projeção;
6. advecção;
7. fontes de densidade e velocidade;
8. mapa de obstáculos extraído da arte;
9. renderização em caracteres;
10. interação do ponteiro.

O artigo de Jos Stam é a base matemática; o texto de Mike Ash oferece uma tradução didática para código. Para um projeto real, é prudente:

• começar sem obstáculos;
• validar o movimento numa grade pequena;
• adicionar bordas;
• transformar caracteres não vazios em sólidos;
• adicionar emissor e interação;
• só então investir na paleta textual.

Uma resolução menor, ampliada visualmente, costuma ser suficiente. Na capa da Tramoia, a grade observada tinha mais de 61 mil células, o que já exige atenção a desempenho.

Estimativa de dificuldade

Construir “uma página que parece ANSI” é relativamente fácil. Construir algo tão coerente, legível e autoral quanto a Tramoia é difícil porque a maior parte do valor está na arte e na direção editorial, não na quantidade de código.

Recomendações práticas

Para estudar o projeto

1. Começar pelo repositório público.
2. Comparar um .txt com seu artigo .html.
3. Abrir os .ans num editor compatível e examinar os registros SAUCE.
4. Executar ansi-tools numa arte pequena.
5. Ler primeiro doom_fire.js, que tem um modelo mais simples.
6. Estudar depois fluid.js junto às referências de Jos Stam e Mike Ash.
7. Desativar JavaScript no navegador para separar conteúdo-base de efeitos.

Para criar uma obra inspirada

Prioridade recomendada:

1. definir assunto, voz e identidade;
2. fazer uma excelente capa ANSI estática;
3. criar um artigo completo e legível;
4. testar fonte, largura e celulares;
5. publicar sem animação;
6. acrescentar um único efeito que tenha relação com a marca;
7. criar modo acessível e redução de movimento;
8. automatizar o processo apenas depois que o formato estiver maduro.

Para não produzir uma cópia vazia

Evitar:

• reproduzir o logotipo ou os desenhos da Tramoia;
• copiar a paleta e o fogo sem uma justificativa própria;
• usar “visual terminal” em conteúdo sem relação com essa cultura;
• sacrificar leitura apenas para parecer antigo;
• adicionar muitos efeitos concorrentes;
• atribuir aos autores ferramentas que eles não documentaram.

O melhor aprendizado é o princípio: escolher uma linguagem técnica ligada ao tema e explorá-la como meio artístico.

Melhor equilíbrio técnico

Para um novo projeto, a recomendação é:

• Markdown como fonte editorial;
• .ans preservado como arte original;
• conversão automatizada;
• HTML semântico em paralelo;
• fontes WOFF locais;
• CSS pequeno;
• Canvas 2D para efeitos;
• JavaScript sem framework, se o escopo continuar pequeno;
• GitHub Pages ou Cloudflare Pages;
• RSS, sitemap e metadados sociais;
• redução de movimento e controle de pausa;
• README, licença e documentação de build.

Framework não é requisito. A simplicidade é parte da força da proposta.

Conclusão

A Tramoia foi construída como uma publicação estática de arte textual. Seus autores combinaram arquivos ANSI, caracteres CP437 convertidos para Unicode, fontes históricas do IBM PC, HTML baseado em <pre> e milhares de spans, CSS próprio e JavaScript puro. O site é servido pelo GitHub Pages em domínio personalizado, sem backend, banco de dados, CMS ou framework de frontend.

A capa acrescenta uma simulação de fluidos baseada no método de Jos Stam; a TRM 0x2 acrescenta fogo inspirado em Doom, usando as letras TRM como partículas e a própria arte como obstáculo. O conversor rambkk/ansi-tools está explicitamente creditado e explica a estrutura repetitiva do HTML.

O processo editorial exato não está publicado, mas as evidências indicam texto simples, diagramação numa grade ANSI, conversão para HTML e inserção de links. O editor de ANSI não pode ser identificado com segurança.

O aspecto mais admirável do projeto não é uma biblioteca secreta. É a disciplina de levar uma ideia estética até o fim: conteúdo, código, tipografia, animação, hospedagem e história da mídia foram tratados como uma só obra. Essa coerência é o verdadeiro “efeito especial” da Tramoia.

Fontes consultadas

Projeto e código

• Site oficial da Tramoia
• TRAMOIA 0x2
• Repositório público TRAMOIA-sh.github.io
• Organização TRAMOIA-sh no GitHub
• Histórico de commits do site
• Commit de publicação da TRM 0x2
• Código da simulação de fluidos
• Código do fogo da TRM 0x2
• CSS da TRM 0x2
• HTML do índice da TRM 0x2
• Perfil público de Caio Lüders no GitHub

ANSI, fontes e técnicas visuais

• rambkk/ansi-tools: conversão de ANSI para HTML
• SAUCE: Standard Architecture for Universal Comment Extensions
• The Ultimate Oldschool PC Font Pack
• Moebius ANSI and ASCII Editor
• How DOOM fire was done, por Fabien Sanglard
• Real-Time Fluid Dynamics for Games, por Jos Stam
• Fluid Simulation for Dummies, por Mike Ash

Hospedagem e contexto

• O que é GitHub Pages
• Domínios personalizados no GitHub Pages
• Tramoia no diretório Weird Net
• Menção pública à Tramoia como zine brasileira ativa

Nota sobre atualidade

Pesquisa concluída em 29 de julho de 2026. O site, o repositório, os scripts, o histórico e a infraestrutura podem mudar. Informações técnicas sujeitas a alterações devem ser confirmadas no código e nas páginas oficiais antes de serem reutilizadas em produção.