UTF8 characters in presets not rendering correctly on M1 macOS, v3.2.x

[phuvf]

[phuvf]

[dnmeid]

What is the codepoint of these characters?

[phuvf]

⮜ and ⮞

I was working from this list: https://github.com/bitfocus/companion/wiki/Text-input but didn't encode using the number - just copy-pasted the actual character into the code. It worked on Windows so I thought I'd done it correctly.

This can be seen on line 11 of actions.js

[phuvf]

Sorry, that got decoded. I'll try again: ⮜ and ⮞

[dnmeid]

This is not a bug of the zinc-oscpoint module. It should work exactly like you are doing it. I use unicode characters a lot in perests the same way.
The codepoints of your characters are present also in the older versions. Starting with 3.2 we support vector fonts and with that even more (nearly all) unicode characters. I wonder why this is working on windows and intel mac but not on arm mac.
Unfortunaltely I don't have an arm mac, so I'm afraid I can't trace the bug well.

Are unicode characters working when you paste them directly in the button text line on M1 or is this a problem only for presets?

[phuvf]

This was reported to me by another user who was giving OSCPoint a spin during an event yesterday. All my testing has been on Windows and Intel macOS - but I'll spin this up on an M1 MacBook tomorrow and see what happens.

Assuming my wife lets me borrow her machine.

[Julusian]

I can confirm that chrome and safari on both m1 mac and chrome and companion on ubuntu are unable to render those characters.

My first thought was maybe the characters are missing from the font files we are using, but they are present in NotoSansSymbols2-Regular.ttf.

[Julusian]

Oh right ok, so the canvas will only use the first font that we tell it to use and if the character is not in that font it will show the empty box (or similar depending on platform?) mono/SkiaSharp#232 (comment)

So I suspect that a font is bleeding through from the OS to fill the characters not available in the font we are drawing with.
It looks like changing that behaviour is going to require fiddling with something either in the rust skia wrapping, or perhaps inside skia itself.

Maybe this would be fixed by a different canvas library (as well as fixing the 'problem' that skia-canvas does not appear to be maintained, causing us to use a fork that I have published). It doesn't seem likely though

[dnmeid]

It seemd to me that this was an old issue. I did try a lot of different fonts and combinations of fonts and on the intel mac the font fallback is working. First our built in fonts are used in the given order and then there is a fallback to the system fonts.
I just saw that I forgot to include all internal fonts, in fact only the sans serif and the color emoji is used and the symbols font is unused. So maybe only the fallback to the system font doesn't work.
Can you please check on the arm macOS the © char. On the button you should see the two straight lines from the c are not parallel, that is our sans font. If you see a colored ©, it will come from our color emoji font and if the two lines are parallel it is from the system font. If you then check the ⚾ char, you should see the ball on the button colored and symmetrical. If the system font bleeds thru, the seams of the ball would be slightly tilted. If you see a colored ball, it means that fallback within skia-canvas is working as this char is not present in the sans font.
Then it is enough to just include the symbols.

Edit: @Julusian, I just did see you found the issue yourself and did allready a fix. Is it working?

[Julusian]

I'm not 100% happy with how the code looks, but I am happy with how that #2648 behaves.
I think the code is unavoidable though, as I need to break out the symbol font into multiple font to make it work on my linux machine.

I've merged it into beta now, let me know if it doesn't work for you