Numbers appear as squares on Element Desktop with custom config.json

[lampholder]

• A deployment is using a 'managed desktop install', in which the latest desktop app releases are copied onto staff workstations, and then the config.json from their web instance is copied to the appropriate location on the device to configure the local desktop app
• This config.json file specifies a custom theme
• The theme has some relative paths linking to the various Inter fonts (which are hosted on their web installation)
• These relative paths don't resolve to fonts
• Because the fonts aren't loaded correctly, numbers appear as squares

[t3chguy]

relative paths linking

How can they have relative paths linking from a Desktop app to a Web deployment? Surely relative would mean they are resolved relative to the Desktop internal installation running at vector://vector

[lampholder]

Yeah, that's exactly what I mean :) And the fonts aren't there (obviously), which is the source of the problem.

[t3chguy]

I am not sure what the expectation is here in that case, should it be ignoring their font if it cannot be loaded?

[t3chguy]

It's not far off specifying the Wingdings font and complaining its not readable 🙃

[lampholder]

Well, there is not an expectation that this would work - I made this issue to raise the question of how we could help recommend they use custom themes with a desktop install.

[t3chguy]

A Desktop build is not attached to a Web one so they would have to deploy fonts somewhere locally and probably refer to it as a file:// - or maybe referencing their https://

[lampholder]

Right, so at the same time as deploying their config.json they could also dump the fonts locally - is there a way they could continue to use the same config.json that serves their web deployment to avoid having an templating step for that?

[t3chguy]

Yes, if they whilst building inject the fonts into the right place. Otherwise they would have to inject them into the asar archive to be able to get them relative to vector://

[lampholder]

At the moment they're using our build rather than building their own. In their specific case the font they're using is Inter, though, which presumably we do bundle locally into the build?

[t3chguy]

Yes but probably at a location which includes a random string for bundle id.
I'd imagine just not specifying a font would also use Inter given it is the app's default.

[lampholder]

Apparently not - I've heard (though haven't verified) that we'll use nunito instead if a custom theme doesn't specify a font.

[lampholder]

Apparently not - I've heard (though haven't verified) that we'll use nunito instead if a custom theme doesn't specify a font.

This is confirmed - custom themes are still based off the pre-rebrand stuff, so if we don't specify a font it'll use Nunito

[jryans]

At the moment, the main workarounds I can see would be to:

• Use absolute paths to the fonts (but this means desktop would request these web resources)
• Use fallback font families (but that might mean letters and numbers use a different font)

I suppose a more ideal fix would be to have some way to easily package custom fonts into a desktop build, but that's a more complex change.

[andybalaam]

@lampholder @t3chguy is this still relevant?

[t3chguy]

Has WIP PR