ListAssFonts: 小工具，分析字幕使用的字型 (2023/06/13 更新)

wyj-aln 发表于 2020-5-16 18:55
感谢楼主的即时回答：
1、我的不加\fe的符号不能正常显示应该和系统环境不同导致编码预设字型不同有关， ...

2、关于经典中圆简和迷你简细行楷这两款字体不同版本的LAF运行情况：
①v200321：识别为已安装，黑色，无问题；
②v200427：识别为已安装，黑色，但是NeedVerify里会认为所有该字型的字都为缺字；
③v200509：识别为未安装，红色，NeedVerify里不会认为正常显示的字为缺字。
应该和.NET Framework版本有关？

我安裝這兩個字型後，從「設定->個人化->字型」去找這兩個字型，發現它們並排在第一位，中繼資料也不太正常


不管那個版本的 .NET Framework 都抓不到這兩個字型檔案的內容
大概是字型檔案本身有些缺陷，.NET Framework 乾脆就不處理了


在 v200509 以前，LAF 有作容錯的動作，把這種抓不到內容的字型的 RegKey，當成它的字型名稱來處理，所以 v200321 沒問題

從 v200427 開始，LAF 會紀錄字型內所有的字元資料，而這種有缺陷的字型，根本無從得知它有哪些字元，所以它的字元資料為空，所有字都是缺字

在 v200509 開始，LAF 拿掉了容錯的動作，對於這種 .NET Framework 抓不到內容的字型，就不做特別處理了，所以看起來就是未安裝的狀態

　　　　　只有已安裝字型，才能得知它的檔案裡包含了哪些字元，因此能作缺字的判斷
　　　　　所以未安裝字型，肯定是不會缺字的，因為 LAF 沒辦法憑空猜測它的字型檔案會有什麼內容


另外，我去找了一下這兩個字型

迷你簡細行楷有另外兩個版本，可以正常被 .NET Framework 辨識出來，或許可以替換掉你現有的版本

　　https://www.fontke.com/font/10106386/download/
　　https://www.fontke.com/font/10455771/download/


經典中圓簡，則不管哪個版本，通通都無法辨識


對於這種有問題的字型，作容錯的話，也是無法判斷缺字的，單純只是顯示上已安裝（黑色）或未安裝（紅色）的差別


再想想怎麼做好了

3、PS：第一次作快取时，面板里有句话“Don't worry, it's just an One-time job.”这里应该为a One-time job,，定冠词用a还是an应该看后面的音标而不是字母的元辅性。

感謝回報，下一版會修正

v200517

新功能 或 bug 修正

1. 修正沒缺字時，"NeedVerify.txt" 可能沒被刪除的問題
2. 修正移除某些字體後，ListAssFonts 會出現「未經處理的異常」問題
3. 新增參數 "-OCL"，（意指 Only Check Letters），缺字檢查時只檢查文字，對於數字、標點、符號、空白，一律略過不管
　　　　　　　　　　　　　　　　　　　　　　　未加此參數時，會檢查文字、數字、標點、符號，只略過空白
4. 對於某些 .Net Framework 無法處理的字型，如：「经典中圆简」、「迷你简细行楷」
　以額外支援的方式，讓它們在 ListAssFonts 裡能夠正常顯示安裝狀態、已安裝的話也能順利使用字型檔案複製功能
　但不支援缺字檢查功能（此功能需 .Net Framework 支援）
5. 將有用到「未安裝字型」、或是「不支援檢查缺字功能的字型」的字幕檔案，列進程式自動產生的「NeedVerify.txt」裡
　（當有加 -NNV 參數時，此功能無效，因為 NNV = No Need Verify，不會產生 NeedVerify.txt）


現在的 NeedVerify.txt 大概長這樣



字幕檔案A
Not Installed = 未安裝字型A、B、...、N
Installed but without any character information = 已安裝，但不支援缺字檢查功能的字型A、B、...、N
Lack of Characters = 缺字字型A，以及所缺的字、出現在哪一行
Lack of Characters = 缺字字型B，以及所缺的字、出現在哪一行
...

字幕檔案B
...
...

wyj-aln 发表于 2020-5-16 10:15
感谢楼主的回答！附件里针对性地给了显示不正确的两款字体：经典中圆简和迷你简细行楷以及测试用的ass文 ...

v200517 支援了這些字體

但因為有需要新增一些資訊到 cache files 裡面

請先刪除 %USERPROFILE%\AppData\Local\ListAssFonts 這個目錄，再重新執行 ListAssFonts

關於 -OCL 參數，再說明一下


目前 Unicode 有對所有字元作分類

我把 BIG5 跟 GBK 裡的所有字元（2 bytes 部分），都拿去做測試，測試結果在附件，檔名開頭分別為 BIG5 跟 GBK 的兩個文字檔


以 GBK 為例的話，檔案的前半部分如圖：




加上 -OCL，會讓 ListAssFonts 只檢查文字部分的字元有沒有缺字

文字部分的字元，指的就是上圖的紅框部分的字元，共有 83 + 113 +10 +21130 + 未列入的半型文字字元 (ABC, def 之類)


不加 -OCL，ListAssFonts 除了空白字元以外通通會檢查缺字

也就是整份檔案內的所有字元，都會檢查，比文字部分僅多了數百個數字、標點、及符號


要不要使用 -OCL 這個參數，可以根據附件來自行判斷

另外，BIG5 跟 GBK 只是用來舉例，了解一下各編碼內有多少不同種的字元而已

實際上 ListAssFonts 並不是根據 BIG5 或 GBK 來做字元判斷的
所有字元都是按照 Unicode 的分類標準，來做缺字檢查

大佬这是啥意思 0517版

BK-201 发表于 2020-5-23 18:22
大佬这是啥意思 0517版

第一次執行 ListAssFonts 時，會先花上好幾分鐘來作字型快取

使用思源黑體的Regular跟Bold字根的話都會顯示暗紫色呢
不管是1.004還是2.001照理說使用1.004應該會顯示黑色？

題外話，1.004跟2.001有很大差異嗎
畢竟大部分ass都還是以1.004的字型下去製作(如果是使用思源黑體)
目前是R跟B裝1.004，其他裝2.001

elvislee1104 发表于 2020-6-2 19:18
使用思源黑體的Regular跟Bold字根的話都會顯示暗紫色呢
不管是1.004還是2.001照理說使用1.004應該會顯示黑 ...

使用 1.004 Regular & Bold 都會是暗紫，不會是黑色
暗紫就是特別為了思源黑體跟 Noto Sans 1.x 版而量身打造的

目前不會因為電腦上裝的是思源黑體 1.x 或 2.x，而動態改變暗紫色的判斷標準

題外話，1.004跟2.001有很大差異嗎

目前我所知道最大的差異就是 .ass 裡的語法吧 (笑)

其它差異可以看官方字型 readme 檔案 27,28頁

畢竟大部分ass都還是以1.004的字型下去製作(如果是使用思源黑體)
目前是R跟B裝1.004，其他裝2.001

我覺得這樣裝也是 OK 的，但 ListAssFonts 還是會顯示暗紫色，用意是提醒 user 這字幕是可以 update 的
user 如果不想 update 字幕也沒問題，但需要自行判斷 1.004 思源黑體 / Noto Sans 是否有安裝在系統上了


會這樣設計，主要是程式需要有一個一致性的標準

當 ListAssFonts 面對一堆字幕，裡面有使用思源黑體 1.x 版的，也有使用 2.x 版的
這兩個版本的字型檔案，又不能同時裝在系統上，一定要選擇某一版

針對 1.x 版或 2.x 版的兩種字幕，ListAssFonts 也必須要表現出差異
不然 user 可能也會混淆，ex: 我明明就有裝思源黑體 Bold啊，為什麼這個字幕 OK，換個字幕就變成字型未安裝了

（這也是當初加入暗紫色的初衷）


長遠來看，字型版本會一直往前推進，1.004 版遲早還是要換下來

雖然一個一個改現有的字幕檔的確是有點麻煩
但也不可能一直無限期擱置吧

或許我可以寫個小工具，專門來更新字幕檔裡的思源黑體 (?)

v200604

這次改版主要是針對 Error.txt 做改善跟加強

[NeedVerify.txt]
1. 對於有字型子集的字幕，不再產生 NeedVerify.txt

[Error.txt]
2. 更改 Error.txt 的產生規則，原本針對每個有問題的字幕檔都產生一個 Error.txt，現在是每個目標只會產生一個 Error.txt
　（假設一個目錄 A 下面有五個字幕檔案 1 ~ 檔案 5，如果把目錄 A 丟進 ListAssFonts，那麼在目錄 A 下最多只有一個 Error.txt；
　　　　　　　　　　　　　　　　　　　　如果是把檔案1 ~ 檔案5 丟進 ListAssFonts，那最多就會產生五個 Error.txt）

　現在的 Error.txt 大概長這樣，跟 NeedVerify.txt 的風格類似
　單一檔案裡包含多個字幕檔的問題，包括問題所在的行號、該行的所有文字


3. ListAssFonts 現在也會檢查編碼（style 定義行的最後一個數字，或 \fe 所指定的編碼），如果編碼不合理，就會列為錯誤
　常見的編碼有 134 (GB2312)，136 (BIG5)，128 (SHIFT-JIS)，1 (Default)，0 (ANSI)，除此之外還有十來個數字是合理編碼

　不合理的編碼就如上圖，各 style 行最後一個數字都是135，不屬於任何一個合理編碼

4. Error.txt 每次都會重新產生，不會保留

5. 對於程式自動產生的 *.txt，不再把檔名複製到剪貼簿

大佬更新地好勤快，太强了！感谢您的工作！