"Arbitrary" change in fonts?

mpv Information

mpv v0.39.0-26-gc3d9243a Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Sep 29 2024 00:06:06
libplacebo version: v7.349.0 (v7.349.0-13-ga018ab0-dirty)
FFmpeg version: N-117251-g6ec6b0790
FFmpeg library versions:
   libavcodec      61.20.100
   libavdevice     61.4.100
   libavfilter     10.5.100
   libavformat     61.8.100
   libavutil       59.40.100
   libswresample   5.4.100
   libswscale      8.4.100

Other Information

- Windows version: Microsoft Windows [Versión 10.0.19045.4894]
- GPU model, driver and version: Intel(R) HD Graphics 920; NVIDIA GeForce 940MX.
- Source of mpv: https://github.com/shinchiro/mpv-winbuild-cmake/releases
- Introduced in version: -
https://images2.imgbox.com/a0/19/j3DrC9Od_o.png
https://images2.imgbox.com/c1/60/hVv6ukuW_o.png

Reproduction Steps

Reproducible with --no-config. Reproduce a video with both Chinese (simplified), Chinese (traditional) and other languages subs, in srt. The fonts for, in this case, Chinese, change arbitrarily. The Long Ballad EP01 WEB-DL mkv-00 08 23 922-#1 mpv-shot0001 mpv-shot0004

Expected Behavior

For the font not to change arbitrarily.

Actual Behavior

The font changes arbitrarily, apparently happens when you switch between subs, sometimes. I think I understand why this changes now: if the first (simplified) sub has a line where all characters are simplified (and, hence, change the font to the "simpler" one, then the font will display in all lines as intended, when you change back; if, then you change to traditional, and then change back to simplified, it seems then the "sturdier" traditional font remains for characters that are from the "simplified" but actually the same as the "traditional" version, while the actual simplified characters which have no equivalent in the traditional form display with the "simpler" font.

Log File

output.txt

Sample Files

https://www.mediafire.com/file/sfxun4sd2qwhok0/sample.zip/file

I carefully read all instruction and confirm that I did the following:

[X] I tested with the latest mpv version to validate that the issue is not already fixed.
[X] I provided all required information including system and mpv version.
[X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
[X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
[X] I attached the full, untruncated log file.
[X] I attached the backtrace in the case of a crash.

You need to install and use font that supports all the glyphs.

There are multiple

[sub/ass] Glyph 0x... not found, selecting one more font for (sans-serif, 400, 0)

what happens is that some glyphs are rendered with different font than others and as you notice they will look different and not connect with the rest.

You need to install and use font that supports all the glyphs.

There are multiple
[sub/ass] Glyph 0x... not found, selecting one more font for (sans-serif, 400, 0)
what happens is that some glyphs are rendered with different font than others and as you notice they will look different and not connect with the rest.

Thank you, I will see if that fixes it, I will look through fonts and decide on a handful to install for Chinese. Is there any way to set a "preferred" Chinese font for simplified and traditional in MPV or how does it choose which one it uses by default? Maybe the one that Windows sets? I will look into it also.

Well, I installed some other fonts, but this doesn't seem to solve the problem. Furthermore, the Simplified font does have a font which can be used without missing characters (as does the Traditional), but for some reason, and this is the "bug", the Simplified seemingly changes for no reason to the Traditional font (but only in the characters that are equal to the Traditionals, since the others do not exist in that font). Any ideas?

Have you configured mpv to use one of those fonts? Add "--sub-font=Font name" to the mpv invocation.

Much as you guessed, libass (the subtitle renderer) asks your system for an arbitrary font that can display the first character, and precisely to avoid suddenly changing fonts, it keeps using that same font whenever it can. So if you first encounter characters that are the same in Simplified and Traditional forms and your system picks e. g. a Traditional-only font, and then later you encounter a Simplified-only character, it asks your system for a second font to display it. An example from your log:

[sub/ass] Glyph 0x968F not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold
[sub/ass] Glyph 0x5F52 not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> MicrosoftJhengHeiUIRegular, 1, MicrosoftJhengHeiUIRegular

When you switched to the Traditional track, your log shows:

[sub/ass] Glyph 0x4E0D not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold

Then you switched back to the Simplified track, and the log shows the same message as above:

[sub/ass] Glyph 0x4E0D not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold
[sub/ass] Glyph 0x5B9E not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> MicrosoftJhengHeiUIRegular, 1, MicrosoftJhengHeiUIRegular

You switched back and forth a bunch more times, but the log for each track stayed consistent: Traditional picked YuGothicUI, while Simplified picked YuGothicUI and then JhengHeiUI. The log suggests that prior track switches never affected subsequent rendering.

Yu Gothic is actually a Japanese font family, not Chinese at all. Unfortunately in your case, Windows picks it as the default, thinking you want to display Japanese kanji. This is partly a libass bug, because your subtitle track is marked Chinese, so it should be asking Windows to prefer Chinese fonts, and this is a known issue that is tracked in https://github.com/libass/libass/pull/607, but a fix isn’t expected any time soon. If I’m not mistaken, you could work around this (if you really wanted) by setting your system locale to Chinese.

JhengHei is actually a Traditional Chinese font family, so it’s ironic that it gets picked here for the Simplified track. I’m guessing the subtitles contain characters that are absent in Japanese but nevertheless present either in Traditional Chinese or just as a courtesy in JhengHei.

To display Simplified Chinese SRT subtitles in a decent font, set "--sub-font=Microsoft YaHei" (or another font that you prefer).

To display Traditional Chinese SRT subtitles in a decent font, set "--sub-font=Microsoft JhengHei" (or another font that you prefer).

Have you configured mpv to use one of those fonts? Add "--sub-font=Font name" to the mpv invocation.

Much as you guessed, libass (the subtitle renderer) asks your system for an arbitrary font that can display the first character, and precisely to avoid suddenly changing fonts, it keeps using that same font whenever it can. So if you first encounter characters that are the same in Simplified and Traditional forms and your system picks e. g. a Traditional-only font, and then later you encounter a Simplified-only character, it asks your system for a second font to display it. An example from your log:
[sub/ass] Glyph 0x968F not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold
[sub/ass] Glyph 0x5F52 not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> MicrosoftJhengHeiUIRegular, 1, MicrosoftJhengHeiUIRegular
When you switched to the Traditional track, your log shows:
[sub/ass] Glyph 0x4E0D not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold
Then you switched back to the Simplified track, and the log shows the same message as above:
[sub/ass] Glyph 0x4E0D not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold
[sub/ass] Glyph 0x5B9E not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> MicrosoftJhengHeiUIRegular, 1, MicrosoftJhengHeiUIRegular
You switched back and forth a bunch more times, but the log for each track stayed consistent: Traditional picked YuGothicUI, while Simplified picked YuGothicUI and then JhengHeiUI. The log suggests that prior track switches never affected subsequent rendering.

Yu Gothic is actually a Japanese font family, not Chinese at all. Unfortunately in your case, Windows picks it as the default, thinking you want to display Japanese kanji. This is partly a libass bug, because your subtitle track is marked Chinese, so it should be asking Windows to prefer Chinese fonts, and this is a known issue that is tracked in libass/libass#607, but a fix isn’t expected any time soon. If I’m not mistaken, you could work around this (if you really wanted) by setting your system locale to Chinese.

JhengHei is actually a Traditional Chinese font family, so it’s ironic that it gets picked here for the Simplified track. I’m guessing the subtitles contain characters that are absent in Japanese but nevertheless present either in Traditional Chinese or just as a courtesy in JhengHei.

To display Simplified Chinese SRT subtitles in a decent font, set "--sub-font=Microsoft YaHei" (or another font that you prefer).

To display Traditional Chinese SRT subtitles in a decent font, set "--sub-font=Microsoft JhengHei" (or another font that you prefer).

Thank you very much for the clear explanation, I think I understand what happens more thoroughly now, and the options you've given me are enough to help me get through the problem, since I have to configure other stuff with dual subs and so on in the terminal to start the video, adding more options is the way to go. Maybe I'll just add those options to mpv.conf so that I don't have to add them everytime, in any case. Then, I guess, this isn't exactly and mpv bug but a libass bug, so I think I should close this, as it's solved. Thank you again!

Have you configured mpv to use one of those fonts? Add "--sub-font=Font name" to the mpv invocation.

Much as you guessed, libass (the subtitle renderer) asks your system for an arbitrary font that can display the first character, and precisely to avoid suddenly changing fonts, it keeps using that same font whenever it can. So if you first encounter characters that are the same in Simplified and Traditional forms and your system picks e. g. a Traditional-only font, and then later you encounter a Simplified-only character, it asks your system for a second font to display it. An example from your log:
[sub/ass] Glyph 0x968F not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold
[sub/ass] Glyph 0x5F52 not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> MicrosoftJhengHeiUIRegular, 1, MicrosoftJhengHeiUIRegular
When you switched to the Traditional track, your log shows:
[sub/ass] Glyph 0x4E0D not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold
Then you switched back to the Simplified track, and the log shows the same message as above:
[sub/ass] Glyph 0x4E0D not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> YuGothicUI-Semibold, 2, YuGothicUI-Semibold
[sub/ass] Glyph 0x5B9E not found, selecting one more font for (sans-serif, 400, 0)
[sub/ass] fontselect: (sans-serif, 400, 0) -> MicrosoftJhengHeiUIRegular, 1, MicrosoftJhengHeiUIRegular
You switched back and forth a bunch more times, but the log for each track stayed consistent: Traditional picked YuGothicUI, while Simplified picked YuGothicUI and then JhengHeiUI. The log suggests that prior track switches never affected subsequent rendering.

Yu Gothic is actually a Japanese font family, not Chinese at all. Unfortunately in your case, Windows picks it as the default, thinking you want to display Japanese kanji. This is partly a libass bug, because your subtitle track is marked Chinese, so it should be asking Windows to prefer Chinese fonts, and this is a known issue that is tracked in libass/libass#607, but a fix isn’t expected any time soon. If I’m not mistaken, you could work around this (if you really wanted) by setting your system locale to Chinese.

JhengHei is actually a Traditional Chinese font family, so it’s ironic that it gets picked here for the Simplified track. I’m guessing the subtitles contain characters that are absent in Japanese but nevertheless present either in Traditional Chinese or just as a courtesy in JhengHei.

To display Simplified Chinese SRT subtitles in a decent font, set "--sub-font=Microsoft YaHei" (or another font that you prefer).

To display Traditional Chinese SRT subtitles in a decent font, set "--sub-font=Microsoft JhengHei" (or another font that you prefer).

Well, trying this out, this mirrors another feature request I posted a bit ago (for --secondary-sub-scale to be an option), is there any way to set the font for each subtitle in particular? For example: "--zh-sub-font=Microsoft YaHei" for simplified, no idea how you could specify that "--zh-sub-font=Microsoft JhengHei" for traditional, the same "--zh-sub-font=Arial" for Spanish "--zh-sub-font=Calibri" for English or is this not possible? Thank you.

Perhaps someone with better mpv knowledge will correct me, but as far as I’m aware, this isn’t possible. And indeed, even if it were, it seems both of your Chinese tracks are annotated with the exact same language tag (at least as far as mpv can tell), so it wouldn’t help.

It wouldn't be possible in config. But it should be possible to make lua script that checks subtitle track langauge and set the font accordingly. I don't have time rn to give example, but should be straightforward, to observe tracks and act on that.

Perhaps someone with better mpv knowledge will correct me, but as far as I’m aware, this isn’t possible. And indeed, even if it were, it seems both of your Chinese tracks are annotated with the exact same language tag (at least as far as mpv can tell), so it wouldn’t help.

Yep, although I wouldn't worry about the Chinese (since there are, I'm sure, fonts that support both; and, either way, I could re-mux if necessary to specify, if the tag exists), but more about the Spanish/English.

It wouldn't be possible in config. But it should be possible to make lua script that checks subtitle track langauge and set the font accordingly. I don't have time rn to give example, but should be straightforward, to observe tracks and act on that. I see, that'd would take a while to make, at least for me, but I will check if there are any similar scripts and work from that. Thank you.

mpv-player / mpv