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: o resultado é o arquivo recebido

Se um arquivo traz atributos de cor, numeração ou omissão depende do próprio arquivo. Esta página enuncia a ordem de leitura e o limite da exibição; não promete que uma importação específica vá produzir esta ou aquela cor. Por isso, a conclusão pública só vai até “entra em vigor quando o arquivo traz um atributo de cor reconhecível”.

O resultado concreto de cor de revisão depois de importar um arquivo de troca real deve ser lido nas marcas de revisão visíveis no arquivo recebido. “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 uma ALE, confira estes campos” continua valendo: a parte receptora deve conferir os campos e valores que de fato aparecem no arquivo.

Essa cadeia só pode ser descrita pelas regras de leitura, e um resultado concreto de cor depois de uma importação real deve ser lido nas marcas de revisão visíveis no arquivo recebido.

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 só no arquivo que está em suas mãos dá para conferir se ele traz atributos de cor, numeração ou omissão. Esta página apenas enuncia as regras de leitura, e o resultado concreto são as marcas de revisão visíveis no arquivo recebido.

Axiom One LLC — SlateX