Embedded piped video buttons's font depend on browser.display.use_document_fonts

[ghost]

Hi,

I'm testing Piped with embedded YouTube videos. Works fine, but the video buttons depend on Firefox's browser.display.use_document_fonts setting to display correctly.

Testing conditions :

Privacy Redirect 1.1.49 / Firefox 96.0.1 / Windows 7 Privacy Redirect / Invidious instance : https://piped.kavin.rocks uBlock Origin / My rules : added * kavin.rocks * noop uBlock Origin shows three connections to kavin.rocks : piped.kavin.rocks, pipedapi.kavin.rocks, pipedproxy-ams-2.kavin.rocks : OK Enforce Browser Fonts Firefox extension allows per-site settings forbrowser.display.use_document_fonts =1 or =0 (browser fonts) Video example page : https://wn.com/#/live

Piped videos' toolbar fonts require browser.display.use_document_fonts = 1 to be displayed correctly I use a Firefox extension named Enforce Browser Fonts and allow documents fonts on https://piped.kavin.rocks so no display issue. Unfortunately embedded piped videos will depend on the browser.display.use_document_fonts setting as well, and require that the site be allowed to use its fonts (again, with the Enforce Browser Fonts per-site allow/forbid setting).

With browser.display.use_document_fonts = 0 : no video buttons font

With browser.display.use_document_fonts = 1 : video buttons fonts applied correctly

Embedded YouTube videos redirected to Invidious display video buttons fonts correctly Embedded YouTube videos redirected to Piped depend on thebrowser.display.use_document_fonts setting (must be = 1)

Is there any chance that Piped video fonts be displayed independently of the browser's browser.display.use_document_fonts setting?

The target as far as i'm concerned is to be 100% independent of YouTube ... Thanks again for this wonderful project.

[FireMasterK]

This can't be done, as the icons require the font, I don't see any other easy alternative that can be implemented.

[ghost]

No such problem with Invidious. No big deal. Thanks

[lhindir]

Hi, I think this issue is worth reopening. There are definitely alternatives; icon fonts are generally considered an outdated method of serving icons these days compared to just serving SVG's. You can even continue to use FontAwesome icons in SVG form. Some rationale (and a FontAwesome example) here and here if you like. Alternatively, or even currently, you could use Unicode, either instead of the icons or as the fallbacks instead of the current lengthy text such as more_vert (e.g. ⋮) or slow_motion_video (e.g. 🏃 or 🐢).

This is only a request, of course. Thanks for your work!

[FireMasterK]

The problem here is that I don't control these, they're used by https://github.com/google/shaka-player

[ghost]

The problem here is that I don't control these, they're used by https://github.com/google/shaka-player

In that case why do some Piped instances (https://piped.tokhmi.xyz/ & https://piped.silkky.cloud/) call fonts.gstatic.com (as well as gstaticadssl.l.google.com btw)? Less bothering (no connection to Google) but nevertheless puzzling is that https://piped.mint.lgbt/ gets the fonts from fonts.kavin.rocks. I mean these instances when accessed directly, not from piped.kavin.rocks/preferences/Instance Selection of course.

If the fonts are included in the shake-player, if instances use this shake-player, why do some instances nevertheless call a fonts' server, why are the fonts either retrieved from fonts.kavin.rocks (not a problem, only odd) or from fonts.gstatic.com (a privacy problem and odd)?

[lhindir]

Ah, I thought that might be it when I saw the like and dislike icons worked. Personally, I'm a fan of just using the browser's native player, but if that's not possible here's the upstream issue: https://github.com/google/shaka-player/issues/2467