D'où viennent les couleurs de révision et dans quel ordre l'importation les lit
Les couleurs de révision sont d'abord une convention laissée par les révisions sur papier : chaque passe de révision se distinguait par la couleur des feuillets, ce n'est pas un champ propriétaire inventé par un logiciel. Quand SlateX importe un fichier d'échange de scénario, il lit la couleur selon trois niveaux : d'abord la couleur de mise en forme du paragraphe lui-même, puis la couleur explicite portée par les propriétés de la scène ; ce n'est que si ces deux emplacements sont vides qu'il tente de prendre un nom de couleur entre parenthèses à la fin du titre de scène. Même quand un nom est lu, il doit encore passer la comparaison nom par nom du côté affichage, et sans correspondance le résultat est traité comme sans couleur.
Les couleurs de révision viennent d'une convention professionnelle héritée des passes de révision ; le côté importation se contente de lire, dans un ordre défini, les informations de couleur déjà présentes dans le fichier.
La couleur du paragraphe d'abord, puis celle de la scène
La première source est la couleur de mise en forme portée par le paragraphe du titre de scène lui-même. Vient ensuite la couleur écrite explicitement dans les propriétés de la scène dans le fichier ; cette couche, plus tardive dans l'ordre de lecture et plus spécifique, remplace la couleur de paragraphe déjà lue. Autrement dit, quand les deux emplacements portent une valeur, c'est celle des propriétés de scène qui donne le résultat.
Ce n'est que lorsque ces deux emplacements n'apportent pas de couleur qu'intervient le troisième niveau : vérifier si le texte du titre de scène se termine par un nom de couleur en majuscules entre parenthèses, puis ramener le nom lu à une forme commode pour la comparaison ultérieure. Ce repli exclut explicitement le mot qui marque une suppression et ne le traite pas comme une couleur de révision.
Le côté affichage compare une seconde fois le nom de couleur
Une fois le nom de couleur obtenu, le côté affichage ne transforme pas n'importe quelle chaîne en une couleur : il compare d'abord le nom lu avec les quatre noms de couleur de base (blue, pink, yellow, green), puis avec plusieurs noms étendus et variantes de second niveau ; sans correspondance, le résultat est traité comme sans couleur.
Ainsi, « une chaîne de couleur est écrite dans le fichier » et « la couleur correspondante apparaît à l'écran » ne sont pas des faits du même niveau. La chaîne ne produit un affichage coloré que si l'attribut est lisible et si le nom tombe dans le périmètre comparable du côté affichage. Ici, on ne remonte pas d'un nom de couleur jusqu'à une passe de révision, et on n'explique pas non plus la signification métier pour le compte de l'origine du fichier.
Omission et lecture des couleurs : deux règles voisines, distinctes
« Cette scène est supprimée » a deux sources. L'une vient de l'attribut d'omission présent dans le fichier ; l'autre cherche directement, dans le texte du titre de scène, une suite fixe de lettres majuscules, et cette correspondance de texte est sensible à la casse. Il suffit que le texte du titre contienne justement cette suite de majuscules pour que la scène soit jugée supprimée : la ligne apparaît encore dans la barre latérale, mais le nom de la scène est barré et grisé, et la pastille de complétion, INT/EXT, jour/nuit ainsi que le nombre de pages ne s'affichent plus.
Le jugement d'omission ne se déduit donc pas seulement de « la présence ou non d'une couleur de révision ». La lecture des couleurs et l'état d'omission ont des sources distinctes, et la recherche de couleur en fin de titre exclut explicitement le mot de suppression. Le destinataire doit vérifier lui-même, dans le fichier, l'attribut de couleur, l'attribut d'omission et le texte du titre de scène, sans prendre l'un de ces emplacements comme signal de repli pour les deux autres.
Frontière dure : les échantillons actuels ne couvrent pas cette chaîne
Nos deux fichiers d'échantillons actuels ne comportent aucun attribut de couleur, de numéro ni d'omission ; ces échantillons ne couvrent donc pas la chaîne des couleurs de révision. Le code peut établir l'ordre de lecture et les règles de correspondance, mais les échantillons ne prouvent pas qu'un fichier d'échange réel produira telle ou telle couleur de révision après importation.
La conclusion publique s'arrête donc à « cela prend effet quand l'attribut est lisible ». « De quoi se compose une ligne de titre de scène » traite de la structure du titre elle-même ; si le résultat de l'importation est ensuite remis à un destinataire, le principe de « Avant d'utiliser un ALE, vérifier ces champs » reste valable : le destinataire doit vérifier lui-même les champs et les valeurs réellement présents dans le fichier.
Les échantillons actuels ne portent aucun attribut de couleur, de numéro ni d'omission ; cette chaîne ne peut être décrite que par ses règles de lecture, et le vide des échantillons ne doit pas être écrit comme un résultat de couleur déjà vérifié.
FAQ
Les couleurs de révision ont-elles été inventées par un logiciel de scénarisation ?
Non. Elles relèvent d'une convention professionnelle héritée des passes de révision sur papier ; cette App lit seulement les informations qui apparaissent dans le fichier d'échange.
Quand le fichier porte à la fois une couleur de paragraphe et une couleur de scène, laquelle est retenue ?
La couleur explicite des propriétés de scène remplace la couleur de mise en forme du paragraphe lue d'abord, parce qu'elle est plus spécifique et plus tardive dans l'ordre de lecture.
Quand la couleur entre parenthèses en fin de titre est-elle lue ?
Uniquement quand les deux premiers niveaux ne donnent pas de couleur : la lecture tente alors le nom entre parenthèses en fin de titre, en excluant le mot qui marque une suppression.
Pourquoi ne pas dire simplement qu'une couleur de révision apparaîtra après importation ?
Parce que les deux échantillons actuels ne portent aucun attribut de couleur, de numéro ni d'omission. Ce qui est établi, ce sont les règles de lecture du code ; savoir si un fichier donné porte ces attributs se vérifie sur le fichier d'échange réel.
Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.