Scheduled report shows square character in HTML report in date

[tsteur]

See below screenshot:

I created a scheduled report including graphs. Not PDF but HTML.

Then I clicked on "Download" on the created report.

The issue is visible on every graph.

This is on Matomo 5 on demo.matomo.org .

[sgiehl]

The "problem" is that various languages are using special space characters (e.g. half width, non breakable, ...) within the date format definition. The font we are using the generate the graphs simply doesn't support those characters.

We implemented a fix for french only in the past, where numbers weren't displayed correctly due to using a special space chart. See #20953

This time we should definitely aim to find a more global solution to fix all problems around that.

This might also be solved when using a new charting library, which we might need to do anyway. See #20570

[tsteur]

@sgiehl Did this used to work and is a regression? Or did it never work? I don't remember seeing this in the mobile app where we maybe use the same graphs (not 100% sure though).

[sgiehl]

I guess it kind of used to work at some point before we were using date format definitions from CLDR. Those definitions are updated from time to time. Maybe those unusual spaces in English came in with one of the latest updates.

[tsteur]

👍 Thanks for that. Could we label it as a regression in that case? cc @Stan-vw

[Stan-vw]

It's a bit tough to see if this is a proper regression, given the CLDR move sounds like a strategic choice and it's potentially been part of it ever since. But given that it potentially affects A LOT of users / report consumers and it's pretty embarrassing, I'm keen to prioritise is either way.

[atom-box]

Today a user reported:

• The characters display correctly in Matomo user interface but
• They fail to display correctly when exported in a pdf report.

We are observing boxes under entry page title section. This might be in place of Hindi (Regional languages).
Please help us with the necessary modifications to remove these boxes.

[mneudert]

Two known problematic characters introduced by CLDR 42 (thin space, narrow non-breaking space) have been treated in #21897 to fix rendering for the default non-unicode font. That is only an extension to the work done in #20953.

Having #21854 for general font improvements (everything outside graphs), and #20570 to replace the image library, should this be closed as solved? Or is there more we need to improve until a long-term solution is in place?

[sgiehl]

Let's close this one. Besides the issues you already mentioned, there are also #8665, #21129, #3304 and maybe even more that would benefit from a stable/global solution for that topic. We can now simply add more characters for replacement if other issues are opened.