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 per i valori che rientrano nell'ambito scritto, dopo il giro «esportazione e reimportazione» alcuni subiscono riscritture che si ricavano direttamente dalle regole dei due lati.
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, il lato scrittura 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 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 contenuti vengono riscritti in modo deterministico dal 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 il lato scrittura ricompone l'intestazione 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 è la ripetizione del punto. Il lato lettura conserva il punto insieme a un prefisso come INT., mentre il lato scrittura aggiunge di nuovo un punto dopo l'INT/EST, quindi un solo giro può produrre un punto doppio. 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. Il lato scrittura, 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, il lato scrittura 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 quattro forme di un valore vuoto 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: derivabile dal codice non vuol dire giro già accettato con un software di terze parti
L'accumulo sull'intestazione, il punto doppio e la sostituzione del riassunto seguono direttamente dal mettere insieme le regole attuali del lato scrittura e del lato lettura. Noi non abbiamo ancora percorso per intero il giro «apertura, salvataggio con altro nome e reimportazione» con un software di sceneggiatura di terze parti reale, quindi ciò che qui si può affermare è una sola frase: il giro non garantisce la fedeltà carattere per carattere.
Questo confine limita anche l'ambito delle estrapolazioni. Il comportamento deterministico del lato app non va scritto come «un certo software di sceneggiatura di terze parti farà sicuramente così», e un giro reale non percorso non va scritto come già accettato; chi riceve il file deve verificare in autonomia il file di scambio effettivo e, dopo la rilettura, le intestazioni di scena, le lunghezze, i riassunti e gli stati.
Il giro non garantisce la fedeltà carattere per carattere; il codice dimostra che il percorso di riscrittura esiste, ma apertura, salvataggio con altro nome e reimportazione con un software di sceneggiatura di terze parti reale vanno ancora verificati file per file.
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. Noi non abbiamo ancora completato la verifica del giro reale con un software di sceneggiatura di terze parti, quindi chi riceve il file deve verificare in autonomia il file effettivo; il confine pubblico resta che il giro non garantisce la fedeltà carattere per carattere.
Axiom One LLC — SlateX. I numeri di questo articolo sono aggiornati al 2026-09-24.