孤雨独火 发表于 2022-4-30 03:54
只要你内存够大就行
https://bbs.acgrip.com/forum.php?mod=redirect&goto=findpost&ptid=7798&pid=85692& ...
哦，原来还有这个问题。那看来系统的字体管理还是有点用啊。
不过我平常不会放太多字体进去，所以问题不大。
shadows 发表于 2022-4-30 11:53
你这是视频/字幕制作者的操作，不是播放者做的，不可能每个视频播放前都自己制作mks字幕
...
五年前我也是用这句话否定别人的
本帖最后由 shadows 于 2022-4-30 23:29 编辑
StarRingChild 发表于 2022-4-30 21:24
五年前我也是用这句话否定别人的
准确的说，操作难度、花费时间精力、实现效果与现有的其他解决方案（楼主的方法、各种自动加载字体工具）相比没有显著的优势
5年前可还没有那些字体自动加载工具，只有手动拖动字体到FontLoader.exe挂载。随着新工具、新技术的发展，有些事可以用新办法解决
虽然一般还是用默认字体
感觉mpv的小功能蛮多的是真的
Violit 发表于 2022-4-30 19:23
听说pot也有类似的功能？
额，转念一想pot自带的字幕渲染器不咋地，还是算了吧... ...
pot也有，而且使用madVR+xysubfilter也是可以加载pot目录下的fonts文件夹中的字体
本帖最后由 StarRingChild 于 2022-5-1 13:24 编辑
shadows 发表于 2022-4-30 23:23
准确的说，操作难度、花费时间精力、实现效果与现有的其他解决方案（楼主的方法、各种自动加载字体工具） ...
5 年前就有人跟我说过子集化的事情，我当时也是觉得没有那些字体自动加载工具，只有手动拖动字体到FontLoader.exe挂载。
但是现在有了mkvtool。
ass + fonts 通过 mkvtool + ass2mks.py 可以实现 ass 与 mks 的无损互转，我和 mkvtool 的作者肝了三四天，在 macOS、Windows、 Linux 上做了测试，已经把这个功能已经完善了。当然，需要播放器如 MPV 支持挂载子集化后的 mks
现在的操作难度，已经降低到连 hello world 都不会写的小白，也会操作了。我们分析了 ass 的各种情况，除了基本的粗斜体处理，连单行超过 65535 字符导致的 bug 也一一解决。
在 MPV 挂载子集化后的 mks 效果与安装完整字体 + 挂载 ass 完全一致
本帖最后由 shadows 于 2022-5-1 15:38 编辑
StarRingChild 发表于 2022-5-1 13:19
5 年前就有人跟我说过子集化的事情，我当时也是觉得没有那些字体自动加载工具，只有手动拖动字体到FontLoa ...
你做出的努力令人佩服，也尊重你的想法。但是我依然觉得制作mks这类事情更适合字幕制作者之类的角色去做，并不是说mks不可行。
如果能在字幕组中推行，使得外挂字幕增加mks这种方式，那么对于普通用户来说将是不错的选择。
本帖最后由 StarRingChild 于 2022-5-1 18:39 编辑
shadows 发表于 2022-5-1 15:37
你做出的努力令人佩服，也尊重你的想法。但是我依然觉得制作mks这类事情更适合字幕制作者之类的角色去做， ...
不啊，只要你有了字幕和字体，利用 mkvtool 就可以自己动手制作 mks，然后就可以丢弃掉麻烦的字体包了，基本上是 0 门槛的操作
事实上，有些字幕组已经掌握了这项技术，并且在 WebRip 中广泛使用子集化发布 MKV，只是在发布 BDRip 时，依然附带了完整的 ass 和 fonts.7z。这既有可能是出于惯性，也可能是照顾部分不支持 mks 的播放器。即使字幕组现在推广这项技术，还有很多已经发布的字幕无法享受，用户完全可以自己动手。
总之，站在用户的角度思考，如果不想安装/加载完整的字体，使用子集化 mks 字幕是另一种不错的解决方案。
蓥荥 发表于 2022-5-1 02:28
pot也有，而且使用madVR+xysubfilter也是可以加载pot目录下的fonts文件夹中的字体
...
好像不行吧，或者是我不会操作...
本帖最后由 苏辰汐 于 2022-5-1 20:08 编辑
StarRingChild 发表于 2022-5-1 18:31
不啊，只要你有了字幕和字体，利用 mkvtool 就可以自己动手制作 mks，然后就可以丢弃掉麻烦的字体包了，基 ...
并不是很认同你的看法，站在用户的角度思考明显是按需加载字体的轮子更为便利。
1. 无论是按需加载还是字体子集化都必然要维护字幕所需的原始字体包（子集化后也不可删除，需重复利用），mks子集化后mks文件内反而多了子集后的字体体积。看不出来更胜一筹。
2. 从便利性出发的角度思考，按需加载字体的轮子只需要配置下轮子就可一劳永逸；而mks子集化需要用户对所有已有/新增资源进行子集化操作，其持续性工作量可想而知。哪个更便利也是不言而明。
3. mks子集化应该对比的是ass字幕图形化（pgs），这两者的使用场景和操作性才是高度重叠，也是各有优劣。
就如楼上所说，ass子集化/图形化这一操作由于其操作的持续性，使用场景更适合字幕制作者/内封压制者在前期制作中进行，而不是由用户去维护这一行为。事实上确实有不少字幕组/压制组在内封时进行了ass字体子集化操作，理应得到支持和好评。
当然鉴于按需加载字体的轮子只存在于windows系统上，而linux上有更直接的fontconfig用于字体加载，只能说在windows/linux上mks子集化/图形化在用户层面的优势不高。
而当应用场景扩展到电视/电视盒子上时，由于安卓盒子/atv等的局限性，mks子集化/图形化的优势才彰显出来（不过这种应该都需要内封获得高兼容性）。这时候也没有mpv/mpc-hc之类pc播放器的事了（libmpv倒还有点存在感