Cosa non torna da un FDX esportato
Un file FDX scritto da SlateX e poi reimportato nell’app non rimette a posto il progetto originale com’era. A livello di file viene scritto il nome del progetto, e a livello di scena lo scambio ruota attorno a numero di scena, INT/EST, nome della scena, momento del giorno, ottavi, colore di revisione, contrassegno di omissione, numero di pagina ed elementi della sceneggiatura; i dati dell’app che non stanno in questo insieme scritto non possono tornare attraverso questo file. E conta ancora di più un altro fatto: anche i valori che rientrano nell’ambito scritto, ogni volta che il file viene esportato e riletto, subiscono comunque riscritture legate a un comportamento fisso.
Il limite di ciò che FDX può riportare lo stabilisce prima l’ambito di scrittura, e un valore che vi rientra non equivale a un valore che torna carattere per carattere com’era.
L’ambito scritto è il limite di ciò che può tornare
Mettendo insieme livello di file e livello di scena, l’esportazione conserva il nome del progetto e l’insieme formato da numero di scena, INT/EST, nome della scena, momento del giorno, ottavi, colore di revisione, contrassegno di omissione, numero di pagina ed elementi della sceneggiatura. Inquadrature, record di ciak, videocamere, timecode (incluso il timecode audio Sound TC) e percorsi dei media non sono nella struttura di scrittura di questo FDX, e quindi queste registrazioni del set non si possono ripristinare da questo file.
Qui sta la divisione dei compiti tra «Cosa scambia FDX e cosa non riporta» e questa pagina. La pagina padre descrive l’ambito dello scambio; questa pagina resta più stretta e guarda lo stesso file di scambio della sceneggiatura quando esce e quando torna, cioè come cambiano i contenuti dentro l’ambito e quali contenuti non hanno affatto un supporto di ritorno.
Tre comportamenti dell’intestazione della scena e del riassunto da distinguere nel giro
Il primo è l’accumulo sull’intestazione della scena. In una scena importata da FDX il nome della scena conserva l’intero titolo originale, mentre INT/EST e momento del giorno ne trattengono ciascuno una copia separata; alla riesportazione l’intestazione viene ricomposta come «prefisso INT/EST + intero titolo originale + separatore + momento del giorno originale», e così titolo e momento del giorno si sovrappongono una volta. Le scene create a mano dentro l’app si comportano diversamente su questo punto, perché le loro tre parti erano già salvate separate, e lì la stessa sovrapposizione non ha origine.
Il secondo è il punto, che viene aggiunto in modo condizionato. All’importazione un prefisso come INT. viene conservato esattamente com’è, e all’esportazione se ne aggiunge uno solo quando il valore non ha già il punto in fondo, quindi un solo giro non produce il doppio punto di INT..; ciò che può ripetersi sono il titolo e l’informazione giorno/notte dentro l’intestazione della scena. Qui si descrive il risultato delle regole dei due lati messe insieme, non un’ipotesi sul comportamento di un software di sceneggiatura di terze parti.
Il terzo è la sostituzione del riassunto. All’importazione i contenuti di tipo note o riassunto possono finire nel riassunto della scena e, quando non c’è alcun riassunto di questo tipo da scrivere, anche il primo paragrafo di azione o un paragrafo normale possono essere presi come riassunto: nel riassunto può quindi esserci l’intero testo della descrizione dell’azione, non la sintesi della trama. L’esportazione, da parte sua, non rimanda il riassunto della scena nell’attributo corrispondente, così a una reimportazione successiva quella posizione può essere di nuovo occupata dal primo paragrafo di azione o da un paragrafo normale.
Altri tre cambiamenti di ritorno vanno considerati a parte
Quando gli ottavi di una scena sono 0, l’esportazione non scrive l’attributo di lunghezza; alla rilettura una lunghezza assente viene trattata come 1/8 di pagina, quindi «0 o vuoto» torna come 1/8 di pagina. Lo stato delle scene reimportate viene scritto come «non ripresa», e lo stato di ripresa precedente non si può ripristinare attraverso FDX. I paragrafi di note o riassunto non tornano come elementi della sceneggiatura nella loro posizione di prima, e anche l’ordine degli elementi della sceneggiatura viene riassegnato.
Questi cambiamenti non dicono che il file sia danneggiato, dicono che «cosa scrive questo formato» e «come vengono creati gli oggetti alla rilettura» non sono la stessa cosa. «Le diverse facce di un valore mancante nei file di consegna» aiuta a distinguere stringa vuota, attributo assente e segnaposto, ma qui si resta solo sul giro di andata e ritorno dell’FDX.
Confine rigido: il comportamento si può descrivere, ma quattro domande richiedono ancora la prova a livello di file
L’accumulo sull’intestazione della scena, la sostituzione del riassunto, l’omissione della lunghezza quando gli ottavi sono 0 e il suo ritorno a 1/8 di pagina alla rilettura, lo stato «non ripresa» scritto alla reimportazione e i paragrafi di note o riassunto che non tornano nella posizione originale come elementi della sceneggiatura — con l’ordine rinumerato — sono comportamenti che si osservano quando questa app esporta un file e lo rilegge. Sono solo quattro le domande che restano fuori da ciò che questa pagina può chiarire:
Quali campi aggiuntivi perde un determinato FDX reale. L’importazione legge solo i cinque attributi citati; per elencare che cos’altro perde un file concreto occorre confrontarlo campo per campo con quel file stesso.
Quali scene il filtro dei duplicati elimina davvero. Il filtro è in funzione, ma l’insieme esatto delle scene interessate dipende dal file di input e va confrontato con il risultato dell’importazione.
L’interoperabilità reale con un software di sceneggiatura di terze parti. Questa pagina non promette un giro senza perdite; il risultato di apertura, salvataggio con altro nome e reimportazione in un software di terze parti dipende dal file che si usa davvero.
L’entità reale di queste riscritture fisse in un dato giro. Tutte queste riscritture avvengono davvero; quanto cambino il titolo, il riassunto o la lunghezza di un file concreto richiede ancora un confronto tra il file esportato e il risultato riletto.
Il confine pubblico è quindi questo: il giro non garantisce una conservazione letterale carattere per carattere. Non si deve estendere un comportamento ormai stabilito fino ad affermare che ogni file cambi nella stessa misura, né presentare come confermato il risultato effettivo di un software di terze parti; chi riceve deve controllare il file di scambio reale e, dopo la rilettura, intestazione, lunghezza, riassunto e stato.
Il giro non garantisce una conservazione letterale carattere per carattere; tutte queste riscritture avvengono davvero, ma il cambiamento effettivo di ogni singolo file va comunque verificato.
FAQ
FDX può riportare con sé anche le inquadrature e i record di ciak?
Dalla struttura di scrittura attuale questi oggetti del set non si ricavano. Non rientrano nell’ambito di scambio di questo FDX, e la reimportazione non li ricostruisce dal nulla.
Perché l’intestazione della scena può guadagnare un prefisso e un momento del giorno in più?
Una scena importata conserva l’intero titolo originale insieme a INT/EST e momento del giorno salvati a parte, e alla riesportazione quelle tre parti vengono ricucite insieme. Una scena creata a mano su questo punto si comporta diversamente, perché le tre parti sono salvate separate fin dall’origine.
Perché il riassunto può diventare descrizione dell’azione?
Quando non c’è alcuna note o riassunto da scrivere, il primo paragrafo di azione o un paragrafo normale può essere preso come riassunto, mentre il riassunto non ha un percorso di riscrittura corrispondente. A una reimportazione successiva quella posizione può quindi essere occupata dall’intero testo della descrizione dell’azione.
Queste conclusioni significano che un software di sceneggiatura di terze parti ha superato il giro?
No. Questa pagina non garantisce per il risultato effettivo di apertura, salvataggio con altro nome e reimportazione in un software di sceneggiatura di terze parti, quindi chi riceve deve verificare in autonomia il file che ha in mano; il confine pubblico resta che il giro non garantisce la fedeltà carattere per carattere.
Axiom One LLC — SlateX