AzaiOuO 发表于 2020-4-25 02:52
感謝~ 因為它幾乎是把全部的都列出來了XD
PS.有些番是只列OP部分 但用肉眼確認過之後發現沒有缺字
NeedVerify 字幕的判斷條件是
1. 在繁中 OS 下
2. 字型有簡中的字型名稱
3. 字數 < 20000
如果字幕所用到的所有字型裡面，有符合這些條件的字型
程式就會把相關的字幕行，放進 NeedVerify 字幕裡
但這不代表實際上一定真的會缺字
還是要搭配影片，或是用 Aegisub 才能知道有沒有缺字
tonyhsie 发表于 2020-4-25 03:38
NeedVerify 字幕的判斷條件是
1. 在繁中 OS 下
2. 字型有簡中的字型名稱
今天研究了一下，如何從實際的字型檔案來判斷，是不是真的缺了某個字
結果還不錯
最近應該可以升級一下缺字功能，直接準確地抓出確實有缺的字
{:12_885:}
tonyhsie 发表于 2020-4-25 19:29
今天研究了一下，如何從實際的字型檔案來判斷，是不是真的缺了某個字
結果還不錯
感謝大佬提供神器
平常很愛用 "王漢宗特黑體繁" 這個字體 (很像官方字幕會用的)
缺點就是缺字挺多的
有時候看番看到缺一兩字還能用FontForge自己補字
缺字一多 就只能忍痛換字體了 ((開始羨慕以前能無視字體追番的我
AzaiOuO 发表于 2020-4-27 03:41
感謝大佬提供神器
平常很愛用 "王漢宗特黑體繁" 這個字體 (很像官方字幕會用的)
缺點就是缺字挺多的
我自己是用思源黑體當作預設字體 (大小24)
效果也跟官方字幕很像
而且理論上它不會缺字，可以試試
v200427
新功能 or bug 修正
1. 因為 "思源黑體" & "Noto Sans CJK" v2.0 版以後，改變了 "一般 Regular" & "粗體 Bold" 的字型名稱形式
所以 ListAssFonts 會把 v1.x 版以前的字型名稱，都當成「定義錯誤的字型」來看待，顯示成暗紫色
ex: "思源黑體 Regular"、"Noto Sans CJK TC Bold" 這些名稱皆為 v1.x 以前的定義方式，視為定義錯誤
"思源黑體"、"Noto Sans CJK TC" + "\b1" or "style 行的 Bold 欄設為 -1"，v2.0 以後的定義方式，視為唯一正確定義
"思源宋體" 以前就是這種定義方式，所以沒有不同定義的問題，而現在 "思源黑體" v2.0 也跟進使用了一樣的定義方式
2. 如果有勾選 "Save .txt"，ListAssFonts 會自動打開這個文字檔
3. 支援內嵌的圖形檔 (類似內嵌的字型檔一樣，但沒有實際看過有這種字幕檔，只是根據 spec 實作這功能)
4. 如果字幕檔裡有內嵌字型或圖形，ListAssFonts 會跳出提示視窗
5. 如果字幕檔裡有某些行有問題 (1. 不符合正常字幕行規範, 2. 含有 "\rnd", 3. 字幕行指定的 style 不存在)，ListAssFonts 會將這些有問題的行存成 error.txt
6. 修正當「處理過長路徑」時，ListAssFonts 可能會停止回應的問題
7. ListAssFonts 所使用的 .Net Framework 從 4.5.2 變成 4.8
8. ListAssFonts 不再產生 ".NeedVerify.ass"，改為產生 "NeedVerify.txt"，內容為真正缺字的字幕、字型、所缺的字
NeedVerify.txt 可以說是全新的功能，跟以往的 NeedVerify.ass 完全不一樣
以前的 NeedVerify.ass，是用猜測的方式，把可能有缺字嫌疑者，全都抓起來，再通通交給使用者自行判斷
現在的 NeedVerify.txt，是把字幕檔的文字，用字型檔來一個個檢查，就跟「 Aegisub 的字型檢查功能」一模一樣
目前的 NeedVerify.txt 格式如下圖：
第一行是字幕檔的路徑
"D:\アクセル・ワールド\(0EF606CC).tc.Appended.ass"
第二行開始，
是缺字的字型，以及所缺的字，( ) 內的數字是行號，表示這個字出現在字幕檔裡的第幾行
华文细黑 <STXihei>：「，」(#1190,#1191)；「收」(#1190)；「有」(#1175)；「行」(#1190)；「的」(#1189,#1190)；「時」(#1190)；「託」(#1190)；「郵」(#1175)；「開」(#1190)；「新」(#1175)；「準」(#1191)；「酬」(#1190)；「認」(#1190)；「確」(#1190)；「輸」(#1189)
後面依此類推
ListAssFonts 是先把各字幕檔的所有文字收集起來之後，最後才會到字型檔裡去確認有沒有缺字
在字幕檔案不多、大小不大的情況下，效能差異不大
但如果字幕數多、或檔案大小較大，對效能會有一定的影響
這個收集文字的過程，會讓 ListAssFonts 的記憶體使用量持續上升，程式也沒有回應，這是完全正常的現象
（我測試了自己電腦上的 2,207 個字幕檔，大小 1.275 GB，記憶體最高峰時大概會用到 1.05 GB，產生 NeedVerify.txt 之後會正常釋放掉）
一些實驗數據
字幕總數字幕總大小字型數字元數找缺字時間不找缺字時間備註
1. 2,2071.275 GB 703 295,733 470.83 秒275.02 秒大量字幕檔
2.6 253.19 MB142,568 75.72 秒70.38 秒超大字幕檔
3.14 453.26 KB 6 1,992 0.165 秒 0.089 秒 一般情況
4.28920.34 KB 93,9341.012 秒1.179 秒一般情況
從上表可以發現，在極端的情況下，找缺字可能會對 ListAssFonts 的效能產生巨大的影響(1. 的執行時間多了 71.2%、多了 3 分 16 秒)
但在一般情況下，影響不大 (2. 多了 7.59%，3. 多了 85.4% 但實際上差不到 0.1 秒，4. 多了 16.5% 但實際上差不到 0.2 秒)
目前 ListAssFonts 預設是開啟 NeedVerify 找缺字功能的 (不管系統是簡中 或繁中 OS 都一樣)，但可以使用參數 "-nnv" 來強制關閉此功能
而 ListAssFonts 如果在剖析字幕檔的過程中
發現有 "未安裝字型" 或是 "定義錯誤字型"
便會自動暫時停止找缺字的功能，以減少不必要的執行時間、記憶體空間的浪費
ListAssFonts 跟 Aegisub 的字型檢查功能
目前的差異大概是這些：
1. ListAssFonts 可接受複數字幕檔，而 Aegisub 只能一次餵一個
2. 新增或移除字型後，ListAssFonts 不需要花時間重建資料庫，但 Aegisub 需要
3. Aegisub 會判斷出「'方正粗圆_GBK' 缺少下列字形： - U+00A0 NO-BREAK SPACE (\h)」，但 ListAssFonts 不會，因為 LAF 會跳過空白類的字元
4. Aegisub 有「樣式 '*Default' 不存在」而無法判斷字幕缺字的問題，但 ListAssFonts 沒有，因為 LAF 會把 "*Default" 當成 "Default" 看待，正常判斷缺字
因為這是全新功能，還沒經過時間的考驗
為了後續改版的參考用，也歡迎大家提供各式各樣意見
本帖最后由 tonyhsie 于 2020-5-8 04:45 编辑
v200508
新功能 or bug 修正
1. 改變 "NeedVerify.txt" 裡面缺字的顯示方式，如：
Verdana Bold：「？～」：#86「？」, #89「？～」
依序是，A. 有缺字的字型，B. 同個字幕檔裡，用到此字型而缺的字，C. 行號，以及該行缺的字
2. 可以接受帶 " 的參數，不需要拿掉 "，如："D:\ReLIFE\01.ass"
3. 修正同一行字幕，同時有兩個 \r 可能會判斷錯誤的問題 (v200423 才有的 bug)
4. 修正 \r, \b, \i, \fe, \p 等的判斷邏輯
5. 如果字幕檔裡不再有缺字了，會刪除以前檢查時自動產生的 "NeedVerify.txt"
6. 修正在執行 debug 功能時，新安裝或移除的字型，可能沒有反映在列表裡的問題
7. 支援多語系的 face name。所謂的 face name 是指 Regular、Bold、Light 這些字重，有的字型可能有英文以外的 face name，如 "纤体"、"ボールド"
8. 在 MPC-HC 內建的字幕 renderer 或 XySubFilter 下，.ass 檔其實也可以使用 .srt 的字幕指令，如 "<font face="X">, <b>, <i>" 等等；
本來打算讓 ListAssFonts 支援這些語法，程式也改好了，但後來這功能沒有實際放進去
因為使用這種語法的字幕真的很罕見，Aegisub 也不支援，現在 ListAssFonts 做法是，把用到這些指令的字幕行，收集起來存入 "error.txt"
9. 本版最大的改變之一，會把在所有字型裡、所有文字的列表，快取起來，大幅提升檢查缺字的速度；
但是第一次執行這一版時，ListAssFonts 會先花上好幾分鐘來作快取，這是沒辦法的事，也只有第一次執行時需要這麼做
後續再安裝字型、或刪除字型，也不會再重複作快取，會僅針對差異的部分即時處理，秒快取
如果執行時帶了 "-nnv" 參數，那 ListAssFonts 就不會作快取，也不會檢查缺字；之後若拿掉 "-nnv" 參數，程式會再作一次完整的快取
10. 本版最大的改變之二，程式不會再沒有回應了，起碼會在文字框裡秀出目前的進度、或是程式的狀況，如圖
圖中的字幕檔名，是會即時更新的，一直到字型列表的結果產生出來為止
本帖最后由 tonyhsie 于 2020-5-8 04:50 编辑
關於 v200508 的字型快取功能
這裡再補充說明一下
要找出字幕所使用到的字型，到底缺了哪幾個字，其實是很耗費時間的行為
因為必須要讀取字型檔案，一個字一個字來做確認；字型檔案一多的話，耗費的時間也會瘋狂增加
所以一定要做快取，避免重複的讀取，才能加快處理速度、減少檢測時間
對所有字型做快取，是一件非常耗時的工作，但能一勞永逸
只要快取檔案還在，那 ListAssFonts 就永遠不需要再去存取實際的字型檔案
Aegisub 也會做快取，所以系統上的字型沒有新增或刪除時，檢測缺字非常快（但在新增或刪除字型後，就要花上不少時間重作快取）
ListAssFonts 沒有這種現象，刪除單一字型時，快取修正時間只需 0.000 秒；而新增單一字型時，快取修正時間約 0.1~0.3 秒，幾乎無感
以下是一些實驗數據，供大家參考
測試 時間 備註
建立字型快取 5 分 52.25 秒 字型越多、檔案越大、速度越慢，只需做一次
在大量字幕裡找尋缺字、不使用快取 (約 = v200427) 7 分 14.75 秒 字幕越多、檔案越大、速度越慢
在大量字幕裡找尋缺字、使用快取 (v200508) 4 分 15.89 秒跟不用快取比，速度提升了 169.90 %
在大量字幕裡、不找尋缺字 (也就是 -nnv )4 分 08.68 秒跟使用快取比，速度提升了 102.90 %，幾乎沒差別
建立字型快取的測試環境：
1. Windows 10 專業版 1909，字型存放於 C 槽 (240 GB SSD)
2. 字型檔案數 1282 個，大小 6.47 GB
大量字幕的測試環境：
1. 字幕檔案數 2,221 個，大小 1.28 GB
結論：
1. 如果沒有什麼特別考量，以前有在使用 -nnv 這個參數的朋友，可以考慮拿掉了
2. 第一次建立快取，雖然會花很長時間，但之後幾乎就沒影響了
https://pastebin.com/TVven7gQ
又有報錯了啊，求大大幫忙看一下
謝謝
新版本，按 F12 進 debug mode 會出現 窗口反復彈出消失的情況啊
neil78 发表于 2020-5-8 19:51
https://pastebin.com/TVven7gQ
好的，我處理一下
如果有遇到同樣問題，可先執行一下附件，就能徹底關閉 ListAssFonts