[BUG] Unicode "glyphs" not rendering correctly in 4.0.0

[arikorn]

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Unicode shape-characters such as arrows and "targets" such as “⦾” (U+29BE) do not correctly align vertically in the latest v4.0.0 (companion-win64-4.0.0+7898-main-a5e9a2e7).

Incidentally, compared to v3.5.3 the glyphs are larger when in auto (this may be a good thing - v3.5.3 can't render the largest (44pt) size), but in 4.0 the characters do not align vertically correctly. For example, here, vertical-center alignment is selected:

Here's another example using a smaller (fixed) size showing all three vertical alignments being out of alignment:

Steps To Reproduce

1. Create a new button
2. Set its text to “⦾” (U+29BE) (w/o quotes)
3. Leave or set the font size to Auto (or use a fixed size, as above - but it looks a bit worse with Auto)
4. Set text alignment to (center, center)
   (See images, above and below)

Expected Behavior

Unicode characters should be centered both horizontally and vertically, as it is in v3.5.3 (and earlier). Here is a screenshot from the latest stable version (v3.5.3) [note, as mentioned above, that "Auto" size is smaller in 3.5.3 than v4.0. This is not the bug, just an observation.]

Environment (please complete the following information)

- OS: Windows 10
- Browser: Chrome 134.0.6998.89 
- Companion Version: companion-win64-4.0.0+7898-main-a5e9a2e7

Additional context

Note that "normal" text centers correctly vertically, but the non-latin glyphs have this issue. I've tested this with several "circle-in-circle" characters and arrows such as “➡” (U+27A1), ⬈ U+2B08, etc. as shown in the images above.

P.S. @Julusian, thank you for the short-release action fix! (I came across this bug while successfully testing your fix.)

[dnmeid]

This is a known problem. It has been reported in #2731 first.
#2731 was closed with a fix but unfortunately the fix did not really tackle the root of the problem. Additionally there have been other problems in 2731, so I rather keep this issue open instead of reopening 2731.

The main cause is that the emoji fonts and the text fonts that we are using have totally different line line spacing. The proper fix would be to adjust the emoji font itself to match the line spacing of the text fonts.

[arikorn]

Thanks @dnmeid. I did a bit of exploring and came up with more bizarre behavior. Some of it might even be helpful here...

Looking here I thought, maybe one of the other font families would behave differently. At Google's Noto fonts website for Symbols, I picked out arrows. Some worked well enough but the diagonal arrows were even worse than what I had been using: in the screenshot, below, the right and bottom arrows are fine but the right-bottom diagonal one is drawn below the bottom of the button. Why would this be? Is it a bug in Noto Symbols? Is Companion selecting it from a different font? (There seems to be plenty of overlap in the fonts loaded.)

Playing with it a little more: whichever character is first seems to control the centering... Here's a chart of sorts for
⬋ = U+2B0B (my original fat arrow) and
↙ = U+2199 (from the Noto Symbols? font - it shows in a blue box in the text input field).
Notice that with a Latin char (".") at the start, the previously "way-off" arrow is now properly centered. Sadly, a non-printing character (space) at the beginning of the text has no effect.

[dnmeid]

I think the problem is here: https://github.com/bitfocus/companion/blob/9131a303d5130d8a99f6c3dd0ae6955bf44aa86e/companion/lib/Graphics/Image.ts#L565C3-L568C1
This fix tries to avoid problems with different font line heights, but it obviously fails when the letter 'A' in that font is way off.
As I said, the solution will be to fix our fonts itself to have identical ascents and descents.

[arikorn]

Thank you Dorian (@dnmeid), that's very helpful. I'm betting that the solution is in the code rather than the font and it should be something relatively "simple" once we can divine the source of the problem. My reasoning is that characters such as the diagonal arrows above are drawn correctly when starting with a "Latin" character, as in the last button-example in my previous reply (the .↙ button text), but not when it's the first character

To reinforce my hunch: If I understand the code correctly, it draws the string ".↙" in a single call here:
this.context2d.fillText(text, xAnchor, yAnchor)
so the fact that it's drawing it correctly in this case, suggests that there is nothing intrinsically wrong with the fonts.

I started going down the rabbit hole of baselines, etc, in CSS and, while I'm probably in the "dangerous amount of knowledge" phase, I did notice that CSS does indeed have a concept of an alignment-baseline which normally tries to align everything to the first character's "dominant-baseline." It's not clear to me if/how it's possible to influence this using the context2d object but here's a simple experiment:

We can force the findLastChar 'anonymous' function to use the our preferred baseline by modifying this code

	let measure = this.context2d.measureText(textChars.join(''))
	let diff = w - measure.width

to measure a string that always starts with a "Latin" character (see my next comment). Here I'm adding your 'A' to the text to be measured and then subtracting its width so we get the width of only textChars. (Using "." might be slightly less intrusive, but hopefully not an issue for now.)

	let measure = this.context2d.measureText('A' + textChars.join(''))
	let diff = w - (measure.width - lineHeightSample.width)

for testing, if the button has only the single character (or two?), we should be guaranteed that findLastChar will return with this value. (Hopefully I'm not way off-base here as to when the code is run!)

By way of background for the above...
The way you're calculating the "normative size" is probably just fine: you're looking for the "CSS font-size" of a "standard" font ${fontheight}px/${fontLineHeight}px ${DEFAULT_FONTS} but since DEFAULT_FONTS is the list of all fonts, and the glyph 'A' is in the first font in the list, you will always get the size of the "Companion-sans" font, i.e. the first font in the list, regardless of what other fonts/glyphs are in the string to draw. (I am curious if the result is different than fontheight, though. Maybe different units?)

(Incidentally and unrelated: "companion-mono" is missing from the DEFAULT_FONTS list, whether intentionally or not...)

If this issue is still open if/when I am able to install a core-companion dev environment on my Windows computer, I'll be happy to continue delving...