XLSX files failing to import/export on azure web apps due to the default font.

[jawood1]

Which version of Skybrud.Umbraco.Redirects.Import are you using? (Please write the exact version, example: 4.0.1)

4.0.1

Which version of Skybrud.Umbraco.Redirects are you using? (Please write the exact version, example: 4.0.15)

4.0.17

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

10.7.0

Bug description

When running an import or export with an excel file it's throwing an error when running in azure web apps.

I believe this is due to the default font Calibri that is trying to be used not being installed on the server, so I can imagine this extends to other servers as well.

https://docs.closedxml.io/en/latest/tips/missing-font.html#missing-font

There are some solutions outlined within the link above primarily being to search for installed fonts on the server to use as a fallback https://docs.closedxml.io/en/latest/tips/missing-font.html#use-already-installed-font or bundling in a font for ClosedXML by default instead.

I can imagine for imports having any fallback font selected isn't an issue as it's just grabbing the information but on export I don't imagine it's as straight forward if the user doesn't have the font on their device?

[abjerner]

I think this is an issue that requires some more research. According to the documentation, ClosedXml will look for the Calibri font, and if not found, look for Microsoft Sans Serif. So in your case, loading the XLSX file probably fails because neither of the two fonts are present in the host operating system.

The solution may be to include a fallback font instead. According to your link, the Carlito font may be a good substitute that can be embedded with my package. The font license also seems to allow this. But like mentioned, I need to research and test this to be sure, so I'll save this for later when I have some more time.

[lm-chpa]

We are having the same error on Azure.
Our Azure App Service Plan is using Operating System Linux

@jawood1 Is your app service plan using Windows or Linux?

[jawood1]

Hi @lm-chpa I have the same issue for Linux and Windows based app services plans.

The issue being that fonts aren't installed on app services so when it's attempting to retrieve a font for generating the excel it can't.

It seems as suggested that the solution should perhaps include a open source font as per the documentation to get around this issue.

@abjerner just a thought on this, though it requires further investigation perhaps including the Carlito for instance as standard and if possible give developers the options to configure their own font as well?

[lm-chpa]

Understood @jawood1 I thought the it would help us, changing to Windows App Service plan.
I guess it would possible to replicate the issue on mac OS or Ubuntu. I think I will try that out

[abjerner]

just a thought on this, though it requires further investigation perhaps including the Carlito for instance as standard and if possible give developers the options to configure their own font as well?

This might be the way to go, but I haven't head the time to look any further into this.

The way I understood the issue, it's because ClosedXml uses the font for calculating the size of the text, but not so much for reading the actual text value. We don't really need the size of the text for the import, so a solution could also be to disable this part if possible in ClosedXml.

Another approach could be to simply use the first available font on the host system, assuming that there is at least one font available. Again, we don't really care about the size or how the text is rendered, so I think this should be fine as well.