改稿顏色從哪裡來，匯入時按什麼順序讀取

改稿顏色先是紙面年代留下的修訂約定：不同修訂輪次用不同紙色區分，不是某個軟體發明出來的專屬欄位。SlateX 匯入劇本交換檔案時，會按三級順序取顏色：先看段落本身的排版顏色，再看場景屬性裡的顯式顏色；前兩處都沒有時，才從場頭末尾括號裡嘗試取顏色名。讀到了名字，也還要經過顯示側的逐名比對，匹配不到就按無色處理。

改稿顏色來自修訂流程的行業約定；匯入側只是按既定順序讀取檔案裡已經存在的顏色資訊。

先看段落顏色，再看場景顏色

起始來源是場頭段落自身帶的排版顏色。隨後再看檔案裡場景屬性顯式寫出的顏色；因為這一層在讀取順序裡更靠後、也更具體，它會覆蓋前面已經讀到的段落顏色。也就是說，兩處都有值時，場景屬性的值佔用最後結果。

這兩個位置都沒有顏色時，才進入第三層：檢查場頭文字末尾是否有括號包住的全大寫顏色名，再把讀到的名字歸一為便於後續比較的形態。這個兜底同時顯式排除表示刪減的那個詞，不把它當成修訂顏色。

顯示側還會再比對一次顏色名

拿到顏色名稱之後，顯示側不會把任意字串都畫成某種顏色，而是把讀到的名字先與四種基礎色名（blue、pink、yellow、green）比對，再與若干擴展色名和二級變體比對；比對不到時就按無色處理。

因此，「檔案裡寫了顏色字串」和「介面上出現對應顏色」不是同一層事實。只有讀得到屬性，並且名稱落在顯示側可比對範圍內時，這條鏈路才會產生顏色顯示。這裡不從某個顏色名反推修訂輪次，也不替檔案來源解釋它的業務含義。

省略判定與顏色讀取是相鄰但不同的規則

「本場已刪減」有兩條來源。一條來自檔案裡的省略屬性；另一條直接檢查場頭正文裡是否包含固定的大寫字母組合，而且這個文字匹配區分大小寫。只要標題正文恰好包含那組大寫字母，就會被判成已刪減：側邊欄裡這一行仍然出現，但場景名加上刪除線並置灰，完成徽章、內外景、日／夜、頁數這幾項都不再顯示。

這意味著省略判斷不能僅按「有沒有修訂顏色」來推斷。顏色讀取和省略狀態有各自的來源，標題尾部取顏色時還會明確排除刪減詞。接收方應自行核對檔案裡的顏色屬性、省略屬性和場頭正文，不要把其中一個位置當成另外兩個位置的替代訊號。

硬邊界：現有樣本沒有覆蓋這條鏈路

我方現有兩份樣本檔案裡沒有任何顏色、編號、省略屬性，因此這些樣本對修訂顏色鏈路沒有覆蓋。程式碼可以說明讀取順序和匹配規則，但樣本不能證明一次真實交換檔案匯入後會出現某個具體修訂色結果。

所以公開結論只能到「讀得到屬性時才生效」。《一行場景標題由哪幾段組成》負責場頭結構本身；如果後續把匯入結果交給接收方，《拿到 ALE，先核對這些欄位》的原則仍然適用：接收方應自行核對實際檔案裡出現的欄位和值。

現有樣本沒有顏色、編號或省略屬性；這條鏈路只能按讀取規則描述，不能把樣本空白寫成已驗證的顏色結果。

FAQ

改稿顏色是某個劇作軟體發明的嗎？

不是。這裡採用的是從紙面修訂流程延續下來的行業約定；本 App 只讀取交換檔案裡出現的相關資訊。

檔案裡同時有段落顏色和場景顏色時用哪個？

場景屬性裡的顯式顏色會覆蓋先讀到的段落排版顏色，因為它在讀取順序裡更具體、更靠後。

標題末尾的括號顏色什麼時候會被讀取？

只有前兩層都沒有顏色時，才會去場頭末尾括號裡取顏色名，並排除表示刪減的那個詞。

為什麼不能直接說匯入後會出現改稿色？

因為現有兩份樣本沒有顏色、編號或省略屬性。能確定的是程式碼讀取規則；具體檔案是否帶這些屬性，需要對實際交換檔案核對。

Axiom One LLC — SlateX。以上數字截至 2026-09-24。