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, cada vez que un archivo se exporta y se vuelve a leer, algunos valores sufren igual reescrituras fijadas por un comportamiento establecido.
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, la exportación 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 timecode (incluido el timecode de sonido Sound TC) 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 comportamientos del título de escena y del resumen que hay que distinguir en el 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, se 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 el punto. Al importar, un prefijo como INT. se retiene tal cual, y al exportar se agrega un punto solo cuando el valor no lo trae al final, así que el ida y vuelta no produce un punto doble como INT..; lo que sí puede repetirse es el título y la información de hora del día dentro del título de escena. Lo que se describe acá 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. La exportación, 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, la exportación 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. “Cómo se ve un valor que falta en el archivo de entrega” 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: el comportamiento se puede describir, pero cuatro preguntas todavía exigen la prueba a nivel de archivo
La superposición del título de escena, la sustitución del resumen, la omisión de la longitud cuando los octavos de página son 0 y su conversión a 1/8 de página al releer, el estado “sin rodar” que se escribe al reimportar y los párrafos de notas o de tipo resumen que no vuelven a su posición original como elementos de guion —con la orden de estos renumerada— son comportamientos que se observan cuando esta app exporta un archivo y lo vuelve a leer. Solo cuatro preguntas quedan fuera de lo que esta página puede resolver:
Qué campos adicionales pierde un FDX real concreto. La importación solo lee los cinco atributos mencionados; para enumerar qué más pierde un archivo determinado hay que compararlo campo por campo con ese mismo archivo.
Qué escenas filtra en la práctica la regla de duplicados. El filtro está en funcionamiento, pero el conjunto exacto de escenas afectadas depende del archivo de entrada y debe contrastarse con el resultado de la importación.
La interoperación real con software de guion de terceros. Esta página no promete un ida y vuelta sin pérdidas; el resultado de abrir, guardar como y volver a importar en un software de terceros depende del archivo que de hecho se use.
La magnitud real de estas reescrituras fijas en una ida y vuelta concreta. Todas estas reescrituras sí ocurren; cuánto cambian el título, el resumen o la longitud de un archivo determinado sigue exigiendo comparar el archivo exportado con el resultado releído.
El límite público es, entonces: la ida y vuelta no garantiza una conservación literal carácter por carácter. No hay que ampliar un comportamiento ya establecido a la afirmación de que todos los archivos cambian en la misma medida, ni presentar como confirmado el resultado real de una aplicación de terceros; quien recibe debe revisar el archivo de intercambio real y el título de escena, la longitud, el resumen y el estado que resulten después de la relectura.
La ida y vuelta no garantiza una conservación literal carácter por carácter; todas estas reescrituras sí ocurren, pero el cambio real de cada archivo sigue pidiendo una revisión.
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. Esta página no avala el resultado real de abrir, guardar como y volver a importar en un software de guion de terceros, así que quien recibe debe revisar el archivo que tiene en la mano, y el límite público llega apenas hasta que el ida y vuelta no garantiza la fidelidad carácter por carácter.
Axiom One LLC — SlateX