Where Revision Colors Come From—and How Import Reads Them

Revision colors began as a paper-era revision convention: different revision passes used different paper colors, rather than a field invented by one software product. When SlateX imports a script exchange file, it reads color in three stages: paragraph formatting first, then an explicit scene color, and only when both are absent does it try to take a color name from parentheses at the end of the slugline. Even after a name is read, the display layer compares it against known names and treats an unmatched value as no color.

Revision colors come from an industry revision convention; the import side only reads color information that is already present in the file, in a defined order.

Paragraph color comes first, then scene color

The first source is the formatting color attached to the scene-heading paragraph itself. The second source is an explicit color written in the scene properties; because this source is more specific and appears later in the read order, it replaces a paragraph color that was already found. When both positions contain a value, the scene-property value becomes the result.

Only when neither of those positions provides color does the third stage run: the importer checks whether the slugline ends with an all-uppercase color name inside parentheses, then normalizes the name for later comparison. That fallback explicitly excludes the word used to mark an omitted scene, so it is not treated as a revision color.

The display layer compares the color name again

After a color name has been read, the display layer does not turn any arbitrary string into a color. It compares the name against four base color names (blue, pink, yellow, green) and then against several extended names and second-level variants; if no name matches, the display result is clear.

That means “the file contains a color string” and “the interface shows a corresponding color” are separate facts. The chain produces a visible color only when the attribute is present and the name falls within the display comparison set. This rule does not infer a revision pass from the color name or assign business meaning on behalf of the source file.

Omission is adjacent to color parsing but uses a different rule

A scene can be treated as omitted from two sources. One is the file’s explicit omission property; the other is a case-sensitive substring check against the slugline text for a fixed uppercase letter sequence. If that sequence happens to occur in the slugline text, the scene is treated as omitted: the row still appears in the sidebar, but the set name is struck through and dimmed, and the completion badge, Int./Ext., day/night and page-count chips are all dropped.

Omission therefore cannot be inferred merely from the presence or absence of revision color. Color reading and omission state have separate sources, and the parenthetical color fallback explicitly excludes the omission word. A receiver should verify the file’s color property, omission property, and slugline text separately instead of using one as a substitute signal for the others.

Hard boundary: the receiving file is the result

Whether a given file carries color, number, or omission properties depends on that file. This page states the read order and the display boundary; it does not promise that a particular import will produce a particular color. The public conclusion therefore stops at “it takes effect when the file carries a recognizable color attribute.”

A specific revision-color outcome after importing a real exchange file should be read from the revision marks visible in the receiving file. What a Slugline Is Made Of covers the structure of the slugline itself; when an imported result is handed onward, the principle in What to Check Before Using an ALE for Matching still applies: the receiver should verify the fields and values actually present in the file.

This path can be described from its read rules; a specific color outcome after a real import should be read from the revision marks visible in the receiving file.

FAQ

Were revision colors invented by a particular script application?

No. The convention comes from paper-era revision practice; this app reads related information when it is present in the exchange file.

If both paragraph color and scene color exist, which one is used?

The explicit scene-property color replaces the paragraph formatting color because it is the more specific, later source in the read order.

When is a parenthetical color at the end of a slugline read?

Only when the first two sources provide no color does the importer try the trailing parenthetical name, while excluding the word used for omission.

Why not say that imported scripts will show revision colors?

Whether your own file carries colour, number or omission properties can only be checked in that file. This page states the read rules; the specific result is the revision marks visible in the receiving file.

Axiom One LLC — SlateX