Qué no devuelve un FDX exportado
Un FDX escrito por SlateX que después regresa a la app no equivale a reinstalar tal cual el proyecto original. A nivel de archivo se escribe el nombre del proyecto, y a nivel de escena el intercambio gira alrededor del número de escena, INT/EXT, el nombre de la escena, la hora del día, los octavos de página, el color de revisión, la marca de omisión, el número de página y los elementos de guion; los datos de la app que no entran en ese alcance escrito no se pueden traer de vuelta con este archivo. Y lo más importante: aunque algo pertenezca al alcance escrito, algunos valores sufren, después de “exportar y volver a importar”, reescrituras que se derivan directamente del código de los dos lados.
Lo máximo que un FDX puede devolver lo fija primero el alcance de lo que se escribe; y un valor que sí esté dentro tampoco vuelve necesariamente carácter por carácter como estaba.
El alcance escrito fija el techo de lo que puede regresar
Sumando el nivel de archivo y el nivel de escena, el lado de la escritura conserva el nombre del proyecto junto con el número de escena, INT/EXT, el nombre de la escena, la hora del día, los octavos de página, el color de revisión, la marca de omisión, el número de página y los elementos de guion. Los planos, los registros de toma, los registros de cámara, el código de tiempo y las rutas de los medios no están en la estructura de escritura de este FDX, así que desde este archivo no se recuperan esos registros del set.
Ahí está el reparto entre “Qué intercambio conviene a FDX y qué información pierde” y esta página. La página principal explica el alcance del intercambio; esta se queda más angosta y mira únicamente qué le pasa al contenido que sí está dentro cuando el mismo archivo de intercambio de guion sale y vuelve a entrar, y qué contenido ni siquiera tiene un camino por donde regresar.
Tres contenidos se reescriben de forma determinista después del ida y vuelta
Uno es la capa extra en el título de escena. Una escena importada desde FDX conserva en el nombre de la escena el título original completo, y al mismo tiempo INT/EXT y la hora del día guardan cada uno su propia copia; al exportar otra vez, el lado de la escritura arma de nuevo el título de escena con “prefijo de INT/EXT + título original completo + separador + hora del día original”, de modo que el título y la hora del día se vuelven a superponer. Una escena creada a mano dentro de la app se comporta distinto en este punto, porque esas tres partes ya estaban guardadas por separado y ahí no existe el mismo origen de superposición.
Otro es la duplicación del punto. El lado de lectura retiene el punto junto con el prefijo en formas como INT., y el lado de la escritura agrega además un punto después de INT/EXT, así que un solo ida y vuelta puede producir un punto doble. Lo que se describe aquí es el resultado de combinar las reglas de los dos lados, no una inferencia sobre cómo se comporta un software de guion de terceros.
Y queda la sustitución del resumen. Al importar, el contenido de notas o de tipo resumen puede pasar al resumen de la escena, y cuando no hay ese resumen pendiente, el primer párrafo de acción o un párrafo común también puede terminar usado como resumen; por eso lo que carga el resumen puede ser el texto de acción completo, no una sinopsis de la trama. El lado de la escritura, además, no devuelve el resumen de la escena a un atributo que le corresponda, así que al volver a importar es posible que ese puesto lo vuelva a ocupar el primer párrafo de acción o un párrafo común.
Otros tres cambios del regreso conviene verlos por separado
Cuando los octavos de página de una escena son 0, el lado de la escritura no escribe el atributo de longitud; al releer, una longitud que falta se procesa como 1/8 de página, de modo que “0 o vacío” termina convertido en 1/8 de página. El estado de las escenas reimportadas se escribe como “sin rodar”, así que el estado de rodaje que había antes no lo recupera un FDX. Los párrafos de notas o de tipo resumen no regresan como elementos de guion en su puesto original, y el orden de los elementos de guion se numera otra vez.
Estos cambios no quieren decir que el archivo esté dañado; quieren decir que “qué escribe este formato” y “cómo se crean los objetos al leerlo” no son la misma pregunta. “Las cuatro formas de un valor ausente” ayuda a distinguir entre cadena vacía, atributo que falta y valor de reserva, pero acá seguimos tratando solo el ida y vuelta del propio FDX.
Límite duro: derivable del código no significa recorrido con terceros
La superposición del título de escena, el punto doble y la sustitución del resumen salen de combinar de frente las reglas del lado de la escritura con las del lado de la lectura. Todavía no hemos recorrido completo el ciclo de “abrir, guardar como y volver a importar” con un software de guion de terceros real, así que acá lo único que podemos dejar firme es una frase: el ida y vuelta no garantiza la fidelidad carácter por carácter.
Ese límite acota también hasta dónde se puede extrapolar. El comportamiento determinista del código no debe escribirse como “tal software de terceros reaccionará así”, y un ida y vuelta real todavía no recorrido no debe escribirse como ya validado; quien recibe debe revisar por su cuenta el archivo de intercambio efectivo y el título de escena, la longitud, el resumen y el estado que resulten después de la relectura.
El ida y vuelta no garantiza la fidelidad carácter por carácter; el código muestra que el camino de reescritura existe, pero el abrir, guardar como y volver a importar con un software de terceros real sigue pidiendo una revisión archivo por archivo.
FAQ
¿Un FDX devuelve también los planos y los registros de toma?
Esos objetos del set no se obtienen de la estructura de escritura actual. No están en el alcance de intercambio de este FDX y volver a importarlo tampoco los reconstruye de la nada.
¿Por qué el título de escena puede ganar una capa extra de prefijo y de hora del día?
Una escena importada conserva a la vez el título original completo, INT/EXT y la hora del día, y al exportar otra vez se vuelven a unir las tres partes. Una escena creada a mano se comporta distinto aquí, porque las tres partes se guardaban por separado desde el principio.
¿Por qué el resumen puede quedar convertido en texto de acción?
Cuando no hay notas ni un resumen pendiente que escribir, el primer párrafo de acción o un párrafo común puede tomar el puesto del resumen, y el resumen no tiene un camino para escribirse de vuelta. Al volver a importar, ese puesto puede quedar otra vez ocupado por el texto de acción completo.
¿Estas conclusiones significan que un software de guion de terceros ya pasó el ida y vuelta?
No lo significan. Todavía no completamos la validación del ida y vuelta completo con un software de terceros real, así que quien recibe debe revisar el archivo efectivo, y el límite público sigue siendo que el ida y vuelta no garantiza la fidelidad carácter por carácter.
Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.