I may have found the main problem:
If I replace all thin characters, such as the character i, j or l, with a wider character such as e, the problem vanishes. This is strange to me, as I assumed character width is accounted for in the “get desired size” function. This also seems to be the case: If I try to find the fraction of the string “iiiiiiiiii” and “MMMMMMMMMM” using “get desired width”, it does seem to the right value.
Some experimenting results are as follows:
trying to colour “ee” in “ee ii ii ii” causes the first part of the first ‘i’ to be coloured as well.
trying to colour “ee ee” in “ee ee ii ii” causes a larger part of the first ‘i’ to be coloured.
note that colouring the first part of the ‘i’ already includes a deviation the width of a space.
trying to colour “ii” in “ii ii ii ii” goed correctly.
It seems like character with widths like ‘e’ are treated as too much wider then characters with widths like ‘i’. I have no idea how to work around that, however.
My further attempts to solve it so far:
-Removing margins causes barely any change
-I replaced the “get text size” with “get desired size” for widgets with slightly better results, but the same problem is still present.
I am trying to colour words of a string inside a Text Object Widget one by one, like this:
To achieve this, I use a material as seen below.
The fill parameter is to determine what fraction of the string is coloured.
I then apply a dynamic instance of this material to the font material of the Text Object Widget within a widget blueprint. The “fill” material is updated every tick to a variable named progress. The widget blueprint is seen below.
To colour the words one by one, I use the following HUD blueprint:
The string Lyric contains the full string to display, and the string LyricProg contains the words that have to be coloured. Note that this is always the first N words, N being the variable wordindex. Then the length of both strings is determined and the ratio between them is calculated. This ratio is then set to the fill material through the variable progress in the widget blueprint.
My idea was that the fill of the material would then fill the string up to the ratio, so right after the first string. However, some words only get filled in so far, like seen in image 5.
Any idea what might be going wrong?