Jump to content

Accessing system files from Plugin


roaku

Recommended Posts

I'm curious if it's possible to load this file from the context of a Plugin:

'[emby-server-path]/system/dashboard-ui/modules/fonts/material-icons/LDItaoyNOAY6Uewc665JcIzCKsKc_M9flwmJ_1.woff'

I'm currently providing it to my plugin by copying it to my project directory and doing the whole assembly thing to bundle it into the dll.

But it would be cooler and cleaner if I could do something similar to 'Assembly.GetExecutingAssembly().GetManifestResourceStream([FILEPATH])', but for a file from Emby proper.

 

 

Link to comment
Share on other sites

So, on the backend of my plugin, I'm loading the font file into SkiaSharp manually, since the system fonts aren't always available to SkiaSharp across all Emby builds (Synology for sure, but possibly others) and this approach has provided consistent icon rendering across platforms.

iconic-render.png.fa7df12dc2ab8adf8fcfb053cfd297a8.png

 

On the frontend, I'm loading the modules font over http using its relative web path into openjs and parsing out the glyph names and codepoints to dynamically provide an icon selector:

iconic-selector.png.0f6ab7ea73c46f618f8a69c162826e12.png

I've tried the inverse approach, which is to have openjs parse my plugin's version of the font over http, but something gets mangled (wrong content-type header?)  when I get Emby to provide the font as a plugin resource (e.g. "/web/configurationpage?name=IconsFont&v=4.5.4.0"), and openjs can't parse it.

So, I'd *like* to be able to have the front end and back end load the same Emby provided file and have my plugin get out of the font *providing* business.

Alternatively, I'd be like to at least have my front end and back end loading the identical file, instead of each loading a different copy.

Edited by roaku
Link to comment
Share on other sites

Ok, there's no cross-platform way right now as the web assets are handled differently on some platforms. You may just want to embed a copy of it into the plugin.

Link to comment
Share on other sites

The catch with that approach is that openjs can't parse the font when it comes through as a 'ConfigurationPage' from my plugin.

If I could figure out how to tell Plugin.cs to provide the font in the same way as the server provides: "localhost:8096/web/modules/fonts/material-icons/LDItaoyNOAY6Uewc665JcIzCKsKc_M9flwmJ_1.woff?v=4.5.4.0" (attachment, content-type 'font/woff', etc.) I'd be in business.

From what I'm seeing, 'configurationpage=' can figure out that a javascript file is 'application/x-javascript' but not that a given font file is 'font/woff'.

Is there any way to get the Emby server to provide my plugin's font as a font over http?

 

Before I figured out the font parsing, I just had the glyph names and codepoint manually mapped to a js object, so worst case, I could go back to that.

Link to comment
Share on other sites

1 hour ago, Luke said:

Ok, there's no cross-platform way right now as the web assets are handled differently on some platforms.

Sorry to keep pestering you, but could I get come clarification on this quote?

Is this url available across all Emby platforms for 4.5.4.0?

Quote

[host]:8096/web/modules/fonts/material-icons/LDItaoyNOAY6Uewc665JcIzCKsKc_M9flwmJ_1.woff?v=4.5.4.0

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...