Colores de revisión: de dónde vienen y en qué orden los lee la importación
Los colores de revisión vienen, antes que nada, de una convención de corrección de la época del papel: cada ronda de revisión se distinguía con un color de hoja distinto, no son un campo privativo que haya inventado un software. Al importar un archivo de intercambio de guion, SlateX toma 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; solo cuando fallan las dos posiciones anteriores intenta sacar un nombre de color del paréntesis del final del título de escena. Y aunque lea el nombre, todavía falta el cotejo nombre por nombre del lado de la pantalla: 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 ya definido, la información de color que el archivo trae escrita.
Mirar primero el color del párrafo y después el de la escena
El punto de partida es el color de formato que carga el propio párrafo del título de escena. Después 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, deja sin efecto el color de párrafo ya encontrado. Es decir, cuando las dos posiciones traen valor, el resultado queda con el de las propiedades de la escena.
Solo si ninguna de las dos posiciones aporta color entra el tercer nivel: se revisa si el texto del título de escena remata en un nombre de color en mayúsculas encerrado entre paréntesis, y el nombre leído se normaliza a una forma cómoda para comparar después. Este último recurso deja fuera de forma expresa la palabra que marca una escena omitida: no la cuenta como color de revisión.
Del lado de la pantalla el nombre del color se vuelve a comparar
Con el nombre en la mano, la pantalla no pinta de un color cualquier string: lo compara primero contra los cuatro nombres base (blue, pink, yellow, green) y después contra varios nombres extendidos y variantes de segundo nivel; si no encaja con ninguno, se trata como sin color.
Por eso “el archivo trae un string de color” y “la interfaz muestra el color correspondiente” no son hechos del mismo nivel. Esta cadena llega a producir color visible solo si el atributo se lee y si el nombre cae dentro de lo que la pantalla puede comparar. De aquí no se saca qué ronda de revisión toca un nombre de color, ni se explica, en lugar del origen del archivo, qué significado operativo tiene.
Decidir si una escena va omitida y leer el color son reglas vecinas, no la misma
Que “esta escena va omitida” admite dos fuentes. Una es la propiedad de omisión escrita en el archivo; la otra revisa de frente si el texto del título de escena contiene una secuencia fija de letras en mayúsculas, y ese cotejo de texto distingue mayúsculas de minúsculas. Basta con que el texto del título traiga 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 completada, INT/EXT, día/noche y el número de 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 deja fuera de forma expresa la palabra de omisión. Quien recibe debe revisar 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.
Límite duro: las muestras de hoy no cubren esta cadena
Los dos archivos de muestra que tenemos ahora no traen ningún atributo de color, de número ni de omisión, así que esas muestras no cubren la cadena de los colores de revisión. El código alcanza a explicar el orden de lectura y las reglas de cotejo, pero las muestras no demuestran que, al importar un archivo de intercambio real, vaya a salir tal resultado concreto de color de revisión.
Por eso la conclusión pública solo llega hasta “se aplica cuando la propiedad se puede leer”. “Qué partes forman 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 quien lo recibe, sigue valiendo el principio de “Cuando reciba el ALE, revise primero estos campos”: revisar por cuenta propia los campos y los valores que aparezcan de hecho en el archivo.
Las muestras de hoy no traen atributos de color, de número ni de omisión; esta cadena solo se puede describir desde sus reglas de lectura, y el vacío de las muestras no se puede escribir como un resultado de color ya verificado.
FAQ
¿Los colores de revisión los inventó algún software de guion?
No. Lo que se aplica aquí es una convención del sector que viene del flujo de corrección en papel; esta app solo lee la información relacionada que aparezca 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 deja sin efecto el color de formato del párrafo leído antes, porque en el orden de lectura es más concreto y llega más tarde.
¿Cuándo se lee el color entre paréntesis al final del título?
Solo cuando los dos niveles anteriores no aportan color se busca el nombre de color en el paréntesis del final del título de escena, y se deja fuera la palabra que marca una escena omitida.
¿Por qué no se puede decir directamente que la importación va a mostrar colores de revisión?
Porque las dos muestras de ahora no traen atributos de color, de número ni de omisión. Lo que está firme son las reglas de lectura del código; si un archivo concreto trae esos atributos, hay que comprobarlo contra el archivo de intercambio real.
Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.