Fundamentos / F8.1 · INT/EXT

Como o INT/EXT de um cabeçalho de cena é adivinhado a partir dos separadores

Ao processar um cabeçalho de cena, o SlateX adivinha a partir dos separadores, em vez de comparar a linha com uma lista de termos de INT/EXT. Ele corta primeiro o horário do dia a partir do fim e depois tenta cortar o INT/EXT a partir do início da linha; todo o processo depende de espaço, ponto, forma de hífen e limite de número de caracteres. A língua em si não é o critério, então a mesma regra de escrita pode pegar um caso em chinês e deixar passar um em inglês, ou o contrário.

A divisão do cabeçalho de cena depende de separadores e de limites de caracteres, não de uma lista branca de palavras-chave de INT/EXT ou de horário do dia.

Primeiro corta o horário do dia, depois adivinha o INT/EXT

O horário do dia é tratado primeiro. O programa pega o trecho inteiro depois do último - , ou seja, a forma com espaços dos dois lados do hífen; se essa escrita não for encontrada, ele recua para o último - e exige que o fragmento final cortado passe pela proteção de tamanho.

O INT/EXT é tratado em seguida. O programa tenta dois separadores, primeiro o espaço e depois o ponto, pega o prefixo anterior ao separador e só aceita se ele tiver no máximo 6 caracteres. Não há lista branca de palavras-chave aqui, e a etapa também não lê as predefinições de INT/EXT nem as de horário do dia do projeto; portanto, as listas de predefinições não são a base desta decisão.

Quatro exemplos mostram a linha divisória de verdade

内景 控制室 - 日 tem espaço, então o prefixo 内景 é pego. 内景:控制室 - 日 usa dois-pontos de largura total e não tem espaço depois do prefixo, então esse caminho não chega ao INT/EXT. EXTERIOR. OFFICE - DAY tem um ponto, mas EXTERIOR, antes do ponto, passa de 6 caracteres e por isso não é aceito. Em INT./EXT. 屋顶 - 夜, o caminho do espaço encontra primeiro um prefixo longo demais; o caminho do ponto então acerta, e o resultado pega só INT.

Nesse conjunto de exemplos, a linha divisória visível é existir ou não um espaço utilizável; a regra completa ainda precisa ser lida junto com o caminho do ponto e os limites de tamanho. As duas condições de tamanho contam caracteres, não palavras, por isso cada letra chinesa, japonesa ou coreana entra na decisão como um caractere.

Duas formas engolem outra coisa dentro do campo

Em 1. INT. 控制室 - DAY, o 1. é tomado como prefixo de INT/EXT: o número da cena pode até parecer presente, mas o valor de INT/EXT já está deslocado. No título todo em maiúsculas e sem espaço ROOFTOP-PARTY, o final PARTY é cortado como horário do dia e, ao mesmo tempo, o nome do local fica truncado; isso não é rejeitado ali, e o valor cortado segue para os fluxos seguintes.

Travessão e hífen de largura total de fato não estão entre os dois caminhos de separação atuais. Formas compostas como INT.,EXT. não são “algo que ninguém pega”: o caminho do espaço recebe um prefixo longo demais e o descarta, e o caminho do ponto chega a coincidir, ficando apenas com o INT inicial (mesmo caso acima). O que sobra é um valor de prefixo incompleto, não uma rejeição ali mesmo. Não se pode resumir isso a uma língua que funcione melhor ou pior, porque os mesmos limites de caracteres deixam escapar entradas de maneiras diferentes em línguas diferentes.

O valor errado fica, em vez de ser rejeitado na hora

O prefixo adivinhado como INT/EXT entra como está nas predefinições de INT/EXT do projeto e aparece no menu suspenso da tela de edição. O 1. do exemplo pode, assim, virar uma predefinição selecionável de novo, e o valor final cortado de um título sem separador também entra na lista de predefinições correspondente.

Essa fronteira importa porque “apareceu um valor” não é o mesmo que “o valor corresponde ao sentido do set”. A parte receptora deve conferir, depois da importação, as predefinições de INT/EXT e de horário do dia que aparecerem, sobretudo em cabeçalhos com numeração, prefixo composto ou hífen não padrão.

Um prefixo cortado errado continua entrando na lista de predefinições; o valor errado fica, em vez de ser rejeitado na hora.

O que esta regra não cobre

“Quais partes formam um cabeçalho de cena” trata da composição do cabeçalho como um todo; aqui é mais estreito, e só se mostra como INT/EXT e horário do dia são cortados de uma linha de texto. Quanto à nova exportação e à releitura de que trata “O que um FDX exportado não traz de volta”, a parte receptora deve conferir o resultado real da ida e volta, sem inferir que, porque um corte funcionou uma vez, a volta manterá o mesmo valor.

Esta lógica também não trata todas as variantes de travessão, nem lê os marcadores compostos como um todo. Diante de uma forma que não cabe em nenhum dos caminhos de separação atuais (espaço, ponto ou hífen), ela deve ser tratada como uma entrada a verificar manualmente, em vez de tirar conclusões sobre a origem do formato.

FAQ

As predefinições de INT/EXT do projeto participam da divisão do cabeçalho?

Não. A lógica de divisão atual não tem lista branca de palavras-chave e não lê as predefinições de INT/EXT nem as de horário do dia.

Por que EXTERIOR. OFFICE - DAY não chega ao INT/EXT?

Porque o prefixo antes do ponto tem mais de 6 caracteres e passa do limite atual de tamanho do prefixo. Esse limite conta caracteres, não palavras.

O que INT./EXT. produz?

Pela ordem atual de separadores, ela cai no caminho do ponto e pega só a primeira parte, INT. Isso não significa que a forma composta seja preservada por inteiro.

Um valor cortado errado é descartado?

Nessa etapa ele não é rejeitado. O prefixo pego pode entrar na lista de predefinições, por isso é preciso conferi-lo depois da importação.


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