发现个问题，当字幕里的样式过多时。会无法加载字幕，并闪退。
MILK 发表于 2020-2-5 16:33
发现个问题，当字幕里的样式过多时。会无法加载字幕，并闪退。
谢谢报告问题，但是我这周可能没时间来维护这个工具，下一周一定会抽空调查的。
以及，如果有一份能复现问题的字幕，我排查问题的速度会快很多，将其修复的概率也会增加。
我把程序放进字幕文件夹中，然后把所需字体拖入里面，只显示有几个字体，但是从不加载
Axcinr 发表于 2020-2-8 15:13
我把程序放进字幕文件夹中，然后把所需字体拖入里面，只显示有几个字体，但是从不加载 ...
呃，你的操作反了。需要把程序放在字体的文件夹（或者上层目录），然后把字幕拖到程序图标上。
QSCFTHMKO 发表于 2020-2-2 14:28
我又来反馈问题啦
这次似乎不能算作问题，感觉是思源黑体的锅？
因为
首先再一次感谢你提供的信息，我才能很快定位到问题。
先说字体数量太少导致闪退的问题，毫无疑问是我写的 bugε=ε=ε=ε=┌(;￣▽￣)┘
在二分查找匹配的字体文件时，没有检查范围导致内存越界访问，找到原因后就很容易改正。
第一个问题就有点棘手，这两个版本的字体的差异在于：
1.0042.001
Family Noto Sans CJK TC BoldNoto Sans CJK TC
Sub familyRegularBold
Full font nameNoto Sans CJK TC BoldNoto Sans CJK TC Bold
字幕文件指定的名称是 Noto Sans CJK TC Bold，并且 XySubFilter 使用 Windows 自带的字体加载机制。
Windows 的字体匹配貌似只能匹配 Family 这个字段，所以 XySubFilter 无法使用 2.001 版本的字体。
mpv (libass) 自己实现了一套字体匹配机制，它可以使用 2.001 版本的字体。
这个问题的理想解决方法，是在字体匹配时，指定它应该匹配的字段。
但因为用户操作复杂、fc-subs.db 中没有记录对应信息、等原因，我决定用另一种方案：手工黑名单。
在 fc-subs.db 的同目录下，创建一个 fc-ignore.txt 的文本文件，每一行写一个需要忽略的字体文件名（不必包含路径）。
以 "完整包\Google（谷歌）\CJK\NotoSansCJK-Bold 2.001.ttc" 这个文件为例，下面 4 种写法都能将其忽略：
[*]NotoSansCJK-Bold 2.001.ttc
[*]CJK\NotoSansCJK-Bold 2.001.ttc
[*]Google（谷歌）\CJK\NotoSansCJK-Bold 2.001.ttc
[*]完整包\Google（谷歌）\CJK\NotoSansCJK-Bold 2.001.ttc
你可以在这里找到包含上述改动的测试版本，希望它能解决你遇到的问题。
yzwduck 发表于 2020-2-8 23:48
首先再一次感谢你提供的信息，我才能很快定位到问题。
先说字体数量太少导致闪退的问题，毫无疑问是我写 ...
字幕文件上所使用的是 1.x 或 2.x 版本的 Noto Sans CJK TC Bold 字型
理論上程式本身應該能判斷得出來
因為這兩個版本在字幕中，語法上明顯不一樣，使用 2.x 版本字型的語法是 {\fnNoto Sans CJK TC\b1}，而 1.x 版是 {\fnNoto Sans CJK TC Bold}
(在 Style 處所定義的字型也同理)
或許也可以用例外處理的方式來解決這個問題
有同樣問題的字型，大概是以下這些
Noto Sans [無/Mono CJK/CJK] , 共 3*4 = 12 種字型，及對應的思源字型
Source Han Sans [無/CN/JP/K/KR/SC/TC/TW], Source Han Sans HW [無/K/SC/TC] , 共 8+4 = 12 種字型
思源字型另外有原文字型名稱，也需要一併處理，如 "源ノ角ゴシック", "思源黑體 TW" 之類的
如果我的理解沒錯的話
黑名單的作法
只能相容 1.x 或 2.x 其中一個字型版本，遇到使用另一個字型版本的字幕，又會發生無法匹配字型的問題
如果要同時兼容 Noto Sans/思源黑體 的 1.x 及 2.x 版本，可能要在程式內部解決掉這個問題；使用外部黑名單似乎沒辦法兼顧這兩個字型版本
tonyhsie 发表于 2020-2-9 03:36
字幕文件上所使用的是 1.x 或 2.x 版本的 Noto Sans CJK TC Bold 字型
理論上程式本身應該能判斷得出來
我认为在程序中为 Noto Sans 这类字体编码特殊匹配规则，不是一个好主意。
因为一直会有未知的字体需要编码处理，对于维护代码来说，是一个不小的负担。
并且目前的代码结构有点糟糕，可维护性本身就很差，添加复杂的匹配规则很困难。
我认为这个问题的最直接有效的做法，是只匹配字体的 Family name。它无需特殊规则，就可以加载能让 XySubFilter 识别的字体版本；
但是这样做会无法兼容用 Full font name, Postscript name 来指定字体的字幕。
所以我觉得理想的解决方法是给用户一个选项，来决定使用哪种模式来匹配字体，但是目前有这些问题：
[*]在哪里保存这个设置；
[*]在何时何处让用户修改这个设置；
[*]需要修改 fc-cache.db 的结构来保存所需信息；
[*]有重写程序去兼容 Windows/Linux/macOS 的想法；
[*]（没有时间）
因为理想方案近期难以实现，我才决定实验一下容易实现的黑名单机制。
yzwduck 发表于 2020-2-9 09:24
我认为在程序中为 Noto Sans 这类字体编码特殊匹配规则，不是一个好主意。
因为一直会有未知的字体需要编 ...
最后一个问题太真实了{:8_706:}测试了一下闪退的问题没有了，黑名单也确实能起效
那或许严格来说这是是Windows的毛病？估计得来个大佬反馈bug了，之前flac信息标签的问题差不多快一年半才见修复{:8_706:}
好像也就思源黑体这么多幺蛾子的样子，所以目前我选的方式是直接把1.0004版安装到系统里而不是写黑名单{:8_706:}
最后还是谢谢楼主写出这么满足痛点的程序www
本帖最后由 tonyhsie 于 2020-2-10 02:31 编辑
yzwduck 发表于 2020-2-9 09:24
我认为在程序中为 Noto Sans 这类字体编码特殊匹配规则，不是一个好主意。
因为一直会有未知的字体需要编 ...
我想程式內部，有時候無可必免得使用一些特殊規則來處理特殊情況 (dirty work?)
畢竟問題是確實存在那裡的，如果在程式這一關，不解決掉這個問題
那就會變成把問題再轉手到用戶身上，造成用戶本身也需要有足夠的基本知識，才能解決這樣的問題
所以我觉得理想的解决方法是给用户一个选项，来决定使用哪种模式来匹配字体，但是目前有这些问题：
在哪里保存这个设置；
在何时何处让用户修改这个设置；
需要修改 fc-cache.db 的结构来保存所需信息；
有重写程序去兼容 Windows/Linux/macOS 的想法；
（没有时间）
因为理想方案近期难以实现，我才决定实验一下容易实现的黑名单机制。
這樣做無非也是另一種 "特殊規則"
而且沒有解決問題，只是把球丟給使用者而已，而且每一個使用者都必須要懂這套機制、自己動手修改
再者，
根據設置來選擇 Noto Sans 1.x 及 2.x
不管使用者怎麼改設置，勢必要在 Noto Sans 1.x 及 2.x 之中二選一
遇到使用不同版本 Noto Sans 的字幕，使用者就必須再去修改設置
一來，在使用上並不是很方便，
二來，失去了 FontLoader 原先自動加掛字體，簡單解決問題的本意，事情會變得複雜化
三來，跟建立這套機制相比，若換成是在 FontLoaderSub 內部為 Noto Sans 1.x 及 2.x 建立特殊規則，兩者相較，後者反而還比較省事省時間
(不管是對程式開發者，或是使用者來說，比起 "建立一個自定匹配字體的機制"，如果 FontLoaderSub能直接處理掉這個問題，雙方都能節省程式開發/使用的時間)
這是個人的一點淺見，僅供參考
tonyhsie 发表于 2020-2-10 02:22
我想程式內部，有時候無可必免得使用一些特殊規則來處理特殊情況 (dirty work?)
畢竟問題是確實存在那裡的 ...
黑名单是一个特殊的规则，设计它的本意，是如果字体包里有一些不想要的字体，但因为做种等原因无法移除，就需要额外的机制（黑名单）将其屏蔽。碰巧，这个机制容易实现，可以用来“临时”解决字体版本的问题。
将问题回到字体版本上，我完全赞成在程序中编码特殊规则，来改善用户体验的做法。只是我认为解决这个问题的方法有：
[*]给用户提供一个 ON/OFF 开关（也许还可以由程序自动判断）；
[*]为每种可能出现问题的字体编码特殊规则；
我更倾向于第一种做法，不过目前还是没有依据的个人的猜测。有空的话，我会收集一大堆字幕来测试一下它的可行性。
@QSCFTHMKO 这个不是 Windows 的问题，问题在于 ASS/SSA 字幕的标准里，只说了 Fontname 是 The fontname as used by Windows. Case-sensitive. 字幕文件/字幕渲染器（以及其他与字幕相关的工具）没有统一的解释，所以不能把锅甩给 Windows。