Adding host fonts for docker containers

[solidsnake1298]

Adding documentation for adding host system fonts to a Docker container.

[jellyfin-bot]

Cloudflare Pages deployment

Latest commit	f2931cda6fd87af774d047938796eca4c92a3035
Status	✅ Deployed!
Preview URL	https://5e6ddc67.jellyfin-org.pages.dev
Type	🔀 Preview

[p0358]

Hey, can you take a look at my PR #1136? I wasn't aware of yours when creating mine, but now they kinda conflict with each other. I believe that my method of just mounting a folder of custom fonts into a subdirectory of /usr/local/share/fonts is pretty nice and useful, since it can allow users to easily add new fonts for subtitle burn-in on top of what's already existing in the container. Meanwhile mounting a host path instead has a few potential cons instead. My use-case comes from discussion at jellyfin/jellyfin#12511, where user might want to specify some path for fallback fonts that'd be streamed to web clients, and the same path could also be easily mounted into the Docker container, to also let the same fonts be used during burn-in with clients that do that instead of rendering them themselves.

So let me know what you think about it. In worst case scenario we could just end up mentioning both possibilities, but I believe just mounting a custom dir of fonts might be better if we were to choose just one method, as it's easier to add new font files there, instead of having to install an APT packet of fonts on host, provided one even exists (which for some obscure fonts that translators use in subtitles I fear might usually not be the case)...

[solidsnake1298]

Hey, can you take a look at my PR #1136? I wasn't aware of yours when creating mine, but now they kinda conflict with each other. I believe that my method of just mounting a folder of custom fonts into a subdirectory of /usr/local/share/fonts is pretty nice and useful, since it can allow users to easily add new fonts for subtitle burn-in on top of what's already existing in the container. Meanwhile mounting a host path instead has a few potential cons instead. My use-case comes from discussion at jellyfin/jellyfin#12511, where user might want to specify some path for fallback fonts that'd be streamed to web clients, and the same path could also be easily mounted into the Docker container, to also let the same fonts be used during burn-in with clients that do that instead of rendering them themselves.

So let me know what you think about it. In worst case scenario we could just end up mentioning both possibilities, but I believe just mounting a custom dir of fonts might be better if we were to choose just one method, as it's easier to add new font files there, instead of having to install an APT packet of fonts on host, provided one even exists (which for some obscure fonts that translators use in subtitles I fear might usually not be the case)...

@felix920506 - I think we should choose #1136 over my PR.

[felix920506]

Ok then, closing in favor of #1136