De onde vêm as cores de revisão e em que ordem a importação as lê

As cores de revisão são, antes de tudo, um acordo de revisão herdado da era do papel: as rodadas de revisão se distinguiam por cores de papel diferentes, e não por um campo exclusivo inventado por este ou aquele software. Ao importar um arquivo de troca de roteiro, o SlateX busca a cor em três níveis: primeiro a cor de formatação do próprio parágrafo, depois a cor explícita nas propriedades da cena; só quando as duas primeiras posições não têm cor é que ele tenta buscar um nome de cor nos parênteses do fim do cabeçalho de cena. Mesmo com o nome lido, ainda há a comparação nome a nome do lado da exibição, e sem correspondência o caso é tratado como sem cor.

As cores de revisão vêm de um acordo do setor sobre o fluxo de revisão; o lado da importação apenas lê, numa ordem definida, a informação de cor que já está no arquivo.

Primeiro a cor do parágrafo, depois a cor da cena

A primeira fonte é a cor de formatação que o próprio parágrafo do cabeçalho de cena carrega. Em seguida se olha a cor escrita de forma explícita nas propriedades da cena dentro do arquivo; como esse nível vem mais adiante na ordem de leitura e é mais específico, ele substitui a cor de parágrafo já lida. Ou seja, quando as duas posições têm valor, o valor das propriedades da cena é o que define o resultado.

Só quando nenhuma das duas posições tem cor entra o terceiro nível: verificar se o texto do cabeçalho de cena termina com um nome de cor em todas as letras maiúsculas entre parênteses e normalizar o nome lido em uma forma fácil de comparar depois. Esse recurso exclui de forma explícita a palavra que marca a omissão, para não tomá-la como cor de revisão.

O lado da exibição compara o nome da cor outra vez

Depois de obter o nome da cor, o lado da exibição não pinta qualquer string como uma cor: ele compara o nome lido primeiro com os quatro nomes de cor básicos (blue, pink, yellow, green) e depois com vários nomes estendidos e variantes de segundo nível; sem correspondência, o caso é tratado como sem cor.

Portanto, “o arquivo contém uma string de cor” e “a interface mostra a cor correspondente” não são fatos da mesma camada. Essa cadeia produz cor visível apenas quando o atributo pode ser lido e o nome cai dentro do conjunto comparável pelo lado da exibição. Daqui não se infere uma rodada de revisão a partir de um nome de cor nem se interpreta, em nome da origem do arquivo, o que ele quer dizer.

A detecção de omissão é vizinha da leitura de cor, mas é outra regra

Há duas origens para “esta cena foi omitida”. Uma vem do atributo de omissão do arquivo; a outra verifica diretamente se o texto do cabeçalho de cena contém uma sequência fixa de letras maiúsculas, e essa comparação de texto distingue maiúsculas de minúsculas. Basta o texto do título conter aquela sequência de maiúsculas para que a cena seja tratada como omitida: a linha continua aparecendo na barra lateral, mas o nome da cena fica tachado e acinzentado, e o selo de conclusão, INT/EXT, horário do dia e número de páginas deixam de ser exibidos.

Isso quer dizer que a omissão não pode ser inferida apenas por “há ou não uma cor de revisão”. A leitura de cor e o estado de omissão têm origens próprias, e a busca de cor no fim do título exclui explicitamente a palavra de omissão. A parte receptora deve conferir ela mesma, no arquivo, o atributo de cor, o atributo de omissão e o texto do cabeçalho, sem tratar uma dessas posições como sinal substituto das outras duas.

Limite rígido: as amostras atuais não cobrem essa cadeia

Nossas duas amostras de arquivo atuais não têm nenhum atributo de cor, numeração ou omissão, de modo que essas amostras não cobrem a cadeia de cores de revisão. O código dá para explicar a ordem de leitura e as regras de comparação, mas as amostras não provam que a importação de um arquivo de troca real vá produzir este ou aquele resultado de cor de revisão.

Por isso, a conclusão pública só vai até “entra em vigor quando o atributo pode ser lido”. “Quais partes formam um cabeçalho de cena” cuida da estrutura do cabeçalho em si; e, se o resultado da importação for entregue adiante a quem recebe, o princípio de “Ao receber um ALE, confira estes campos” continua valendo: a parte receptora deve conferir os campos e valores que de fato aparecem no arquivo.

As amostras atuais não têm atributos de cor, numeração ou omissão; essa cadeia só pode ser descrita pelas regras de leitura, e o vazio das amostras não pode ser escrito como um resultado de cor já verificado.

FAQ

As cores de revisão foram inventadas por algum software de roteirização?

Não. O que se adota aqui é um acordo do setor que vem do fluxo de revisão em papel; este App só lê a informação pertinente que aparecer no arquivo de troca.

Quando o arquivo tem cor de parágrafo e cor de cena, qual é usada?

A cor explícita das propriedades da cena substitui a cor de formatação do parágrafo lida antes, porque é mais específica e vem mais adiante na ordem de leitura.

Quando a cor entre parênteses no fim do título é lida?

Só quando os dois primeiros níveis não têm cor é que se busca o nome de cor nos parênteses do fim do cabeçalho, excluindo a palavra que marca a omissão.

Por que não dá para dizer que a importação vai mostrar cores de revisão?

Porque as duas amostras atuais não têm atributos de cor, numeração ou omissão. O que se pode firmar são as regras de leitura do código; se um arquivo específico traz esses atributos, é preciso conferir no arquivo de troca real.

Axiom One LLC — SlateX. Os números acima são os de 2026-09-24.