O que um FDX exportado não traz de volta
Um arquivo FDX escrito pelo SlateX e que volta para o app não equivale a instalar de novo o projeto original tal como ele era. No nível de arquivo, ele escreve o nome do projeto; no nível de cena, a troca gira em torno de número da cena, INT/EXT, nome da cena, horário do dia, oitavos, cor de revisão, marcação de omissão, número da página e itens de roteiro. Os dados do app que não estão nesse conjunto escrito não conseguem voltar por esse arquivo. Mais importante: mesmo um valor que esteja dentro do alcance da escrita pode, cada vez que um arquivo é exportado e relido, sofrer reescritas definidas por um comportamento fixo.
O teto do que o FDX consegue trazer de volta é definido primeiro pelo alcance do que se escreve; e um valor que esteja nesse alcance também não volta necessariamente ao estado original, letra por letra.
O alcance do que se escreve é o teto do que volta
Somando o nível de arquivo e o nível de cena, a exportação conserva o nome do projeto junto com número da cena, INT/EXT, nome da cena, horário do dia, oitavos, cor de revisão, marcação de omissão, número da página e itens de roteiro. Planos, registros de tomada, câmeras, timecode (incluindo o timecode de som Sound TC) e caminhos de mídia não estão nessa estrutura de escrita do FDX, portanto esses registros do set não podem ser recuperados a partir desse arquivo.
Essa é a divisão de trabalho entre “O que o FDX troca e o que ele deixa perder” e este texto. O texto pai descreve o alcance da troca; aqui se olha apenas o que acontece com o conteúdo que está dentro desse alcance quando o mesmo arquivo de troca de roteiro sai e volta, e qual conteúdo simplesmente não tem nenhum veículo de volta.
Três comportamentos do cabeçalho de cena e do resumo que é preciso distinguir na ida e volta
Um deles é a sobreposição do cabeçalho de cena. Numa cena importada do FDX, o nome da cena conserva o título original por inteiro, enquanto INT/EXT e horário do dia ficam gravados cada um numa parte separada; ao exportar de novo, o cabeçalho é remontado com “prefixo de INT/EXT + título original por inteiro + separador + horário do dia original”, e então o título e o texto do horário do dia são sobrepostos mais uma vez. Uma cena criada manualmente dentro do app difere nesse ponto, porque essas três partes já eram guardadas separadas, de modo que ali não existe a mesma origem de sobreposição.
Outro é o ponto final. Na importação, um prefixo como INT. é conservado como está, e na exportação só se acrescenta um ponto quando o fim não tem nenhum, então uma ida e volta não produz o ponto duplo de algo como INT..; o que se repete são o título e a marcação de dia e noite dentro do cabeçalho de cena. O que se diz aqui é o resultado das regras de leitura e de escrita combinadas, e não uma inferência sobre o comportamento de softwares de roteirização de terceiros.
O terceiro é a substituição do resumo. Na importação, conteúdo de notas ou de resumo pode entrar no resumo da cena, e, quando não existe esse resumo pendente a ser escrito, o parágrafo de Action ou o parágrafo comum que abre a cena também pode ser usado como resumo; por isso, o resumo pode conter o texto completo da descrição de ação, e não uma sinopse da trama. A exportação também não grava o resumo da cena de volta na propriedade correspondente, então, ao reimportar, essa posição pode ser ocupada outra vez pelo parágrafo de Action ou pelo parágrafo comum de abertura.
Ainda há três mudanças de volta que precisam ser vistas à parte
Quando os oitavos da cena são 0, a exportação não grava o atributo de extensão; ao ler de volta, a ausência de extensão é tratada como 1/8 de página, então “0 ou vazio” se transforma em 1/8 de página. O estado das cenas reimportadas é escrito como “não filmada”, e não é possível recuperar pelo FDX o estado de filmagem anterior. Parágrafos de notas ou de resumo não voltam como itens de roteiro nas posições originais, e a ordem dos itens de roteiro recebe nova numeração.
Essas mudanças não querem dizer que o arquivo esteja corrompido; querem dizer que “o que esse formato escreve” e “como os objetos são criados ao ler de volta” não são a mesma coisa. “As várias caras de um valor ausente num arquivo de entrega” ajuda a distinguir formas como string vazia, atributo ausente e marcador de posição, mas aqui ainda se fala só da ida e volta do próprio FDX.
Limite rígido: o comportamento pode ser descrito, mas quatro perguntas ainda exigem a prova em nível de arquivo
A sobreposição do cabeçalho de cena, a substituição do resumo, a omissão do atributo de extensão quando os oitavos são 0 e o preenchimento com 1/8 de página na releitura, o estado “não filmada” gravado na reimportação e os parágrafos de notas ou de resumo que não voltam à posição original como itens de roteiro — com a ordem destes renumerada — são comportamentos que se observam quando este app exporta um arquivo e o relê. Só quatro perguntas ficam fora do que esta página consegue resolver:
Quais campos adicionais um FDX real específico perde. A importação lê apenas os cinco atributos citados; para listar o que mais um arquivo determinado perde, é preciso compará-lo campo a campo com esse mesmo arquivo.
Quais cenas a regra de duplicados realmente filtra. O filtro está em funcionamento, mas o conjunto exato de cenas afetadas depende do arquivo de entrada e deve ser conferido com o resultado da importação.
A interoperabilidade real com software de roteirização de terceiros. Este texto não promete uma ida e volta sem perdas; o resultado de abrir, salvar como e reimportar num software de terceiros depende do arquivo que você realmente usar.
A magnitude real dessas reescritas fixas numa ida e volta concreta. Todas essas reescritas de fato ocorrem; quanto o título, o resumo ou a extensão de um arquivo específico mudam ainda exige comparar o arquivo exportado com o resultado relido.
O limite público é, portanto: a ida e volta não garante preservação literal caractere por caractere. Não se deve ampliar um comportamento já estabelecido para a afirmação de que todo arquivo muda na mesma medida, nem apresentar como confirmado o resultado real de um software de terceiros; a parte receptora deve conferir o arquivo de troca real e, após a releitura, o cabeçalho, a extensão, o resumo e o estado.
A ida e volta não garante preservação literal caractere por caractere; todas essas reescritas de fato ocorrem, mas a mudança real de cada arquivo ainda precisa ser conferida.
FAQ
O FDX consegue trazer planos e registros de tomada junto?
Esses objetos do set não saem da estrutura de escrita atual. Eles estão fora do alcance de troca desse FDX, e a reimportação não os recria do nada.
Por que o cabeçalho de cena pode ganhar mais uma camada de prefixo e de horário do dia?
Uma cena importada conserva o título original por inteiro no nome da cena, enquanto INT/EXT e horário do dia ficam guardados separadamente, e a exportação junta os três de novo. Uma cena criada manualmente difere nesse ponto, porque as três partes já são guardadas separadas.
Por que o resumo pode virar descrição de ação?
Quando não há notas nem resumo pendente a ser escrito, o parágrafo de Action ou o parágrafo comum de abertura pode ser usado como resumo, e o resumo não tem caminho de gravação de volta correspondente. Por isso, ao reimportar, essa posição pode ser ocupada pelo texto completo da descrição de ação.
Estas conclusões significam que um software de roteirização de terceiros já passou na ida e volta?
Não significam. Este texto não dá garantia sobre o resultado real de abrir, salvar como e reimportar num software de roteirização de terceiros, e por isso a parte receptora deve conferir o arquivo que tem em mãos; o limite público fica em que a ida e volta não garante fidelidade letra por letra.
Axiom One LLC — SlateX