This feels like a super esoteric question, so I’ll be very thankful if anyone has solved it. I’m posting specific unicodes because this only effects a very specific situation.
I’m generating a Distance Field font for use in my 3D world, and localizing it to Polish. Generally speaking the Polish language has a unicode range with attached diacritics, like this
For gameplay reasons, it would be desirable to also render the Latin Letter Small Capital range, which uses a 2nd unicode object (combining Ogonek) to achieve the same resulting character.
The problem is that, in this unicode range the diacritic is separate unicode character typically overlayed onto the Small Caps letter set – and for some reason it does not render in-world. It feels like perhaps the rendering of the text in-world only gets one pass, so it cannot apply the diacritic. Here is the distance field font that’s generated, and the separate diacritic is indeed in the render set.
And just a quick difference - here is what it looks like in the Localization Dashboard vs in-game. I’m showing the single character ᴇ̨ which is just one character that you can type, but is made up the previously mentioned two unicodes.
Localization Dash, ᴇ̨ correct:
In-game, ᴇ̨ diacritic missing:
If anyone knows how to get this working… my Polish players will thank you!
Hi! I really can’t thank you enough for diving in here. I didn’t expect any replies. You even included a package (which I updated)! Thank you!
I think we’re close, my challenge is the SDF / distance field application. Everything works fine in a widget. I don’t have any trouble generating my SDF fonts (I think I even used that video!)
The primary trouble is this:
You wrote ENERGIĘ
I wrote ᴇɴᴇʀɢɪᴇ̨
It’s a different range of unicode where the diacritic isn’t part of the character, it’s a separate character that gets overlayed.
ENERGIĘ will render in my SDF / in-world.
ᴇɴᴇʀɢɪᴇ̨ ends up being ᴇɴᴇʀɢɪᴇ in-world.
For the font, I’m just using Noto Sans but the main issue I think is that SDF probably doesn’t get a second pass for any kind of overlay character. Maybe a bug? Maybe an omission? I’m still hoping it’s something I’m missing.
I have updated the package and attached it. It uses Noto Sans. I wrote both E’s in-world. I didn’t render every character into the SDF so if you type in something random it may not have the characters for it. But I certainly imported Ę and ᴇ̨ to test. Ę works, ᴇ̨ does not.
sorry if you get pinged twice, this editor is being weird and I think my above post wasn’t a direct reply to you (so I wasn’t sure if you were going to see it). This should be a direct reply. I actually responded one comment up Thanks again!
I’ve noticed in the preview window when tying to type in ENERGIĘ the preview is not picking up on E at all (it just show NRGIĘ). Could it be a problem with the Chars list in some way that might be throwing off symbols?
Unreal stores fonts internally with UTF-16. Do the chars follow that standard?
Is the extra work worth the effort over just having standard utf ĘĄ symbols, seeing that they exist in parallel already inside of the font? (You could use the same font just a smaller size of text, maybe via rich text)
Not to mention the reduced readability of the text. What special use case is forcing you to adopt this approach?
Those particular characters fail because I didn’t import them into the SDF font; it’s solvable if you want. I just didn’t import the whole character set to save space. You’d just add them here and re-render
Anyway yes, I will abandon the character set if it’s not solvable, I just found it strange that it didn’t work, and thought to post this question before giving up. I also wanted to ask in case my other languages also had characters built with a secondary overlay character.
My Polish localization team thought the small caps helped identify specifically used terms well, but we can find other approaches.
Thanks again!
