Attached font not used by internal VSFilter

[astiob]

File (originally uploaded to libass/libass#713):
https://github.com/libass/libass/files/13279922/test-00.00.00.000-00.00.00.637.7z.zip

XySubFilter (and mpv):

MPC-HC 2.1.0 with libass disabled:

I can’t tell what’s wrong:

• The MIME type is application/x-truetype-font, which should already be supported.
• The file name is 方正小标宋_GBK.TTF. Could the uppercase extension be a culprit? But I feel like I’ve seen lots of font attachments with all-uppercase names. And the name shouldn’t matter at all if the MIME type matches.
• The Encoding in the ASS style is 1, which means “any”, so the recent(ish) encoding-related font selection changes shouldn’t be interfering with it. And XySubFilter is clearly able to load it, so the encoding matches well enough.
• The name TrueType table contains the exact string given in the ASS style as one of the two “family names”. And again, XySubFilter is clearly able to find this font, so this isn’t an issue with the GDI-based font selection.

[adipose]

I added the mimetypes on the 31st. efb35d8

[astiob]

I added the mimetypes on the 31st. efb35d8

That was for libass, and this MIME type was already on the list.

[astiob]

As a matter of fact, switching the internal renderer to libass (in the published 2.1.0 release) also displays the fonts correctly. Only the VSFilter path is wrong.

[adipose]

I added the mimetypes on the 31st. efb35d8

That was for libass, and this MIME type was already on the list.

Oops, you are right.

[adipose]

As a matter of fact, switching the internal renderer to libass (in the published 2.1.0 release) also displays the fonts correctly. Only the VSFilter path is wrong.

Good thing we have that option. :)

[clsid2]

Problem is in CMyFont::CMyFont()
selectedFontName differs from lf.lfFaceName, so it falls back to Calibri.
selectedFontName is "FZXiaoBiaoSong-B05"

I am not sure if this fallback code is correct and why it was originally added.
Edit: disabling the fallback fixes the problem.

[adipose]

Problem is in CMyFont::CMyFont() selectedFontName differs from lf.lfFaceName, so it falls back to Calibri. selectedFontName is "FZXiaoBiaoSong-B05"

I am not sure if this fallback code is correct and why it was originally added. Edit: disabling the fallback fixes the problem.

So I added this during this commit: 2a9e1da

I remember vaguely that sometimes that font would choose the "closest matching" font and this was better. But clearly the code has issues, maybe with UTF-8 fontnames...

[clsid2]

It doesn't work when a font is referenced to by its family name (of group of similar fonts) instead of its exact facename.

[adipose]

It doesn't work when a font is referenced to by its family name (of group of similar fonts) instead of its exact facename.

It probably selects Arial 9 times out of 10 when it fails. Perhaps if we said "it doesn't match, and it's Arial"?

[adipose]

It doesn't work when a font is referenced to by its family name (of group of similar fonts) instead of its exact facename.

What's happened is the actual filename is 方正小标宋_GBK.ttf but the facename is FZXiaoBiaoSong-B05. I'm actually kind of surprised it found it.

Unfortunately we cannot see the filename of the font that is selected into memory...

[astiob]

The filename doesn’t (shouldn’t) matter at all.

What I think clsid2 is referring to is family name vs full name of the individual font. And for PostScript-outline fonts, it’s family name vs PostScript name instead. But actually this probably isn’t relevant here, because this font’s full and family names are the same.

[adipose]

I cannot see that name anywhere in the font, but it is the filename. But perhaps that's the asian facename, and I just can't see it because of my locale.

[astiob]

Yes, the font in this issue has two sets of names: one in English and one in Chinese. You can see them e. g. with fontTools (below), FontForge, or Fontconfig’s fc-query.

  <name>
    <namerecord nameID="0" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Copyright(c) Founder Corporation.1999
    </namerecord>
    <namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
      FZXiaoBiaoSong-B05
    </namerecord>
    <namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Founder:FZXiaoBiaoSong-B05	Regular
    </namerecord>
    <namerecord nameID="4" platformID="1" platEncID="0" langID="0x0" unicode="True">
      FZXiaoBiaoSong-B05
    </namerecord>
    <namerecord nameID="5" platformID="1" platEncID="0" langID="0x0" unicode="True">
      1.10
    </namerecord>
    <namerecord nameID="6" platformID="1" platEncID="0" langID="0x0" unicode="True">
      FZXBSK--GBK1-0
    </namerecord>
    <namerecord nameID="7" platformID="1" platEncID="0" langID="0x0" unicode="True">
      By Founder Corporation. ±±¥Û∑Ω’˝
    </namerecord>
    <namerecord nameID="0" platformID="3" platEncID="1" langID="0x409">
      Copyright(c) Founder Corporation.1999
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      FZXiaoBiaoSong-B05
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
      Founder:FZXiaoBiaoSong-B05	Regular
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
      FZXiaoBiaoSong-B05
    </namerecord>
    <namerecord nameID="5" platformID="3" platEncID="1" langID="0x409">
      1.10
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
      FZXBSK--GBK1-0
    </namerecord>
    <namerecord nameID="7" platformID="3" platEncID="1" langID="0x409">
      By Founder Corporation. 北大方正
    </namerecord>
    <namerecord nameID="0" platformID="3" platEncID="1" langID="0x804">
      Copyright(c) Founder Corporation.1999
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x804">
      方正小标宋_GBK
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x804">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="1" langID="0x804">
      Founder:方正小标宋_GBK	Regular
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="1" langID="0x804">
      方正小标宋_GBK
    </namerecord>
    <namerecord nameID="5" platformID="3" platEncID="1" langID="0x804">
      1.10
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="1" langID="0x804">
      FZXBSK--GBK1-0
    </namerecord>
    <namerecord nameID="7" platformID="3" platEncID="1" langID="0x804">
      By Founder Corporation. 北大方正
    </namerecord>
  </name>

[adipose]

Thanks, I can see it now.

$fc-query a.ttf
Pattern has 24 elts (size 32)
        family: "FZXiaoBiaoSong-B05"(s) "方正小标宋_GBK"(s)

[astiob]

When exactly two family names are present, GDI finds the font by either of them, but its API only allows it to report back one name, the choice of which indeed depends on the locale. (See this wiki for more painful details.)

[astiob]

I should also mention that the whole idea of replacing the fallback by Calibri is prone to breaking subtitles by itself:

It probably selects Arial 9 times out of 10 when it fails. Perhaps if we said "it doesn't match, and it's Arial"?

GDI does indeed select Arial for Latin so predictably that English fansubs have historically relied on exactly this happening: e. g. see libass/libass#42 (with an even better picture in the last comment). GDI’s choice does seem to depend on the combination of Encoding/\fe/lfCharSet and system locale, though.

[clsid2]

Then we will just take whatever GDI gives us. Arial used to be default font in old VSFilter anyways.