Da dove vengono i colori di revisione e in che ordine li legge l'importazione

I colori di revisione sono prima di tutto una convenzione lasciata dall'epoca della carta: le diverse passate di revisione si distinguevano con colori di carta diversi, non erano un campo esclusivo inventato da un software. Quando SlateX importa un file di scambio della sceneggiatura, legge il colore in tre passaggi: prima il colore di formattazione del paragrafo stesso, poi il colore scritto in modo esplicito nelle proprietà della scena; solo se mancano entrambe le posizioni prova a prendere il nome del colore dalla parentesi in coda al titolo di scena. Anche quando un nome viene letto, deve passare dal confronto nome per nome lato visualizzazione, e se non corrisponde a niente viene trattato come assenza di colore.

I colori di revisione vengono da una convenzione di settore del flusso di revisione; il lato importazione legge solo le informazioni di colore già presenti nel file, nell'ordine stabilito.

Prima il colore del paragrafo, poi quello della scena

La prima fonte è il colore di formattazione portato dal paragrafo del titolo di scena. Poi si guarda il colore scritto esplicitamente nelle proprietà della scena nel file; poiché questo livello, nell'ordine di lettura, arriva dopo ed è più specifico, sostituisce il colore del paragrafo già letto. Quando entrambe le posizioni hanno un valore, quello che resta nel risultato finale è il valore delle proprietà della scena.

Solo se nessuna delle due posizioni fornisce colore entra il terzo livello: si controlla se il testo del titolo di scena termina con un nome di colore tutto in maiuscolo racchiuso tra parentesi, e il nome letto viene normalizzato in una forma comoda per i confronti successivi. Questo ripiegamento esclude in modo esplicito la parola che segna l'omissione, quindi non la tratta come colore di revisione.

Il lato visualizzazione confronta di nuovo il nome del colore

Dopo aver ottenuto il nome del colore, il lato visualizzazione non trasforma una stringa qualsiasi in un colore: confronta prima il nome letto con i quattro nomi di colore base (blue, pink, yellow, green) e poi con alcuni nomi estesi e varianti di secondo livello; se nessun nome corrisponde, il risultato resta senza colore.

Quindi «nel file c'è una stringa di colore» e «sull'interfaccia compare il colore corrispondente» non sono fatti dello stesso livello. La catena produce un colore visibile solo quando l'attributo è leggibile e quando il nome rientra nell'insieme confrontabile dal lato visualizzazione. Qui non si risale dal nome di un colore alla passata di revisione e non si interpreta il significato operativo per conto di chi ha prodotto il file.

Il giudizio di omissione è vicino alla lettura del colore, ma è un'altra regola

Due sono le fonti dello stato «omessa» di una scena. Una è la proprietà di omissione presente nel file; l'altra controlla direttamente se il testo del titolo di scena contiene una sequenza fissa di lettere maiuscole, e questo confronto di testo distingue maiuscole da minuscole. Se quella sequenza maiuscola compare nel testo del titolo, la scena viene giudicata omessa: la riga continua a comparire nella barra laterale, ma il nome della scena appare barrato e in grigio, e il contrassegno di completamento, INT/EST, giorno/notte e il numero di pagine non vengono più mostrati.

Questo significa che l'omissione non si può dedurre solo guardando se c'è un colore di revisione. La lettura del colore e lo stato di omissione hanno fonti distinte, e il prelievo del colore in coda al titolo esclude esplicitamente la parola di omissione. Chi riceve il file deve verificare in autonomia la proprietà di colore, la proprietà di omissione e il testo del titolo di scena, senza trattare una di queste posizioni come segnale sostitutivo delle altre due.

Confine rigido: gli esempi attuali non coprono questa catena

I due file di esempio di cui disponiamo non contengono alcuna proprietà di colore, di numero o di omissione, quindi per la catena dei colori di revisione non offrono copertura. Il codice può descrivere l'ordine di lettura e le regole di confronto, ma gli esempi non dimostrano che dall'importazione di un file di scambio reale derivi un risultato preciso di colore di revisione.

Per questo la conclusione pubblica si ferma a «entra in azione quando l'attributo è leggibile». «Di cosa è composto un titolo di scena» copre la struttura del titolo in sé; se in seguito il risultato dell'importazione passa a chi riceve la consegna, vale ancora il principio di «Cosa controllare in un ALE prima di usarlo per il confronto»: chi riceve il file deve verificare in autonomia campi e valori effettivamente presenti nel file.

Gli esempi attuali non hanno proprietà di colore, di numero o di omissione; questa catena si può descrivere solo dalle sue regole di lettura, e il vuoto negli esempi non va scritto come un risultato di colore già verificato.

FAQ

I colori di revisione li ha inventati un software di sceneggiatura?

No. Qui vale una convenzione di settore che prosegue dal flusso di revisione su carta; questa app legge solo le informazioni correlate che compaiono nel file di scambio.

Se il file ha sia il colore del paragrafo sia quello della scena, quale viene usato?

Il colore esplicito delle proprietà della scena sostituisce il colore di formattazione del paragrafo letto prima, perché nell'ordine di lettura è più specifico e arriva dopo.

Quando viene letto il colore tra parentesi in coda al titolo?

Solo quando i primi due livelli non forniscono colore si prova a prendere il nome nella parentesi in coda al titolo di scena, escludendo la parola che segna l'omissione.

Perché non si può dire che dopo l'importazione compariranno i colori di revisione?

Perché i due esempi attuali non hanno proprietà di colore, di numero o di omissione. Ciò che è certo sono le regole di lettura del codice; se un file concreto porti con sé queste proprietà va verificato sul file di scambio reale.

Axiom One LLC — SlateX. I numeri di questo articolo sono aggiornati al 2026-09-24.