FontLoaderSub: 加载ass/ssa字幕所需字体的小工具 (r7-20200525)

非常感谢大佬的小工具，配合超级字体包真是无敌好用。

有一个不情之请，可不可以添加一个小功能，把匹配到的字体文件保存在一个新的文件夹中。

有时候看一部番只需要10来个左右，但笔记本上常驻50多G的超级字体包还是有些吃不消。。。

Thomashaku 发表于 2019-6-19 15:40
非常感谢大佬的小工具，配合超级字体包真是无敌好用。

有一个不情之请，可不可以添加一个小功能，把匹配到 ...

这个功能本来就有打算，因为 macOS 上加载字体就要靠复制来实现。
只是可能会咕很久…

請問加載的字體是放在記憶體中還是硬盤中的某個位置呢？
我想把臨時加載的字體一鍵提取出來

lee850220 发表于 2019-6-26 19:19
請問加載的字體是放在記憶體中還是硬盤中的某個位置呢？
我想把臨時加載的字體一鍵提取出來 ...

Windows 自行管理这些临时加载的字体，目前没有文档记述它会如何保存；测试发现它只保存在内存中，没有使用新版字体接口的程序无法获取到这些字体的路径信息。它不会复制到类似 C:\Windows\Fonts 的文件夹，所以无法简单地一键复制出来。

yzwduck 发表于 2019-6-26 19:50
Windows 自行管理这些临时加载的字体，目前没有文档记述它会如何保存；测试发现它只保存在内存中，没有使 ...

那有辦法導出font_path到檔案嗎
因為字幕組使用的名字有時候不完全等同於檔案名稱，我也不清楚你們是怎麼匹配到字體檔案的，所以搜尋字體檔案不知道該如何下手才想到這個方法。
已安裝的字體可使用同樣是版上開發的listassfont導出，而臨時加載的字體只要能導出他加載的位置就完美了的把所有用到的字體集合起來了。

lee850220 发表于 2019-6-26 21:55
那有辦法導出font_path到檔案嗎
因為字幕組使用的名字有時候不完全等同於檔案名稱，我也不清楚你們是怎麼 ...

目前这个工具没有导出相关的功能，不过既然已经看到了字体文件的路径，把它整理一下，我觉得不是难事。

• 在对话框里按 Ctrl+C，就可以把显示的文本复制到剪贴板里；
• 打开一个支持正则表达式的文本编辑器（比如 notepad++/sublime/vscode/etc.），把刚才复制的内容粘进去，删掉没有文件路径的行；
• 使用正则替换，把 \[ok\].+> 替换为空；
  

顺便说一下两个程序匹配字体的原理，listassfont 是读取注册表 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts 中保存的字体列表，然后解析出字体的 font family name 来进行匹配；而 FontLoaderSub 是列举文件夹中的文件，解析字体的 font family name, full font name, postscript name 三个属性来匹配。

感谢楼主提供的小工具 我跟楼上一样遇到了r5未响应的问题
r4正常 扫描的是xz字体包

centuryboss 发表于 2019-6-29 13:16
感谢楼主提供的小工具 我跟楼上一样遇到了r5未响应的问题
r4正常 扫描的是xz字体包
...

这是一个原因不明的 bug，目前我不知道如何复现。如果你能提供一份转储文件的话，我就能比较直接地分析 bug 的原因。

如果任务管理器里能找到进程的话，右键菜单里有一个“创建转储文件/Create dump file”，按一下后，会提示在某个位置创建了一个文件；
如果找不到进程的话，希望你能翻到这个贴子的 33 楼，按上边写的步骤，创建一个转储文件发送给我。

非常期待有人能够提供程序崩溃的线索，在此先提前感谢所有提供反馈意见的各位。

好的 转储文件比较大 有170+MB 上传网盘 链接：https://pan.baidu.com/s/1ZgdtBj-aX8qgr6e8NEqJrw 提取码：n0z0
复制这段内容后打开百度网盘手机App，操作更方便哦

遇到这个bug以后 即使强行结束任务 创建的数据库和未响应的程序本身都还是处于占用状态 不能删除或覆盖
此外跟r4相比 出现bug的r5扫描字体创建数据库速度很慢 有时候一个字体未扫描就卡死 有时候扫到一半卡死 希望这些信息能给楼主一些帮助

再次感谢楼主花费时间写的程序 感谢！

centuryboss 发表于 2019-6-29 21:21
好的 转储文件比较大 有170+MB 上传网盘 链接：https://pan.baidu.com/s/1ZgdtBj-aX8qgr6e8NEqJrw 提取码： ...

非常感谢 crash dump，hang 住的原因貌似已经找到，如果可以的话，能否测试验证一下？
这里有我刚修正后的版本，请用 Minimize.zip 里的 Win32 版本测试一下，看它是否会 hang 住？

附：crash dump 分析结论
字体加载完成后，程序(FontLoaderSub/FontLoader) 会使用 SendMessage(HWND_BROADCAST, WM_FONTCHANGE, 0, 0) 来通知所有窗口字体列表的变动，貌似因为某个其他程序没能响应这个消息，导致本程序一直卡住。
为了防止程序卡住，这次修改去除了上面提到的广播消息，后果是：其他程序可能要重启后才能检测到新字体。