Mispositioned diacritic marks

[Teashrock]

Godot version:
3.3.2 Stable Mono Custom build

OS/device including version:
Windows 10 x64 1809

Issue description:
I used RichTextLabel with the custom font named Alegreya Regular for my project and at some moment I decided to change the custom font of it to more fine-looking. The issue is when I changed it, the diacritic marks of words was shifted to the right. So, even if the diacritic mark is above the last letter, it will be literally dangling in the air.
Here's the example word:

This is how it looked before changes (the font is Alegreya Regular):

This is how it looks after the font change (the font is Lora Regular):

One should have in mind that I tried to type the same word with the same font in LibreOffice. It looks like this:

So it's definitely not a font bug. It's a bug of something that renders it.

For comparision: I tried to really move the diacritic mark in the word. Results is below.
The text:

Same text in LibreOffice:

Same text in Godot's RichTextLabel:

As you can see on the last screenshot, the diacritic mark is not on it's place.

Steps to reproduce:

1. Add RichTextLabel.
2. Set Lora Regular as the custom font of it.
3. Type some text with diacritics in the "Text" field.
4. See the bug.

WARNING: for the bug to be reproduced, the diacritic marks should be separate from letters. If you would type a text where each diacritic mark is an inseparable part of the letter, the bug won't show up.
Example:

Minimal reproduction project:
Diacritic Bug Test.zip

[akien-mga]

CC @bruvzg

[Calinou]

I can confirm this on 3.3.2 on Linux:

Therefore, the bug isn't Windows-specific like #23093 is on 3.x.

This is also not exclusive to RichTextLabel. RichTextLabel on the top, Label on the bottom:

[Teashrock]

Update: It's the same in a simple Label.

It's not a bug in RichTextLabel.

[bruvzg]

It's a Godot font handling limitation, fixed in 4.x by the complex shaping. With the 3.x font implementation, which is drawing each glyph individually it's highly unlikely this can be fixed.

4.x:

[Teashrock]

@bruvzg
Can we backport the complex shaping to 3.x?

[bruvzg]

Can we backport the complex shaping to 3.x?

It's part of the huge set of changes, which involves breaking API and binary compatibility with GDNative plugins. Backporting is possible (I have an incomplete and a bit outdated backport here - https://github.com/bruvzg/godot/tree/ts_32), but it won't happen for the official 3.x releases.

[Calinou]

Closing, as this is fixed in master and can't be fixed in 3.x without breaking compatibility with existing projects.