overte-org
Text entities: huge font files don't render properly
I assume I am hitting undocumented limits.
$ wine msdf-atlas-gen.exe -font nishiki-teki_3.99zhb.ttf -type mtsdf -fontname nishiki-teki_3.99zhb -format png -arfont nishiki-teki_3.99zhb.arfont -allglyphs
Neither atlas size nor glyph size selected, using default...
Loaded geometry of 33161 out of 33161 glyphs.
Glyph size: 32 pixels/em
Atlas dimensions: 5060 x 5060
Artery Font file generated.
$
The file I generated is here: https://data.moto9000.moe/nishiki-teki_3.99zhb.arfont
The original font file is here: https://umihotaru.work/
It works fine without using the -allglyphs attribute.
can you give this another try with the latest commit from https://github.com/overte-org/overte/pull/1111? it appears to work for me there (although the font takes a little while to load)
the characters are also seemingly offset by 1 (c renders as b, 1 renders as 0), not sure if that's expected?
can you give this another try with the latest commit from #1111?
It indeed works on #1111.
the characters are also seemingly offset by 1 (c renders as b, 1 renders as 0), not sure if that's expected?
That is not expected. I have no idea how the system works, so I don't know what could be causing this. It works fine with the default limited character set that you get without the -allglyphs parameter.
so the way it works internally is that the artery font reader gives us a list of glyphs, and each one is identified by a "codepoint" which is a uint32. we take the text (a QString) and split it into QChars, which we use to look up Glyphs.
so...it could be an actual problem with the original font, or a problem with the arfont -allglyphs parameter, or a mismatch between QChar and uint32, or some other problem with how we're looking them up...
The original font should be fine, since it works fine with a limited chatset and works fine outside of Overte. Everything else: no idea. It is worth noting though that this font is huge; I uses a lot of the private area as well, which is one of the things that makes it so interesting.
I guess we should try the allglyphs option on some other fonts and see what happens.
ok so it turns out -allglyphs just won't work until some fixes are made to msdf-atlas-gen (which it sounds like...might be pretty far off). but if you instead do -charset charset.txt where charset.txt is just a single line with [0x0,0xFFFF], it should work.
so once #1111 is merged to master, this should be fixed (but you'll have to regenerate the font)