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: el resultado es el archivo que se recibe
Que un archivo traiga atributos de color, de número o de omisión depende de ese archivo. Esta página expone el orden de lectura y el límite del lado de la pantalla; no promete que al importar un archivo concreto vaya a salir un color concreto. Por eso la conclusión pública solo llega hasta “se aplica cuando el archivo trae un atributo de color reconocible”.
El resultado concreto de color de revisión que sale después de importar un archivo de intercambio real debe leerse en las marcas de revisión visibles en el archivo recibido. “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 recibas el ALE, revisa primero estos campos”: revisar por cuenta propia los campos y los valores que aparezcan de hecho en el archivo.
Esta cadena solo se puede describir desde sus reglas de lectura; un resultado concreto de color después de una importación real debe leerse en las marcas de revisión visibles en el archivo recibido.
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 si el archivo que tienes entre manos trae atributos de color, de número o de omisión, eso solo se puede comprobar en ese propio archivo. Esta página enuncia las reglas de lectura, y el resultado concreto son las marcas de revisión visibles en el archivo recibido.
Axiom One LLC — SlateX