Rendering: Incorrect font variant being selected

[neeshy]

Rendering: Incorrect font variant being selected

[kasper93]

The change in 3f153be was made because VSFilter does not consider width when selecting a font.

I appreciate the effort to maintain compatibility with VSFilter. However, I'm curious about libass's approach to establishing its own identity. While emulating VSFilter is important, it might be beneficial to consider how to address extensions of the format and behavioral changes moving forward.

The behavior introduced in version 0.13.0 (9 years ago) with 09edb29 was removed just a week before release without any deprecation period. This sudden change can be challenging for the library users to adapt to.

ASS does not support generic family names; libass only does it for MPlayer and mpv’s sake.

In this case, it might be worthwhile to version it in ScriptType differently than the VSFilter-compatible "ASS" to reflect these specific adaptations.

Thank you for considering this feedback.

[TheOneric]

A workaround should now be in place for Fontconfig; please check everything works as expected and be on the lookout for other font selection oddities. If everything’s alright (or at least no worse than before) we’ll probably publish 0.17.3 in a few weeks.

@kasper93 this issue was completely orthogonal to format extensions and no feature was removed. It’s just an unintended side-effect, affecting only fontconfig in specific scenarios we didn't catch before release.

[kimhbryan]

I'm experiencing the exact same thing, and can confirm the issue seems like a regression with commit 3f153be.

I built mpv with mpv-build on libass commit 0a63b95 and 3f153be, and fontselect exhibits this incorrect behaviour starting from the latter.

And I also do have fontconfig assigning 'sans-serif' to Noto Sans Regular.

$ fc-match 'sans-serif'
NotoSans-Regular.ttf: "Noto Sans" "Regular"

[rcombs]

The change in 3f153be was made because VSFilter does not consider width when selecting a font. If an ASS file explicitly requested Noto Sans, it'd get the Regular variant, because the Condensed version's relevant names are Noto Sans Cond and Noto Sans Condensed; Noto Sans alone only appears in name ID 16 (which is not used by GDI or libass).

If you want to default to a specific width in fontconfig, I would expect you can do that in your configuration?

[kimhbryan]

So before 3f153be an ASS file asking for 'sans-serif' with no further specificity would get the Regular variant of the default sans-serif font (which is sane behaviour; it is exactly what anybody would be expecting), but after 3f153be we now get the Condensed variant of the default sans-serif font.

Is this the intended behaviour of commit 3f153be?

As far as I can tell, 3f153be is essentially a revert of 09edb29.
09edb29 introduces the code that "Fixes wrong matches with different width variants in the same font family" which is exactly the issue that has arisen after the commit has essentially been reverted by 3f153be.

It seems like before font width support (09edb29) there was a "HACK" 09edb29#diff-f279ae24a74ca3d1d177c1052cca831a5fb0ad8a743f0770759c35adcea0c830L101 which mitigated this exact issue we are facing now ("HACK: get the last family name. that fixes fonts like Arial Narrow in some versions").

May I suggest two possible ways to move forward:

1. Revert commit 3f153be; or
2. Reinstate the "HACK" 09edb29#diff-f279ae24a74ca3d1d177c1052cca831a5fb0ad8a743f0770759c35adcea0c830L101

Either option should, I believe, allow fontselect to serve the correct font variant.

[rcombs]

Hmm… With the entire Noto Sans meta-family installed, I can repro this:

• libass reads in all fonts from fontconfig at startup, largely in alphabetical order, including the following:
  • Noto Sans Black(/Italic)
  • Noto Sans Bold(/Italic)
  • Noto Sans Condensed
  • Noto Sans Condensed Black(/Italic), etc.
  • […] Noto Sans Regular
• All of these Noto Sans variants report Noto Sans as a family, despite it not being a GDI-compatible family for these fonts; the Condensed versions additionally report Noto Sans Cond (the GDI-compatible family)
• Later, we call get_substitutions for sans-serif and get back a long list of font families, including (often starting with) Noto Sans
• We iterate the font list searching for Noto Sans, every single variant matches

So, I think we have 2 bugs here:

• The way we retrieve fonts from fontconfig will allow fonts to be treated as exact matches even if they shouldn't (e.g. for GDI compatibility, \fnNoto Sans\b600 should not match Noto Sans Medium; it should only match Noto Sans Regular)
• When performing a fallback/substitution search, we should consider fonts in the order that fontconfig would give them to us when searching for the provided name rather than in the order it gives when simply listing all installed fonts (this would indicate a preference for Noto Sans Regular over Noto Sans Condensed)

[astiob]

So, I think we have 2 bugs here

So it sounds like the first is #315 “we should pass Fontconfig fonts through our own name extraction code” (the problem being that we need lazy font matching for this not to delay startup by an eternity), while the second has been suggested in https://bugzilla.redhat.com/show_bug.cgi?id=2262410.

[astiob]

So before 3f153be an ASS file asking for 'sans-serif' […]

Is this the intended behaviour of commit 3f153be?

While I understand the issue this is causing in mpv, it’s also worth noting that ASS files asking for sans-serif aren’t intended to be supported in the first place. ASS does not support generic family names; libass only does it for MPlayer and mpv’s sake. The quoted commit’s primary concern was ASS compatibility, so we missed this case, and it remains our primary concern even as we look for solutions.

[TheOneric]

Note, the old width selection code in practice never actually worked sensibly either. Since ASS has no way to request a width, it just always penalised fonts whose width wasn’t 100, even when explicitly requesting e.g. Noto Sans Condensed.

All of these Noto Sans variants report Noto Sans as a family, despite it not being a GDI-compatible family for these fonts

yeah, Fontconfig “Makes no distinction between the various kinds of family name” https://github.com/libass/libass/wiki/Fonts-across-platforms#fontconfig

To make sure, i confirmed this doesn’t affect cases where Noto Sans’ regular variant is attached and “Noto Sans Condensed” installed on the system. I.e. this only affects font-fallback which is already “best-effort, no guarantees” anyway, buuut this case is probably quite common and i agree current behaviour isn’t intuitive or desirable.

It seems to get this right (as far as possible for fallbacks), we need to

• convert FontConfig to lazy loading and use our own font parsing (like by now all other system font providers)
• splitting memory and fallback font (#761)　
  OR (maybe?)　 figure out how to sort the fallback list with the current __libass_delimiter magic/hack

Lazy loading and font source separation are both things we already planned anyway, but they might take a while and have a fair chance of initially regressing some other edge cases.
If we can come up with a smaller scale workaround which doesn't regress other providers or VSFilter-compatibility it might be good to put this in place and quickly cut out 0.17.3, but i’m not yet sure how.

[astiob]

splitting memory and fallback font (Separate muxed/memory fonts from system fonts #761)

I don’t see how this is relevant.

[astiob]

If we can come up with a smaller scale workaround which doesn't regress other providers or VSFilter-compatibility it might be good to put this in place and quickly cut out 0.17.3, but i’m not yet sure how.

We could sort the full list of Fontconfig fonts by ABS(width - 100), restoring the effective selection priority from before 3f153be for system fonts when everything else is equal.

[TheOneric]

splitting memory and fallback font (#761)

I don’t see how this is relevant.

it indeed isn’t for this issue, sorry

[kimhbryan]

With 56ad347 libass does select Noto Sans Regular properly when requested "Noto Sans", fixing the incorrect behaviour from 3f153be.

[   0.548][v][osd/libass] fontselect: (Noto Sans, 400, 0) -> /usr/share/fonts/noto/NotoSans-Regular.ttf, 0, NotoSans-Regular