De dónde salen los colores de revisión y en qué orden los lee la importación
Los colores de revisión nacieron como una convención de corrección de la época del papel: cada ronda de revisión se distinguía con un color de papel distinto; no son un campo privativo inventado por un software. Al importar un archivo de intercambio de guion, SlateX lee el color en tres niveles: primero el color de formato del propio párrafo, después el color explícito de las propiedades de la escena, y solo cuando los dos primeros brillan por su ausencia intenta tomar un nombre de color del paréntesis final del título de escena. Y aunque lea un nombre, la pantalla lo somete aún a una comparación nombre por nombre: si no encaja con ninguno, se trata como sin color.
Los colores de revisión vienen de una convención del sector sobre el flujo de corrección; el lado de la importación solo lee, en un orden fijo, la información de color que ya está escrita en el archivo.
Primero el color del párrafo, después el de la escena
La primera fuente es el color de formato que lleva el propio párrafo del título de escena. Luego se mira el color escrito de forma explícita en las propiedades de la escena dentro del archivo; como esta capa llega más tarde en el orden de lectura y es más concreta, sustituye al color de párrafo ya encontrado. Es decir, si las dos posiciones traen valor, el que ocupa el resultado final es el de las propiedades de la escena.
Solo cuando ninguna de las dos posiciones aporta color entra el tercer nivel: comprobar si el título de escena termina con un nombre de color en mayúsculas encerrado entre paréntesis, y normalizar después el nombre leído para poder compararlo. Este último recurso deja fuera de forma expresa la palabra que marca una escena omitida: no la cuenta como color de revisión.
La pantalla vuelve a comparar el nombre de color
Con el nombre de color en la mano, la pantalla no pinta de un color cualquier cadena que lea, sino que compara primero el nombre leído con los cuatro nombres base (blue, pink, yellow, green) y después con varios nombres extendidos y variantes de segundo nivel; si ninguna comparación acierta, el resultado es sin color.
Por eso, «el archivo contiene una cadena de color» y «la interfaz muestra el color correspondiente» no son el mismo hecho. La cadena produce un color visible solo si la propiedad es legible y si el nombre cae dentro del conjunto comparable de la pantalla. Aquí no se deduce ninguna ronda de revisión a partir de un nombre de color, ni se explica en nombre del archivo qué significa su origen.
La omisión es vecina de la lectura de color, pero es otra regla
«Esta escena está omitida» admite dos fuentes. Uno es la propiedad de omisión escrita en el archivo; el otro comprueba directamente si el texto del título de escena contiene una secuencia fija de letras mayúsculas, y esa coincidencia de texto distingue mayúsculas de minúsculas. Bastará con que el texto del título contenga por casualidad esa secuencia en mayúsculas para que la escena se juzgue omitida: la fila sigue apareciendo en la barra lateral, pero el nombre de la escena sale tachado y atenuado, y dejan de mostrarse la insignia de completado, el INT/EXT, el día/noche y las páginas.
Eso significa que el estado de omisión no puede deducirse solo por «si hay o no color de revisión». La lectura del color y el estado de omisión tienen fuentes distintas, y al tomar el color del paréntesis final del título se excluye expresamente la palabra de omisión. El receptor debe verificar por separado en el archivo la propiedad de color, la de omisión y el texto del título de escena, sin tomar una posición como señal sustituta de las otras dos.
Frontera dura: las muestras actuales no cubren este recorrido
Nuestros dos archivos de muestra actuales no llevan color, número ni propiedad de omisión, así que esas muestras no cubren en nada el recorrido del color de revisión. El código permite explicar el orden de lectura y las reglas de comparación, pero las muestras no demuestran que, al importar un archivo de intercambio real, vaya a aparecer tal o cual resultado concreto de color de revisión.
Por eso, la conclusión pública solo llega hasta «entra en vigor cuando la propiedad puede leerse». «De qué partes se compone una línea de título de escena» responde de la estructura del título en sí; y si el resultado importado se entrega después a un receptor, sigue valiendo el principio de «Al recibir un ALE, comprueba primero estos campos»: el receptor debe verificar los campos y valores que aparezcan de hecho en el archivo.
Las muestras actuales no contienen color, número ni propiedad de omisión; este recorrido solo puede describirse desde sus reglas de lectura, y un hueco de muestras no puede escribirse como un resultado de color ya verificado.
FAQ
¿Los colores de revisión los inventó algún software de guion?
No. Lo que se adopta aquí es una convención heredada del flujo de corrección en papel; la App solo lee la información relacionada cuando aparece en el archivo de intercambio.
Si el archivo trae a la vez color de párrafo y de escena, ¿cuál se usa?
El color explícito de las propiedades de la escena sustituye al color de formato del párrafo leído antes, porque en el orden de lectura es la fuente más concreta y posterior.
¿Cuándo se lee un color entre paréntesis al final del título?
Solo si los dos primeros niveles no aportan color se intenta el nombre de color del paréntesis final del título de escena, con la palabra que marca omisión expresamente excluida.
¿Por qué no puede afirmarse que tras importar aparecerán colores de revisión?
Porque las dos muestras actuales no llevan color, número ni propiedad de omisión. Lo estable es la regla de lectura del código; si un archivo concreto trae esas propiedades, hay que comprobarlo contra el archivo de intercambio real.
Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.