Ce que le FDX exporté ne fait pas revenir
Un FDX écrit depuis SlateX et ramené dans l’app ne réinstalle pas le projet original tel quel. Au niveau du fichier, le nom du projet est écrit ; au niveau des scènes, l’échange porte sur le numéro de scène, INT/EXT, le nom de la scène, le jour/nuit, les huitièmes, la couleur de révision, le marqueur d’omission, le numéro de page et les éléments de scénario. Les données de l’app qui ne sont pas dans ce périmètre d’écriture ne peuvent pas revenir par ce fichier. Et surtout, même à l’intérieur du périmètre écrit, certaines valeurs sont, chaque fois qu’un fichier est exporté puis relu, réécrites selon un comportement fixé.
Ce qu’un FDX peut faire revenir est d’abord borné par le périmètre d’écriture ; une valeur qui est dans ce périmètre ne revient pas forcément mot pour mot.
Le périmètre écrit fixe le plafond de ce qui peut revenir
En prenant ensemble le niveau fichier et le niveau scène, l’exportation conserve le nom du projet ainsi que le numéro de scène, INT/EXT, le nom de la scène, le jour/nuit, les huitièmes, la couleur de révision, le marqueur d’omission, le numéro de page et les éléments de scénario. Les plans, les fiches de prise, les caméras, le timecode (y compris le timecode son Sound TC), les chemins de médias, et d’autres enregistrements de plateau du même type, ne font pas partie de la structure d’écriture de ce FDX ; ces enregistrements ne peuvent donc pas être restaurés à partir de ce fichier.
C’est aussi la répartition entre « Ce que FDX sert à échanger, et ce qu’il perd » et cette page. La page parente expose le périmètre de l’échange ; ici on regarde seulement ce qui change, à l’intérieur de ce périmètre, quand un même fichier d’échange de scénario part puis revient, et ce qui n’a aucun support de retour.
Trois comportements du titre de scène et du résumé à distinguer lors d’un aller-retour
Le premier, c’est l’empilement du titre de scène. Pour une scène importée depuis un FDX, le nom de la scène conserve le titre original complet, tandis qu’INT/EXT et le jour/nuit en gardent chacun une copie ; à un nouvel export, le titre de scène est recomposé comme « préfixe INT/EXT + titre original complet + séparateur + jour/nuit d’origine », si bien que le titre et le jour/nuit se superposent une fois de plus. Une scène créée à la main dans l’app se comporte autrement sur ce point, parce que ces trois parties sont déjà stockées séparément et n’offrent pas la même source de superposition.
Le deuxième, c’est le point. À l’importation, un préfixe comme INT. est conservé tel quel, et à l’exportation un point n’est ajouté que si la chaîne ne s’achève pas déjà par un point ; un aller-retour ne fait donc jamais apparaître de double point comme INT... Ce qui se répète, ce sont le titre et l’information jour/nuit dans le titre de scène. Il s’agit ici du résultat des deux règles juxtaposées, pas d’une supposition sur le comportement d’un logiciel tiers.
Le troisième, c’est le remplacement du résumé. À l’importation, les contenus de type Notes ou résumé peuvent entrer dans le résumé de la scène, et quand il n’y a pas de résumé de ce type en attente d’écriture, le paragraphe d’action ou le paragraphe ordinaire du début peut aussi servir de résumé ; le résumé peut donc contenir le texte intégral du paragraphe d’action, et non un résumé de l’intrigue. L’exportation ne reporte pas le résumé de la scène sur un attribut correspondant, de sorte qu’à la réimportation cette place peut de nouveau être prise par le paragraphe d’action ou le paragraphe ordinaire du début.
Trois autres changements de retour à examiner séparément
Quand les huitièmes d’une scène valent 0, l’exportation n’écrit pas d’attribut de longueur ; à la relecture, une longueur absente est traitée comme 1/8 de page, donc « 0 ou absent » devient 1/8 de page. À la réimportation, l’état de la scène est écrit comme « non tournée », et l’état de tournage antérieur ne peut pas être restauré par le FDX. Les paragraphes de type Notes ou résumé ne reviennent pas comme éléments de scénario à leur place d’origine, et l’ordre des éléments de scénario est renuméroté.
Ces changements ne veulent pas dire que le fichier est dégradé ; ils disent que « ce que ce format écrit » et « comment les objets sont créés à la relecture » ne sont pas la même question. « Les différentes formes d’une valeur manquante dans un fichier de livraison » aide à distinguer chaîne vide, attribut absent et valeur de remplissage, mais on reste ici limité à l’aller-retour FDX lui-même.
Frontière dure : le comportement peut être décrit, mais quatre questions exigent encore une preuve au niveau du fichier
L’empilement du titre de scène, le remplacement du résumé, l’omission de la longueur lorsque les huitièmes valent 0 puis son rétablissement à 1/8 de page à la relecture, l’état « non tournée » réécrit à la réimportation, ainsi que les paragraphes de type Notes ou résumé qui ne reviennent pas à leur place d’origine comme éléments de scénario — avec une renumérotation de leur ordre — s’observent quand cette app exporte un fichier puis le relit. Quatre questions restent hors de ce que cette page peut trancher :
Quels champs supplémentaires un FDX réel donné perd. L’importation ne lit que les cinq attributs mentionnés plus haut ; pour dresser la liste de ce qu’un fichier précis perd en plus, il faut le comparer champ par champ avec ce même fichier.
Quelles scènes le filtre de doublons écarte réellement. Le filtre est en place, mais l’ensemble exact des scènes concernées dépend du fichier d’entrée et doit être confronté au résultat de l’importation.
L’interopérabilité réelle avec un logiciel de scénario tiers. Cette page ne promet aucun aller-retour sans perte ; le résultat de l’ouverture, de l’enregistrement sous et de la réimportation dans un logiciel tiers dépend du fichier que vous utilisez réellement.
L’ampleur réelle de ces réécritures fixes dans un aller-retour donné. Toutes ces réécritures ont bien lieu ; savoir de combien le titre, le résumé ou la longueur d’un fichier précis changent exige encore de comparer le fichier exporté avec le résultat relu.
La frontière publique est donc la suivante : un aller-retour ne garantit pas une fidélité littérale caractère par caractère. Il ne faut pas étendre un comportement établi en affirmant que chaque fichier change dans la même mesure, ni présenter comme confirmé le résultat réel d’un logiciel tiers ; le destinataire doit vérifier le fichier d’échange réel ainsi que le titre de scène, la longueur, le résumé et l’état obtenus après relecture.
Un aller-retour ne garantit pas une fidélité littérale caractère par caractère ; toutes ces réécritures ont bien lieu, mais le changement réel de chaque fichier reste à vérifier.
FAQ
Le FDX peut-il faire revenir les plans et les fiches de prise ?
Ces objets de plateau ne peuvent pas être obtenus à partir de la structure d’écriture actuelle. Ils sortent du périmètre d’échange de ce FDX, et une réimportation ne les recréera pas à partir de rien.
Pourquoi le titre de scène peut-il gagner un préfixe et un jour/nuit de plus ?
Une scène importée conserve à la fois le titre original complet, INT/EXT et le jour/nuit, puis un nouvel export assemble les trois. Une scène créée à la main se comporte différemment sur ce point, parce que les trois parties sont conservées séparément à l’origine.
Pourquoi le résumé peut-il devenir du texte d’action ?
Quand aucun contenu de type Notes ou résumé n’est en attente d’écriture, le paragraphe d’action ou le paragraphe ordinaire du début peut être pris comme résumé, et le résumé n’a pas de chemin d’écriture en retour. À la réimportation, cette place peut donc être reprise par le texte intégral du paragraphe d’action.
Ces conclusions signifient-elles qu’un logiciel de scénarisation tiers a réussi un aller-retour ?
Non. Cette page ne cautionne pas le résultat réel de l’ouverture, de l’enregistrement sous et de la réimportation dans un logiciel de scénarisation tiers, et le destinataire doit vérifier lui-même le fichier qu’il a entre les mains ; la frontière publique s’arrête à « un aller-retour ne garantit pas une fidélité mot pour mot ».
Axiom One LLC — SlateX